Zero length recordings
Due to backend crashing
In the last year or so, my MythTV backend has been crashing regularly whenever a Freeview DVB-T program starts recording. Initially, I thought it was a degrading external antenna, because my system used to be rock solid before. However, after several Google search expeditions over the last few months, I have finally nailed down what the problem was. For the record, the motherboard is a ASUS P4S800D-X, with a P4 2.8GHz HT processor, with two Hauppauge Nova-T DVB cards (cx2388), each with 3 encoders, Ubuntu Desktop 11.04, located in the UK. (Hyperthreading is turned off in the BIOS because this upset mythTV many years ago, and I have not turned it on again.)To the present problem solution - I discovered from Ticket #9261 (http://code.mythtv.org/trac/ticket/9261) that the problem is likely to be in the EIT code, where a mutex lock is failing in some way. The solution, therefore, was to not use the EIT at all, turning it off on both tuner cards, and switching to the xmltv feed from the Radio Times on both cards. I subsequently had only one failed recording after that over a 2 day test period where I increased the number of programmes recorded to about 18 a day. After that failure, I then changed both tuner settings so that the cards are freed up between recordings, and I have not had another failure in the last 4 days with the test load. Perhaps when the card is opened for each recording, there is less chance that the lock is corrupted.
To catch the times that mythTV does crash, I have used the following home grown code successfully for a couple of years now:
#!/bin/bash LOG=/var/log/mythtv/mythbackend_http_monitor.log while [ 1 ] do # date "+%Y-%m-%d %H:%M:%S Cycle" >> $LOG if ps -ef | grep [m]ythbackend >/dev/null; then #backend running. NB brackets prevent grep cmd being counted #check http port wget -q --timeout=10 --tries=1 http://127.0.0.1:6544 -O /dev/null if [[ $? != 0 ]]; then #failed to get http date "+%Y-%m-%d %H:%M:%S Mythbackend 1st http response failure" >> $LOG sleep 5 #check again wget -q --timeout=10 --tries=1 http://127.0.0.1:6544 -O /dev/null if [[ $? != 0 ]]; then #failed to get http date "+%Y-%m-%d %H:%M:%S Mythbackend 2nd http response failure" >> $LOG sleep 5 #check again wget -q --timeout=10 --tries=1 http://127.0.0.1:6544 -O /dev/null if [[ $? != 0 ]]; then #failed to get http date "+%Y-%m-%d %H:%M:%S Mythbackend 3rd http response failure: restart" >> $LOG # Mythbackend has crashed, log and restart date "+%Y-%m-%d %H:%M:%S Restarting mythbackend" >> $LOG sudo service mythtv-backend restart sleep 60 else sleep 30 fi else sleep 30 fi else sleep 30 fi else sleep 30 fi done
Start the script from /etc/rc.local:
# start mythv monitoring, sleep first sleep 120 /usr/local/sbin/m-backend-http-monitor.sh &
Due to changes in tuner numbering
I have a DVB-S2 (dual) and a DVB-C tuner. What I didn't realise, was that the Linux kernel was not consistent in its numbering of the three adapters. When I set up the system, it had booted with S1 on 0, C on 1 and S2 on 2, but on subsequent boots, order was different. The symptom was then that seemingly randomly, I would get zero-length recordings.
When the recording fails, live TV didn't work either (obviously, now).
On occasion, when a recording had been important enough to me to check as it started, continual reboots were enough to get things going.
The system shut itself down and woke automatically, so it often rebooted several times a day. It often seems that either all or none of the recordings fail between a pair of adjacent reboots and the problem didn't seem to be channel-dependent.
The solution, as suggested on the mailing list<ref>http://www.mythtv.org/pipermail/mythtv-users/2014-January/358393.html</ref>, was to fix the allocation order by creating a .conf file (I called mine dvb.conf, but I think anything with .conf would probably do):
# Force consistent dvb adapter numbering for use with mythtv backend options ddbridge adapter_nr=0,2 options mantis_core adapter_nr=1
I had a false start because the adapters were named ddbridge and mantis in dmesg. The mantis-driven tuner then did not load at all. Checking the modules reported by lsmod then found the correct naming.