Zero length recordings

From MythTV Official Wiki
Jump to: navigation, search

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.