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

Simon Kenyon simon at koala.ie
Fri Aug 17 09:09:05 UTC 2007

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

More information about the mythtv-dev mailing list