id summary reporter owner description type status priority milestone component version severity resolution keywords cc mlocked 7251 silent mythbackend failure has suddenly returned (possibly EIT stream related) Marc Randolph Janne Grunau "This is a long standing bug (was present well back into 0.21) that comes and goes for a group of people using EIT. The past few nights (since the great-retune event of 2009), it has reappeared on a trunk 0.22 system. Since it is a silent failure (no back trace) we're not sure how to debug this further than just collecting a backend log. If you know what to look for and start searching, it is obvious that a number of people have run into this off and on 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: Bug #4993 As might this be: Bug #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 a 0.21 log file with -v important,eit,siparser (we are attempting to get a 0.22 log and will attach that when it arrives): 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. Are there any ideas on how we can help narrow this down further, or what might be causing it? Much, much more can be found here, along with a full (at present, 0.21) log: https://bugs.launchpad.net/bugs/330272" defect closed minor unknown MythTV - General head medium Invalid 0