The problem initially experienced was the MythTV web front-end failing to connect to the backend, producing a PHP error.
Upon reviewing the /var/log/mythtv/messages/mythbackend.log file, a great many of the following error messages were discovered:
2006-03-18 10:52:29.784 waiting for a thread.. 2006-03-18 10:52:29.795 waiting for a thread..
Upon Googling for the error message, the following email thread was discovered here:
[mythtv] Waiting for a thread backtrace
Mark irish at irishmark.co.uk
Thu Jul 7 04:12:22 EDT 2005
* Previous message: [mythtv] Waiting for a thread backtrace
* Next message: [mythtv] Waiting for a thread backtrace
* Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Isaac Richards wrote:
> On Wednesday 06 July 2005 05:20 pm, Mark wrote:
>
>>Not sure if this in any use at all, but I was running in GDB when I got
>>the old 'Waiting for a thread' problem, so gzipped a backtrace here:
>>http://irishmark.co.uk/myth-backtraces/waiting_for_thread.tar.gz
>>
>>This is from a master with 2 slaves, the master having recently been
>>restarted.
>
>
> Couple question:
>
> How current sources were these?
> It hung due to mythweb, right?
>From cvs of Jun 19th
I figured out why it was happening, there was a bad recording, so
whenever either a frontend selected the file in watch recordings, or
when mythweb tried the recorded_programs page it would do this.
Deleting the dodgy recording was the only way to stop it doing this
every time.
I've never seen it do this before for a bad or zero byte recording, so
it's possibly a one off.
Since MythTV was working fine the previous evening, the .nuv recordings that were made since then were moved from the /myth/tv directory to an arbitrary temp directory. The web front end was checked again, but the same failure occured.
The next step was to restart the mythtv-backend processes. The following command was executed:
/etc/init.d/mythtv-backend restart
The script did not give meaningful output, but at this point the web frontend started to work again.
Upon viewing the “Recorded Programs” link on the web page, the programs that were moved were still displayed, but without thumbnails. The .nuv files were moved back one by one. As each one was restored, the MythTV web front-end successfully regenerated the thumbnails. After all the files were restored, everything continued to work.
While the exact error is not obvious from this exercise, it appears to have not been a corrupt file as in the mailing list post. I suspect this was a case of memory exhaustion with shared memory, which would have been restored by the restart of the processes using that memory.
root@asrock:~# irw 000000037ff07be0 00 Down mceusb 000000037ff07be0 01 Down mceusb 000000037ff07be0 02 Down mceusb 000000037ff07be1 00 Up mceusb 000000037ff07be1 01 Up mceusb