mythbackend silently fails with QSqlQuery::exec: empty query

[Kyle Gordon]

Binary package hint: mythtv-backend

Hi,

Randomly and without warning, mythbackend will silently fail without actually exiting. From the moment of failure onwards, it is unable to perform any database queries, but will continue to serve data to some functions.

The log will switch from normal logging, to errors pertaining to QSqlQuery::exec: failures, and Query failures. Such as -

2009-01-23 20:40:14.676 Scheduled 76 items in 0.4 = 0.02 match + 0.40 place
2009-01-23 20:42:15.071 MainServer::HandleAnnounce Monitor
2009-01-23 20:42:15.075 adding: flat as a client (events: 0)
QSqlQuery::exec: empty query
QSqlQuery::exec: empty query
QSqlQuery::exec: empty query

I have been unable to ascertain the source of the problem, as it appears to happen whilst the system is not in use (ie, whilst at work, or late at night). I have aattached a more comprehensive log in case it may be useful.

Regards

Kyle

The following information may apply...

ii libmyth-0.21-0 0.21.0+fixes16838-0ubuntu3.1 Common library code for MythTV and add-on mo
ii libmyth-perl 0.21.0+fixes16838-0ubuntu3.1 A PERL library to access some MythTV feature
ii mythtv-backend 0.21.0+fixes16838-0ubuntu3.1 A personal video recorder application (serve
ii mythtv-backend-master 0.21.0+fixes16838-0ubuntu3.1 Metapackage to setup and configure a "Master
ii mythtv-common 0.21.0+fixes16838-0ubuntu3.1 A personal video recorder application (commo
ii mythtv-database 0.21.0+fixes16838-0ubuntu3.1 A personal video recorder application (datab
ii mythtv-transcode-utils 0.21.0+fixes16838-0ubuntu3.1 Utilities used for transcoding MythTV tasks
ii mythweb 0.21.0+fixes16838-0ubuntu2.1 Web interface add-on module for MythTV

Linux flat 2.6.24-23-generic #1 SMP Mon Jan 26 00:13:11 UTC 2009 i686 GNU/Linux

Description: Ubuntu 8.04.2
Release: 8.04

ii libdbd-mysql-perl 4.005-1 A Perl5 database interface to the MySQL data
ii libmysqlclient15off 5.0.51a-3ubuntu5.4 MySQL database client library
ii libqt3-mt-mysql 3:3.3.8-b-0ubuntu3 MySQL database driver for Qt3 (Threaded)
ii mysql-client 5.0.51a-3ubuntu5.4 MySQL database client (meta package dependin
ii mysql-client-5.0 5.0.51a-3ubuntu5.4 MySQL database client binaries
ii mysql-common 5.0.51a-3ubuntu5.4 MySQL database common files
ii mysql-server 5.0.51a-3ubuntu5.4 MySQL database server (meta package dependin
ii mysql-server-5.0 5.0.51a-3ubuntu5.4 MySQL database server binaries

[Kyle Gordon (kylegordon)]

Hi,

I've just come home, and haven't used MythTV since last night. The system has fallen over and mythbackend.log contains the following info...

222yyyy-22MM-22dd 22hh:22mm:22ss.22zzz decodeLongLong() called with the iterator too close to the end of the list.
222yyyy-22MM-22dd 22hh:22mm:22ss.22zzz decodeLongLong() called with the iterator too close to the end of the list.
222yyyy-22MM-22dd 22hh:22mm:22ss.22zzz AutoExpire: CalcParams(): Max required Free Space: 1.0 GB w/freq: 15 min
222yyyy-22MM-22dd 22hh:22mm:22ss.22zzz decodeLongLong() called with the iterator too close to the end of the list.
222yyyy-22MM-22dd 22hh:22mm:22ss.22zzz decodeLongLong() called with the iterator too close to the end of the list.
222yyyy-22MM-22dd 22hh:22mm:22ss.22zzz 2Reschedule requested for id -1.
222yyyy-22MM-22dd 22hh:22mm:22ss.22zzz DB Error (UpdateMatches):
Query was:
SELECT NULL from record WHERE type = :FINDONE AND findid <= 0;
Driver error was [2/1064]:
QMYSQL3: Unable to execute query
Database error was:
You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ':FINDONE AND findid <= 0' at line 1

222yyyy-22MM-22dd 22hh:22mm:22ss.22zzz DB Error (Update next_record):
Query was:
UPDATE record SET next_record = '0000-00-00T00:00:00' WHERE recordid = :RECORDID;
Driver error was [2/1064]:
QMYSQL3: Unable to execute query
Database error was:
You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ':RECORDID' at line 1

222yyyy-22MM-22dd 22hh:22mm:22ss.22zzz DB Error (Update next_record):
Query was:
UPDATE record SET next_record = '0000-00-00T00:00:00' WHERE recordid = :RECORDID;
Driver error was [2/1064]:
QMYSQL3: Unable to execute query
Database error was:
You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ':RECORDID' at line 1

222yyyy-22MM-22dd 22hh:22mm:22ss.22zzz DB Error (Update next_record):
Query was:
UPDATE record SET next_record = :NEXTREC WHERE recordid = :RECORDID;
Driver error was [2/1064]:
QMYSQL3: Unable to execute query
Database error was:
You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ':NEXTREC WHERE recordid = :RECORDID' at line 1

222yyyy-22MM-22dd 22hh:22mm:22ss.22zzz DB Error (Update next_record):
Query was:
UPDATE record SET next_record = :NEXTREC WHERE recordid = :RECORDID;
Driver error was [2/1064]:
QMYSQL3: Unable to execute query
Database error was:
You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ':NEXTREC WHERE recordid = :RECORDID' at line 1

222yyyy-22MM-22dd 22hh:22mm:22ss.22zzz DB Error (Update next_record):
Query was:
UPDATE record SET next_record = :NEXTREC WHERE recordid = :RECORDID;
Driver error was [2/1064]:
QMYSQL3: Unable to execute query
Database error was:
You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ':NEXTREC WHERE recordid = :...

[MarcRandolph (mrand)]

Howdy, and thank you for helping to make Mythbuntu better. Unfortunately, mythtv developers upstream have stopped focusing on 0.21 based reports in preparation for a 0.22 release later this year. Is this bug still occurring for you? Could you please try to see if this bug is reproducible on 0.22? If it is, we can try to forward this bug upstream to get the right eyes focused on it.

We have builds of mythtv 0.22 available on a PPA to test. Please follow the directions at http://mythbuntu.org/auto-builds to enable them.

WARNING: If you intend to revert back to 0.21 after testing, you will need to back up your database before upgrading.

    Thanks!

[alistair (alistair-tyeurgain)]

I have just started to get this problem as well.

I notice that entries appear in the "programs" table of the database with all-zero start and end times, which cannot be right! This started out-of-the-blue just the other day.

I have a setup that uses the off-air programme guide from UK DVB-T.

I will give 0.22 a try, since the present installation is so unstable as to be near useless, after near-enough 18 months of virtually flawless operation.

A

[Roy Thompson (roy-haematic)]

I've started to get this issue in the last two weeks as well. mythbackend failing about every other day. Did you try .22?

[alistair (alistair-tyeurgain)]

On Wednesday 26 August 2009 08:14:54 Roy Thompson wrote:
> I've started to get this issue in the last two weeks as well.
> mythbackend failing about every other day. Did you try .22?
Roy

Trying .22 looks to be more complex than I first thought.

However, I am now running the backend with options "-v database --nojobqueue"
and have not had a crash since. I don't use any post-recording jobs so that
looses nothing. I am going to drop the verbose option because it is not
revealing anything useful.

A

[MarcRandolph (mrand)]

The fact that two of you have started seeing this within the past few weeks would seem to indicate something changed in that time frame, or soon before. Did you all do an update around that time? What versions are you running? Have you run a database check? Do your error messages look very close to Kyle's (with the invalid looking date 222yyyy-22MM-22dd 22hh:22mm:22ss.22zzz)?

Thank you,

   Marc

[MarcRandolph (mrand)]

ah - another question: Do you all use remote frontends? If so, do you have a real IP address set for the backend rather than 127.0.0.1?
Or did you all happen to change a configuration? Do you use EIT? Random idea: Perhaps the format of the EIT changed, and triggers a bug in MythTV.

[Kev Walke (kelvinelk)]

The error which i get are similar in format to Kyle's. It seems to happen mostly in the middle of the night but it has been happening for some time, around the time that it was first reported by Kyle. It is only recently that it seems to be getting far more frequent.

Background to my mythtv setup:

I have been running mythtv for a couple of years now, initially using the packages that came with ubuntu, then moving to the weekly builds from mythbuntu. I have a remote frontend and the backend sits on a private subnet. EIT is used to collect the radio information only on DVB-T. Tuner card is a Hauppauge Nova-T 500.

The issue always seems to occur when the backend _appears_ to be idle, but perhaps it is actually doing some housekeeping or something in the background? I am reluctant to start using 0.22 and wait for the bug to occur as we record things daily and any database backup will quickly be out of date.

For now I will try alistair's trick of turning off the jobqueue thread, and if that doesn't work, try running backend with --nohousekeeping also.

[alistair (alistair-tyeurgain)]

As a follow-up:

> Do your error messages look very close to Kyle's (with the invalid looking date 222yyyy-22MM-22dd 22hh:22mm:22ss.22zzz)?

Yes, indeed! Searching on 222yyyy was how I found this thread. It also seems to happen in the middle of the night.

> Do you all use remote frontends? If so, do you have a real IP address set for the backend rather than 127.0.0.1?

Yes. The backend is on an unattended machine that runs the backend, and a couple of other non-intensive services (Slimserver music server, IMAP server, DHCP server, DNS server, all for a small LAN only). It has no GUI, 2G RAM & 1T+360G HDD, and is not at all stressed!

> Or did you all happen to change a configuration?

No. It is an Ubuntu Hardy LTS machine that just receives the normal updates using apt-get once a week. It uses no special repos (apart from for the Slimserver). I have just run mythtv-setup the once, right at the start. However, it is not a Mythubuntu install. It is a server install with the mythbackend installed afterwards.

BTW, the backend has not gone down since I turned off the jobqueue.

A

[Roy Thompson (roy-haematic)]

I get very similar error message, yes, that is how I found this bug too.

....
222yyyy-22MM-22dd 22hh:22mm:22ss.22zzz DB Error (JobQueue::CleanupOldJobsInQueue: Error deleting old finished jobs.):
Query was:
DELETE FROM jobqueue WHERE (status in (:FINISHED, :ABORTED, :CANCELLED) AND statustime < :DONEPURGEDATE) OR (status in (:ERRORED) AND statustime < :ERRORSPURGEDATE)
Driver error was [2/1064]:
QMYSQL3: Unable to execute query
Database error was:
You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ':FINISHED, :ABORTED, :CANCELLED) AND statustime < :DONEPURGEDATE) OR (status in ' at line 1

222yyyy-22MM-22dd 22hh:22mm:22ss.22zzz DB Error (HouseKeeper Cleaning TVChain Table):
Query was:
SELECT DISTINCT chainid FROM tvchain WHERE endtime > :FOURHOURSAGO ;
Driver error was [2/1064]:
QMYSQL3: Unable to execute query
Database error was:
You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ':FOURHOURSAGO' at line 1

....

I have a confession to make: my mythbackend is running on gentoo, not ubuntu!! I know know, I should log it with gentoo and/or mythtv, but this is the only reference I found to this on google felt heartened that I found someone else with the same issue.

My frontend and backend are on the same box, but I do have a real IP address set rather than 127.0.0.1 because I also use mythbackend as a upnp server.

I do use EIT with DVB-T, adapter is Hauppauge Nova-T Stick.

I am trying out --nojobqueue to see what happens...
Roy

[Roy Thompson (roy-haematic)]

Just a note that --nojobqueue did NOT solve it for me.
It happened again last night.

[MarcRandolph (mrand)]

Thanks to all three of you for updates. Sounds like the common theme is EIT. I may have found the offending code, and if that is indeed the source of the problem you all are having, it has been changed in 0.22. For those that are interested, you'll notice that the following changeset describes fixing a problem with MythContext:DBError():

http://cvs.mythtv.org/trac/changeset/17306

You can look in eithelper.cpp and you will find "Looking up chanID" on line 669 uses MythContext::DBError():
http://svn.mythtv.org/trac/browser/branches/release-0-21-fixes/mythtv/libs/libmythtv/eithelper.cpp?rev=21547#L669

I would guess that it is the same for "Update next_record", but I didn't go looking for it. As we mentioned previously, upstream isn't really accepting bugs for 0.21-fixes any more, so I'm afraid the solution will have to be moving to 0.22 (or else to disable EIT and maybe use xmltv). That isn't to say that there may not be additional problems regarding EIT, but I think the source of this bug is likely to be addressed, and as such, I'm going to close this bug.

There are quite a lot of EIT fixes in 0.22 (reminder: if you do upgrade, be SURE to back up your database - and perhaps go read the -user and -dev lists, searching for EIT to make sure any recent fixes haven't introduced other problems that would affect you).

Thank you all again for your help!

[Kev Walke (kelvinelk)]

@MarcRandolph

whoa - hang on a sec!!!!
you want to close a bug based on a guess? play fair!

the changeset you have linked to is for mythcommflag - I dont believe this is a function associated with EIT.

@Roy Thomson

Thanks for letting us know - I am now running with --nohousekeeper - will let you know how that goes

[MarcRandolph (mrand)]

@Kevin,
Sorry, you are correct - I missed the mythcommflag angle somehow while I was rushing around this morning. I'm more than happy to leave this open for a while longer if you all can continue helping to debug it.

I did leave something out of my note earlier: MythContext:DBError() has been replaced by MythDB::DBError() in 0.22.
MythDB:DBError() does look cleaner / safer:

void MythDB::DBError(const QString &where, const QSqlQuery& query)
{
    QString str = QString("DB Error (%1):\n").arg(where);

    str += "Query was:\n";
    str += query.executedQuery() + '\n';
    QString tmp = toCommaList(query.boundValues());
    if (!tmp.isEmpty())
    {
        str += "Bindings were:\n";
        str += tmp;
    }
    str += DBErrorMessage(query.lastError());
    VERBOSE(VB_IMPORTANT, QString("%1").arg(str));
}

when compared to the old:

void MythContext::DBError(const QString &where, const QSqlQuery& query)
{
    QString str = QString("DB Error (%1):\n").arg(where);

    str += "Query was:\n";
    str += query.executedQuery() + "\n";
    str += QString::fromUtf8(DBErrorMessage(query.lastError()));
    VERBOSE(VB_IMPORTANT, QString("%1").arg(str));
}

... so I there still may be hope that this has been resolved, although I'm saying that with less certainty than I did earlier today :-). Regardless, if anyone is willing to try to keep digging, I'll do my best to support you all in your quest!

[Roy Thompson (roy-haematic)]

hey all, fyi I have rebuilt my mythtv from the 2.1 fixes branch with the new DBError function from trunk to see if printing out the bind values helps with diagnosing it.

I am still getting the problem every night so hopefully should have a better error message tomorrow.

Roy

[Kev Walke (kelvinelk)]

@MarcRandolph
No problem, and thanks for reopening.

@All with this bug
Do you all use EIT solely? Or do you use mythfilldatabase to get listings from elsewhere also?

[Roy Thompson (roy-haematic)]

@Kelvinelk

I use EIT only, no mythfilldatabase.

I have a log from it falling over last night, with bind values displayed, here is the first error message:

222yyyy-22MM-22dd 22hh:22mm:22ss.22zzz DB Error (Looking up chanID):
Query was:
SELECT chanid, useonairguide FROM channel, dtv_multiplex WHERE serviceid = :SERVICEID AND networkid = :NETWORKID AND transportid = :TRANSPORTID AND channel.mplexid = dtv_multiplex.mplexid AND channel.sourceid = :SOURCEID
Bindings were:
:NETWORKID=9018, :SERVICEID=23680, :SOURCEID=2, :TRANSPORTID=20480
Driver error was [2/1064]:
QMYSQL3: Unable to execute query
Database error was:
You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ':SERVICEID AND networkid = :NETWORKID AND transportid ' at line 1

After this it looks like every SQL statement fails and the backend is unresponsive from the frontend or mythweb.

Full log attached. Warning:it is 6 meg when uncompressed.

I can't see anything wrong with this query and it runs fine if I run it in mysql, although it does not return any rows.

Roy

[MarcRandolph (mrand)]

Howdy all, I kinda doubt it is a problem with the database or the query itself. The messed up date makes me think of something like a corrupted pointer - most likely in the EIT code since that is the point in common for you all. A corrupted pointer will result in lots things being messed up in memory, and the malformed date format string just happens to be one of them. I'm sure there could be other reasons, but that is my theory, and that is the reason I focused on the error message reporting function rather than database accesses (because some people see completely different database errors).

I assume that if you all stop and then restart the backend, the problem goes away until next occurrence (the next time the EIT code corrupts memory, if my theory is correct)?

[alistair (alistair-tyeurgain)]

I do not use mythfilldatabase - just the off-air schedules.

I have not had the problem recur since I changed to --nojobqueue - the backend has been up for days, now. If upstream really is not fixing this version, I am not keen to experiment by turning the option off again to see if the problem recurs, since I will get complaints from others about the backend service going down. I will try it if there is a chance it will do some good.

A

[MarcRandolph (mrand)]

It might or might not yield anything helpful, but someone might try running with with -v eit,siparser (either one or both) logging turned on overnight. Might produce some really large log files, so be sure to turn it off in the morning!

[Roy Thompson (roy-haematic)]

This is a log file with -v important,eit,siparser
snippet just before sql error appears again:

QSqlQuery::exec: empty query
2009-08-31 17:11:02.522 PESPacket: Failed CRC check 0x22161100 != 0xc3bfa4b5 for StreamID = 0x70
QSqlQuery::exec: empty query
QSqlQuery::exec: empty query
QSqlQuery::exec: empty query
QSqlQuery::exec: empty query
QSqlQuery::exec: empty query
2009-08-31 17:11:03.181 EITScanner (1): Added 28 EIT Events
QSqlQuery::exec: empty query
QSqlQuery::exec: empty query
QSqlQuery::exec: empty query
QSqlQuery::exec: empty query
QSqlQuery::exec: empty query
222yyyy-22MM-22dd 22hh:22mm:22ss.22zzz DB Error (Update next_record):
Query was:
UPDATE record SET next_record = '0000-00-00T00:00:00' WHERE recordid = :RECORDID;
Bindings were:
:RECORDID=143
Driver error was [2/1064]:
QMYSQL3: Unable to execute query
Database error was:
You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ':RECORDID' at line 1

full log file attached.
observations: can't see anything particularly different just before that error happens. There are lots of "PESPacket: Failed CRC check" messages, but those happened from soon after backend is started up not just when it fails.
After it starts to happen, all messages are prefixed with 222yyyy-22MM-22dd 22hh:22mm:22ss.22zzz rather than the correct date+timestamp.

[MarcRandolph (mrand)]

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 ev...

[alistair (alistair-tyeurgain)]

If I upgrade the backend, will existing front ends still work?

I have several front ends running on several distros and architectures (but not on the back-end machine), and upgrading them all at once would be a real pain. However, if they will still work, I can upgrade the back end, and then do the front ends as and when convenient.

A

[Kev Walke (kelvinelk)]

@alistair

I think it depends on whether myth protocol has changed or not. I have a minimyth frontend which ignores a change in myth protocol and attempts to connect anyway. Other implementations will vary and will likely not enable you to connect if there is a mismatch in the protocol.

@all
I have now been running for over a week with --nohousekeeper switch added to mythbackend. I have not had one instance of it crashing in this manner (kiss of death!!!) This is unheard of for my setup over the last couple of months or so.

[Roy Thompson (roy-haematic)]

Mine has now been running fine for 3 days with no errors (it would previously fail within 12 hours of startup). I am NOT using the --nohousekeeper flag.

I can only conclude at the moment that whatever wonky EIT data was being received, which triggered the issue, is now no longer being broadcast?

Roy

[Kev Walke (kelvinelk)]

Well, just as I was starting to forget about this bug, it happened again today! What a shame.

[MajorTom (2-launchpad-simpletcpip-com)]

Just a quick 'me too'. I'm also in the UK and use the DVB-S and DVB-T EIT exclusively. I've started having this once or twice a day since 2009-10-02, presumably because of something in the current EIT data - running mythbuntu with trunk 22179.

[alistair (alistair-tyeurgain)]

Does this coincide with the changes to some of the ITV channels that may require a channel re-scan?

I have been on holiday so the server has not been running but I read about this while I was away.

[Kev Walke (kelvinelk)]

@MajorTom and FAO MarcRandolph
So, looks like this issue affects trunk as well as 0.21-fixes. Perhaps upstream will pay attention to this bug now?

@Alistair
Yes it does coincide, but I rescanned on Thursday. Have you rescanned or seen the bug occur before or after scanning?

[MarcRandolph (mrand)]

I'll make another plea on the mailing lists for ideas on how to debug this further. In the mean time:

1. Please enable apport if you can. don't know if it will help or not
2. The most important thing is to grab logs of the failure on 0.22 systems with -v important,eit,siparser or if you can stand the file size, maybe -all

[MarcRandolph (mrand)]

Make that -v vbi,important,eit,siparser

[Mario Limonciello (superm1)]

OK, so in theory if you turn on the daily trunk builds rather than the karmic archive builds, you should get more debugging symbols built in. So first thing i'd recommend is visit http://mythbuntu.org/auto-builds and turn those on. Next if mythbackend isn't getting caught by apport, run it through gdb.

Follow the directions here:
https://wiki.ubuntu.com/Backtrace

You'll probably want to still run mythbackend as the user "mythtv" though, so to become that user, this is the command to do it:

$ sudo su mythtv -c bash

[Mario Limonciello (superm1)]

Alternatively (and it might be easier), follow the directions on that page to attach to the already running mythbackend process.

[Kev Walke (kelvinelk)]

Apport doesn't want to catch this. It says "The problem cannot be reported - This is not a genuine ubuntu package"

I will see if I can get the daily trunk builds going and attach gdb to mythtv-backend. Please be aware that this means the WAF may go through the floor as I iron out other issues I envisage along the way. If I haven't reported back in a week, be concerned. ;)

[Kev Walke (kelvinelk)]

Okay, apart from there not being an up-to-date and working minimyth for my diskless VIA frontend (WAF=gone through the floor), a desktop frontend that crashes on channel change (known, confirmed mythtv bug)
I am now running trunk with no issues and have gdb attached to the backend. ;) Watch this space

[Mario Limonciello (superm1)]

This will require some modifications to the package to support trunk daily
packages in apport unfortunately.

On Thu, Oct 8, 2009 at 07:16, Kelvinelk <email address hidden> wrote:

> Okay, apart from there not being an up-to-date and working minimyth for my
> diskless VIA frontend (WAF=gone through the floor), a desktop frontend that
> crashes on channel change (known, confirmed mythtv bug)
> I am now running trunk with no issues and have gdb attached to the backend.
> ;) Watch this space
>
> --
> mythbackend silently fails with QSqlQuery::exec: empty query
> https://bugs.launchpad.net/bugs/330272
> You received this bug notification because you are a member of MythTV
> Ubuntu Maintainers, which is subscribed to mythtv in ubuntu.
>

--
Mario Limonciello
<email address hidden>
Sent from Austin, Texas, United States

[MarcRandolph (mrand)]

Upstream closed this bug, probably with good reason. Haven't heard of this happening in recent versions, and even if we did, it would need to be reproduced and a backtrace caught on a 0.24, and preferrably 0.25 system. If this reoccurs, please open a new ticket.