Watch recordings screen will not load if bookmark column contains "invalid" value

[skd5aner <skd5aner@…>]

Recently upgraded to .22-fixes (r22670) from .21-fixes. It may also be of value to let you know that I've been using myth since ~.13 or .14 and the database has been updated from every version since then.

When I launched watched recordings for the first time, I saw no videos. However, the filters list showed 341 videos. In the console, I received a message that said: "sortedlist is empty".

After searching the archives, I came across this: ​http://www.gossamer-threads.com/lists/mythtv/dev/366940?search_string=sortedlist%20is%20empty;#366940 - it appears they had the same problem.

Going into the database, I had 1 recording (the oldest and first record) from 2005 where the bookmark value was set to 127. I manually changed it to 1, and then my watched recording screen loaded as expected.

This can be easily replicated, and wagnerrp in IRC was able to replicate it as well by just changing one recording to have a bookmark value of 127.

First off, no clue how/why that would have received a value of 127. I do not have any custom patches or 3'rd party components. I guess there are really 2 problems, 1) How/Why? did it set the value to 127 and 2) if there is an "invalid" entry, that probably shouldn't prevent the loading of the watch recordings list.

If there's any other data I can provide to help diagnose/troubleshoot let me know.

[skd5aner <skd5aner@…>]

related to #2293 ?

[sphery]

This issue is due to a bug in Qt4 that causes QSqlQuery::next() to fail on a record containing a TINYINT(1) field where the column value is less than -9 or greater than 99.

After discussion in IRC, we have decided not to work around the Qt bug in MythTV at this time. If a lot more users than we expect experience this issue, we will consider adding a workaround.

The only users who could possibly be affected by this issue (ignoring the possibility of users manually editing DB data) are users who upgraded to trunk MythTV between [9270] (Mar 6, 2006 05:30:05 AM) and [11016] (Sep 2, 2006 08:59:13 AM) and who still have recordings more than 3 years and 2 months old. Further, most of those users no longer have the invalid data in their databases. The invalid data will only exist for users who:

• Upgraded to trunk between [9270] and [11016] (both changes during the 0.19 to 0.20 development cycle
• Had one or more recordings with bookmarks set at the time
• Still have one or more of those recordings that had bookmarks
• Have never changed the bookmark on the recording(s)

Any users who experience the issue may fix their data by running:

mysql -umythtv -p mythconverg -e "UPDATE recorded SET bookmark = 1 WHERE bookmark != 0;"

Please feel free to mention to me in IRC (sphery) or send a message to the list if you are affected by this issue.

Thanks to Matt S., Brad Templeton, and Kevin Khupal for the identifying the invalid data that tripped the Qt bug, and to Matt S. for reporting the issue so we could fully understand what's happening.

(Note for me: Likely workaround would be to modify all queries in 0.22-fixes that access the bookmark field to use "bookmark + 0" rather than "bookmark" to retrieve the field contents and add an appropriate comment explaining the hack; then add a DB update to trunk to "UPDATE recorded SET bookmark = 1 WHERE bookmark != 0;" so that the workaround/hack is not necessary in trunk going forward.)

[anonymous]

This is pretty annoying. I spent 4 hours today tracing through the code trying to figure out why query.next() was aborting early.

It would be really nice if the upgrade path would fix the sql database properly.

[sphery]

As a follow-up, I wanted to mention that I wrote a couple of patches for Qt to fix bugs identified when diagnosing this issue. Bug reports and patches are at ​http://bugreports.qt.nokia.com/browse/QTBUG-5758 and ​http://bugreports.qt.nokia.com/browse/QTBUG-5765 .

With the patch for QTBUG-5765 applied, the reported failure in MythTV does not occur. Without that patch, all columns defined in the mythconverg schema with a specified display width could potentially be affected by the Qt bug. However, since we've only had reports of failures with invalid data in the bookmark field for users with old data and a certain usage history, it's very unlikely that anyone has any other data that does not fit within the requested display width. Therefore, there's no reason for users (or distros) to feel they must patch their Qt installation.

Again, any user who encounters this issue should run the above mysql command to fix the data in the bookmark field and let me know that you were affected. (So far, I only know of 4--possibly 5, depending on who anonymous, above, is--users affected.)

[stuartm]

No 'me too's in tickets please.

[sphery]

(In [23159]) Fix invalid values for recorded.bookmark to prevent triggering the Qt bug causing the issue on #7467 for anyone who goes from 0.21-fixes straight to this trunk revision or higher. (And, as it turns out, a DB update to prove [23158] works. :) Refs #7467.

[sphery]

Note, also, the Qt bug is fixed in Qt 4.6.3 or higher, so this issue will not affect even 0.23-fixes (or below) users running MythTV with Qt 4.6.3+.