After compiling together information and posting to the mythtv-users list, I have received no responses - so I'm afraid that the only course forward is for one of you to either upgrade to alpha 0.22, or do a parallel install (anyone have a spare drive or partition?) to see if the problem is still occurring on 0.22.

Here is the note I posted:


Howdy all,

With 0.22 not far away, a group of users on 0.21 are trying narrow down the cause of a 0.21 EIT related bug they are encountering (I'm
just doing the best I can to help them, which is admittedly not much). If you know what to look for and start searching, it is obvious that a number of people have run into this over the past 18 months, and that I can find, none have resolved it:

http://www.gossamer-threads.com/lists/mythtv/users/340705
http://www.gossamer-threads.com/lists/mythtv/users/377245
http://www.gossamer-threads.com/lists/mythtv/users/393125
Then we have the three people here: https://bugs.launchpad.net/bugs/330272
This is possibly the same: http://svn.mythtv.org/trac/ticket/4993
(resolution: no problem could be found)
As might this be: http://svn.mythtv.org/trac/ticket/5739

What appears to happen is that things run fine for a while (some number of hours), and at some point, "QSqlQuery::exec: empty query" starts appearing in the mythtvbackend.log. Sometime later, it devolves further into messages about database errors, yet the users have verified that the database is fine, as is the command sent to it.

This is a snip of the log file with -v important,eit,siparser:

2009-08-31 17:01:10.587 EITCache: Wrote 1 modified entries of 255 for
channel 2734 to database.
2009-08-31 17:01:11.264 EITScanner (1): Now looking for EIT data on
multiplex of channel 12
2009-08-31 17:01:11.265 EITCache: Pruning all entries that ended
before UTC 2009-08-30T17:06:31
2009-08-31 17:01:11.425 EITCache: Deleting old cache entries from the database
2009-08-31 17:01:11.732 Created PMT
Program Map Table ver(20) pid(0x3eb) pnum(1) len(67)

Stream #0 pid(0x12d) type(video-mpeg2 0x2)
Stream Identifier Descriptor (0x52) length(1)
Stream #1 pid(0x12e) type(audio-mp2-layer[1,2,3] 0x4)
Stream Identifier Descriptor (0x52) length(1)
ISO-639 Language: code(eng) canonical(eng) eng(English)
Stream #2 pid(0x130) type(audio-mp2-layer[1,2,3] 0x4)
Stream Identifier Descriptor (0x52) length(1)
ISO-639 Language: code(eng) canonical(eng) eng(English)
Stream #3 pid(0x12f) type(private-data 0x6)
Stream Identifier Descriptor (0x52) length(1)
Subtitling Descriptor (0x59) length(8)

2009-08-31 17:01:12.187 PESPacket: Failed CRC check 0x22160113 !=
0xc3bfa4b5 for StreamID = 0x70
2009-08-31 17:01:12.231 EITScanner (1): Started passive scan.
2009-08-31 17:01:12.678 EITHelper: Added 2 events
2009-08-31 17:01:13.118 EITHelper: Added 2 events
2009-08-31 17:01:13.186 PESPacket: Failed CRC check 0x22160114 !=
0xc3bfa4b5 for StreamID = 0x70
2009-08-31 17:01:13.590 EITHelper: Added 3 events
2009-08-31 17:01:14.038 EITHelper: Added 3 events
QSqlQuery::exec: empty query
QSqlQuery::exec: empty query


.... this goes on for a long while, along with other EIT related log messages, until finally the empty queries give way to the dreaded DB
Error event occurs at a seemingly random spot (because the DB Error varies across users):

QSqlQuery::exec: empty query
QSqlQuery::exec: empty query
QSqlQuery::exec: empty query
222yyyy-22MM-22dd 22hh:22mm:22ss.22zzz DB Error (Update next_record):

The actual DB Error varies... "Looking up chanID" is another favorite. More complete logs are available on the launchpad bug referenced above.

As I mentioned, users have verified that the database is fine, as is the command sent to it. The corrupted date causes me to suspect there is no database error at all, but rather a corruption (bogus pointer?) occurring within the EIT code that manages to stomp on unrelated things.

1. Anyone have any other ideas on how to narrow this down further, or what might be causing it?
2. Any guesses if it is fixed in 0.22 (i.e., has anyone that had this error in 0.21 already moved to 0.22 and seen it go away)?

Thank you!

Marc