But glab to hear you fixed your problem.
Yeah I agree. Sad to say, that the error reoccours when I record, so the patch isn't available for the 0,23.1 version. Will try to upgrade til .24 in the easter and see if this makes a difference.
Hopefully the fix is included here, as I would hate to run the SQL command after each recording.
If it turns out that the upgrade is inconvenient or fails to solve the issue on its own, it would seem that you could set the MySQL command up as a myth user job that would run automatically after every recording. Not the most elegant solution, but would keep the issue out of your hair.
I've been fighting this same problem today. rvindum's suggestion (UPDATE recorded SET subtitle=REPLACE(subtitle, '\0', '');) sounded familiar and has worked for me before, but not this time.
Relevant portion of my log file:
2013-03-31 09:38:05.031 RemoteGetRecordingList() list size appears to be incorrect.
2013-03-31 09:38:05.078 PlaybackBox Error: SortedList is Empty
"UPDATE recorded SET subtitle=REPLACE(subtitle, '\0', '');" covers the "subtitle" field of the "recorded" table. Other fields can have the offending "\0" character. In my case, it was in the "name" field of the "channel" table. The query that was needed was
UPDATE channel SET name=REPLACE(name,'\0','');
Perhaps the long story will help someone debug another problem. So, here it is...
To track down the problem, I did the following:
1) Copied the "recorded" MySQL table to a backup copy ("CREATE TABLE recorded_BACKUP SELECT * FROM recorded;")
2) Deleted a select few entries in the "recorded" MySQL table using MySQL "DELETE FROM recorded WHERE ...;" commands.
3) Re-opened MythTV's "Watch Recordings" screen, checked to see if any recordings appeared, then escaped back out of that screen.
4) Repeated steps 2 and 3 until the "Watch Recordings" screen worked. (IMPORTANT: You can't just leave the "Watch Recordings" screen open--you have to close it and, after each "DELETE FROM recorded WHERE ...;" command, reopen it.)
5) Found the problem was an entry using ChanID 4391.
6) Restored that entry from the backup table ("INSERT INTO recorded SELECT * FROM recorded_BACKUP WHERE chanid=4391;").
7) Studied the data in that entry ("SELECT * FROM recorded WHERE chanid=4391 \G") to find out what was wrong. "UPDATE recorded SET subtitle=REPLACE(subtitle, '\0', '');" had already been done, and I had even run it on other fields...
"UPDATE recorded SET title=REPLACE(title,'\0','');"
"UPDATE recorded SET description=REPLACE(description,'\0','');"
So, I was looking for something new. I didn't find anything in this step.
8) Somewhere through googling, I found a suggestion to run mysqldump and study the data in the resulting file. So, I exited out of mysql, then I ran "mysqldump --extended-insert=FALSE -u[username] -p[password] mythconverg > mythconverg_debug.sql".
9) Opened Step 8's mythconverg_debug.sql in a text editor.
10) Knowing the offending entry had to do with chanid 4391, I ran a search in that text editor for "4391".
This took me straight to the problem--the very first hit was the following line.
INSERT INTO `channel` VALUES (4391,'39_1','39',4,'KSVN','Azteca\0\0\0\0\0\0\0\0 \0\0\0\0\0\0','',NULL,'','',0,32768,32768,32768,32 768,'ATSC',1,'',1,8,1,0,39,1,'0000-00-00 00:00:00','',-1);
Note the evil "\0" that occurs 14 times on that line. A quick "UPDATE channel SET name=REPLACE(name,'\0','');" (or simply "UPDATE channel SET name='Azteca' WHERE chanid=4391;") fixed the problem.
11) Restored all the entries from Step 1's backup table.
"DELETE FROM recorded;"
"INSERT INTO recorded SELECT * FROM recorded_BACKUP;"
"DROP TABLE recorded_BACKUP;"
Perhaps those steps can help others get through this problem, and perhaps the "mysqldump" idea from Step 8 can help someone diagnose other data problems. Or, more likely, perhaps this post will come up in a Google search the next time I have this problem and can't remember how in the world I fixed it. :-)
Thread closed. Please do not post in old threads.