[mythtv] [mythtv-commits] Ticket #3789: Ringbuffer fails to switch at end of program during livetv (huge recording file)

[Eric Bosch]

Thanks, I've just done that, except instead of dropping the database, I
simply truncated it.  Will that have the same effect as far as resetting
the index?  I have noticed some other problems in the database, in that
if I run the myth.find_orphans, I'm coming up with many recordings that
it thinks are orphaned, but they still show up in the recorded programs
and are able to play.

Simon Kenyon wrote:
> MythTV wrote:
>   
>> #3789: Ringbuffer fails to switch at end of program during livetv (huge recording
>> file)
>> -----------------------+----------------------------------------------------
>>  Reporter:  anonymous  |        Owner:  ijr 
>>      Type:  defect     |       Status:  new 
>>  Priority:  major      |    Milestone:  0.21
>> Component:  mythtv     |      Version:  head
>>  Severity:  medium     |   Resolution:      
>>   Mlocked:  0          |  
>> -----------------------+----------------------------------------------------
>>
>> Comment(by eric.bosch at comcast.net):
>>
>>  Ok, Here's the log file from about a minute before to a minute or so after
>>  the transition of the program that should have taken place at 11:30.
>>  Additionally, I found a problem in the log pertaining to duplicate entry
>>  of key 1 on mythlog.  Backend Saruman was trying to create entry with key
>>  1 = 146190, however there already was an entry in mythlog with that key
>>  from backend Gandalf.  I actually see several instances of that same log
>>  entry for other show transition times in the log.  Should I purge the
>>  mythlog table?
>>
>>  INSERT INTO mythlog (module, priority, logdate, host, message, details)
>>  values ('autoexpire', 5, now(), 'saruman', 'Expiring Program', 'Expiring
>>  1016 MBytes for 1006 @ Thu Aug 16 10:00:00 2007 => Dr. Keith Ablow' );
>>  Driver error was [2/1062]:
>>  QMYSQL3: Unable to execute query
>>  Database error was:
>>  Duplicate entry '146190' for key 1
>>
>>   
>>     
> the table has an autoincrement field. note how that field is not 
> specified in the INSERT statement.
> what has happened is that the database has an incorrect idea of what the 
> next value should be and tries to reuse it, violating the key constraints,
> this causes the INSERT to fail.
>
> you will get this if the there is a database/machine crash at the 
> "wrong" time.
> i have had it in the past.
>
> my solution was rather "agricultural". i dumped the table, dropped it 
> and the reloaded it.
> that way, mysql could work out the correct next value for the autoincrement.
>
> the bottom line is that you have at least one problem with your database.
> this does suggest that there may well be others.
> note that mysqlcheck will not find this problem (to my knowledge).
> also alse be careful with dumping tables, dropping them and then 
> reloading them.
> by default mysql doesn't seem to generate all the correct DDL in the 
> dump and i know i had problems with indexes and/or data types after 
> doing this.
> my memory of the exat problems is a bit vague.
>
> hope this helps
> --
> simon
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
>
>