Building a MythTV PVR

MythTV backend setup

Up to now, this has all been about the system. Now one comes to setting up MythTV itself - a simpler task. Firstly, the backend.

Before the setup, certain changes have to be made.

Firstly it is intended that the recorded and other data will be stored in the data partition, mounted at /media/data. Initially MythTV stores all its data in /var/lib/mythtv and sub-directories. This tree was copied to /media/data (sudo cp -r /var/lib/mythtv /media/data), and then ownership of the tree set to mythtv (sudo chown -R mythtv:mythtv /media/data/mythtv). Finally the non-accessable space was reduced from the default 5% to 1% as this is not a boot partition (sudo tune2fs -m 1 /dev/sdann). 'sdann' was sda6 in my case.

Secondly the tuners to be used (PCTV 292e) need firmware to be loaded. The firmware files need to be stored in /lib/firmware and then they will be loaded automatically on tuner detection. There are two files - dvb-demod-si2168-02.fw and dvb-demod-si2168-b40-01.fw - depending on the kernel version, and these can be obtained from http://palosaari.fi/linux/v4l-dvb/firmware/Si2168/.

To set the tuners up it is necessary to (a) create a capture card for each physical tuner, (b) set up at least one video source (one only in this case) then (c) for each capture card, associate it with a video source.

Start the backend setup From Applications >> System. The backend itself will have to be stopped, for which you need a password, then you are just into the setup pages. These are simple enough, and I only mention things out of the ordinary or that had to be changed from default.

General

On the first page the only thing to set is the IP address (lcal and master). These should be set to whatever the IP address for the system is set to. This is one reason for not using DHCP for this system, no chance of its changing. One thing I did discover is that after installation, until MythTV is updated, the front end will not run with anything other than 127.0.0.1 here.

Under locale I set the TV format to PAL, VBI format to PAL teletext, and frequency table to 'try-all' (initially this was set to 'europe-west', but I could not get any HD channels - see later).

Nothing was then changed until the shutdown/wakeup options.

'Block shutdown before client connected' was cleared. It doesn't make much difference since Kodi is started automatically, but still.

Idle timeout was set to 900 seconds (15 minutes). That is the point when it will start to run the shutdown scripts.

'Startup before recording' was set to 300 seconds (5 minutes).

'Wakeup time format' is set to time_t - the backend will then use Unix time (seconds since 1/1/1970) as the time format.

'Command to set Wakeup Time' was set to sudo mythtv-setwaketime $time as previously described.

'Server halt command' was set to mythtv-suspend spd 40320. When using the suspend to RAM approach, the first parameter would have been str. The second is the delay time in seconds (12 hours). The purpose of this is that if there is nothing else set to do, or if the soonest recording is more than 12 hours away, it will wake in 12 hours anyway. This is to keep the program guide up to date by performing EPG grabbing (see later, EPG is obtained from the off air broadcast).

In point of fact, it appears that when 'automatically update program listings' was set up as described below, it automatically woke up every day at 4PM anyway (presumably to run mythfilldatabase), so it may be that the delay time is unnecessary.

'Pre Shutdown check-command' is set to mythtv-shutdowncheck. This and the previous scripts are all described in shutdown and wakeup.

Nothing was then changed until Job Queue (backend specific), where 'Allow commercial-detection jobs' was cleared. I do not run these at all.

Finally, under Program Schedule Downloading Options 'Automatically update program listings' was checked. Actually this seemed to make no difference at all with the 292e tuners, but as will be seen later, I changed to an HDHomeRun Connect, and with that, if this flag was not checked, there was no program guide. Don't see the difference. The 'Guide data program execution start / end' were set to 0 and 23 to allow it to run at any time.

Capture cards

The tuners initially used were 2x PCTV 292e USB tuners (which must be plugged in). Therefore two new cards were created here, one for each. In each case when 'DVB-T/S/C, ATSC or ISDB-T tuner card' was selected one was detected. No changes from default settings were made.

Recording profiles

Not touched.

Video sources

One video source was set up, this is set to grab the guide from the transmitted stream (EIT). Name was '292e-EIT', set to 'Transmitted guide only (EIT)'.

Input connections

Two input connections are needed, one per tuner. Names 292e-0 and 292e-1 were given. In each case, the video source 292e-EIT was selected.

Scan for channels was selected for the first one, the region united-kingdom was selected and scan for TV+radio. It will then scan all frequencies for available channels. It found all the SD channels but no HD ones (see later). For the second tuner, rather than rescan, the scan for the previous tuner was selected. Both tuners now have channels.

Channel editor

Under the editor, all the channels should be listed.

Storage directories

At the moment, all the directories will be set to their initial locations of /var/lib/mythtv/.... In this section, change each location in turn from /var/lib/mythtv/... to /media/data/mythtv/....

The HD channels problem

No HD channels were detected by the channel scan. On investigation it appears there is a problem with MythTV 0.27.6 or earlier, DVB/T2 multiplexes, and tuners using the Si2168 DVB-T/T2/C demodulator.

The older tuners such as the 290e (which did not use the Si2168) had a fudge put in the driver whereby if it tried to tune as DVB/T and that failed, it would automatically try DVB/T2. So the lack of full DVB/T2 support in MythTV didn't matter. This was known as 'auto-switching'.

However, when it came to the 292e driver (using the Si2168) the developer (Antti Palosaari) who wrote the driver decided the fudge had been there long enough, the application writers should have caught up, and did not include it. The result is the 292e on MythTV will currently not tune to DVB/T2 transports, whereas its predecessor the 290e did, and that includes the HD channels in the UK.

Therefore, using the open source driver in the kernel, it appears it is not possible to receive channels using DVB/T2 for tuners using the Si2168, until MythTV supports it. This may happen in 0.27.7, or failing that should happen in 0.28. (I believe there may be an alternative closed source driver, but I have not investigated it).

So, I tried using an HDHomeRun Connect instead. This is a dual tuner that sits on the network - it is not directly connected to the PVR except via ethernet. It therefore does not use a driver of the type the 292e tuners do.

The HDHR is designed to be connected to a router, get its IP address via DHCP, and therefore be available directly to all systems on that network. However the later versions can also connect via link local. I was not able to put it onto the network router because the cabling in the house does not allow it - the router and TV aerial cable are nowhere near each other. As well as that, the HDHR connects to its clients using UDP (datagrams). UDP does not establish a reliable connection (there is no acknowledgement), and it is really just a broadcast to anyone who would wish to listen. Therefore it seemed to me that to place it on a network for which the load is very variable would also risk lost packets and stream corruption.

It was therefore connected peer to peer directly into the wired ethernet socket (eth0) on the motherboard - it is the only device on this link. To get this to work wired ethernet must be set to link local (using Applications >> Services >> Network connections), and that is all there is to it (a crossover 100baseT cable is not required). Note that it is only visible to this system, but that is OK because the backend will manage it for everyone else. Once plugged in, IP addresses in the range 169.254.x.x will be negotiated for the HDHR and eth0. To check if it has connected, open a terminal window and run the command hdhomerun_config discover. This utility is installed already with the system and it should list any HDHRs found.

There is however one big problem. Before the backend starts, all tuners must be running and discovered. If they are not, the backend will not be aware of them. Since this system boots up autonomously with no user intervention, it is important that the HDHR IP addresses are working and the device is available before the backend is started. Unfortunately, the link local IP address allocation process can take in excess of 20 seconds and by that time the backend has started.

Initially it was thought best to set manual IP addresses as they would be there immediately, but this HDHR does not support that (most HDHR models do not). In the end the mechod used was to delay the start of the backend in mythtv-backend.conf. This is the Upstart script that runs the backend as a daemon. There is a lot of information on Upstart, but basically this script runs a pre-start section, then on completion, runs the main script section that starts the daemon.

All this does is sit in a loop (sleeping) checking for the presence of an HDHR. If it finds one it exits with code 0, if it doesn't (times out in 40 seconds), it exits with code 1. Fortunately hdhomerun_config returns 0 if it finds one, 1 if it doesn't. It also uses the file /home/pvr/.mythtv/findhdhr to decide whether to test or not - effectively this is a switch, create it and the test will run, get rid of it and it will not.

The Upstart script /etc/init/mythtv-backend.conf was replaced by this slightly modified one:

There is very little difference: the first line in the pre-start script area was added and is where the test is run. Note that since the test can return 0 or 1, and as any error return will abort the script, it is treated as always returning success (the || true). The script writes to a logfile and one extra line echo "Starting backend" >> /var/log/mythtv/hwclock-WakeTime.log was added to the main script before running the backend daemon to log the start to the same logfile.

Some warnings about Upstart, and especially the expect stanza:

Firstly, script sections are run by the bourne shell and are configured to abort on any error (hence the point above about the return code of the HDHR finding script).

Secondly, If a daemon is being run as in this case, Upstart needs to track its PID. If any command that spawns a process is put in the main script before mythbackend, Upstart will track the wrong PID. For instance if that extra line were changed as simply as echo "`date` : Starting backend" >> /var/log/mythtv/hwclock-WakeTime.log it all goes wrong because Upstart is now watching date, not mythbackend. An indication that this has happened comes when the system shuts down - it will probably sit there for around 5 minutes until Upstart times out. It is worth reading carefully how the expect stanza works, as it is all explained there.

However the script as shown here does work, and it is now necessary to reconfigure the backend for the HDHR. The 292e tuners were removed, the HDHR fitted, and channels, capture cards, video sources and input connections were deleted, then the backend was reconfigured.

The capture cards are now type 'HDHomeRun networked tuner' and were detected (two set up, one per tuner). Changes made in recording options were to set signal timeout to 4000ms and Tuning timeout to 8000ms as it seems slower to tuns than a 292e. Max recording was set to 3. In fact, Silicon Dust say only one channel per multiplex can be used, so initially I set this to 1. The problem with that is that the backend appears to allocate 'n' virtual tuners to each physical tuner (the 'n' being this number). If you are recording, that uses one, if you watch the same channel live, that uses another, so you quickly run out (you can see the usage by looking at the status page in MythWeb). In point of fact, the HDHR seems to accept more than one channel per multiplex despite what Silicon Dust say (I did manage to watch 3x different HD channels all from the same tuner). Logically one would expect the backend to realise two client usages as above are really the same stream and just get it from the backend once, but it doesn't seem to, or at least, that is not how the information is presented. Either way it seems to work with a 3 in there. Note also that there is no option under recording options to say 'use this tuner for EIT' - but it seems to happen anyway.

The video source was set as for the 292e tuners (EIT) but called HDHR-EIT.

Two input sources (one per tuner) were set up as before, and the channels scanned.

And - no HD channels.

At this stage I still had the frequency table in the general section set to 'europe-west'. I found that by changing it to 'try-all' and rescanning, I did get HD channels - but not all of them. After some checking I found that everything on the PSB 3 multiplex was missing. This multiplex is at 474MHz and uses QAM-256 encoding. I raised a bug and after some discussion with developers found that there is no hard coded frequency table. Instead the scanner tries a range of frequencies (presumably controlled by the frequency table setting). Each multiplex should return a list of all other multiplexes and their encoding. 474MHz is at the bottom of the frequency range scanned, and the scanner works from the bottom upwards.

My suspicion as to what is happening is that 474MHz is scanned using QAM-64 and nothing is found. The scanner moves on. When it gets to the next multiplex (which is QAM-64) it finds out that actually there was a multiplex at 474MHz but it was QAM-256 - but by that time it has passed that frequency, and it does not go back, so it is never found.

To be fair the developers didn't agree with this and said it was more likely I was picking up erroneous information from some other transmitter. I am pretty sure that was not happening, and the fact is that when I went into the channel editor, edit transports, added a new multiplex set as ATSC, 474000000 and QAM-256, then deleted all channels and rescanned, it did find all available HD channels, including that PSB 3 multiplex.

It is also true that I never did try the 292e tuners with the 'try-all' frequency table, but I don't think it will have an effect, especially given that there is a logged bug (#12514) on this due for fix in 0.27.7 or 0.28.

So that was it really, the backend is set up, it does recognise the HDHR from a cold start, and it does find HD channels. Probably however when MythTV does support tuners using the Si2168, I will switch back to the 292e tuners.