MythTV DVB Setup Guide Part 2

Compiled by Martin Smith
V0.20 March 2005 (For MythTV Version 0.17)

Hardware Working? Now What?

If you read part one of this document you'll remember that it focussed on getting the DVB hardware installed and working. Before going any further you should have a card that functions correctly with the DVB utilities outside of the MythTV environment.

SInce this document was first written the DVB support in MythTV has been steadily improving and gaining features. There is currently no need to run a CVS version just to work with DVB. Release versions should work just fine.

With the 0.17 release of MythTV there is now support for automatically scanning the DVB channels. This makes setting up a new system much easier but complicates an update from a previous version.

This document will concentrate on getting MythTV working with the new hardware. The aim is to migrate from the initial configuration of MythTV with a single PVR 250 capture card to the final configuration of two budget Nova cards for DVB-T. To reduce the risk and impact of doing this we'll first bring in one DVB card alongside the analogue one. When we're happy it's stable and working correctly then we'll swap out the old card.

I've become pretty attached to my Myth system, which is the reason for taking the cautious route to upgrading it. I really want to see DVB working before making the big jump from what I've got now. Also I have a primary rule of thumb for system administration. This can be summed up as: never do anything you can't easily undo unless you have no other choices left.

This document concentrates on DVB-T because that's the hardware I have. Some if it may well apply to satellite and cable but I'd be speculating if I wrote about things I can't test in practice.

Myth DVB support is also evolving fairly rapidly at the moment. It's possible that things I've written about may change before I get chance to update this document. Please bear this in mind.

Having got my system relatively stable I am now pretty happy with DVB on MythTV. There are some occasional errors in the streams but the picture quality overall is much better than I ever got with analogue.

Backup the MySQL Database

This is a good thing to do at intervals anyway but especially before making major changes to the system configuration.  It can be as simple as:
mysqldump -c -a -p mythconverg > /somewhere_safe/mythsql.dump
The backup file may be quite large, my current backup ended up at 25MBytes.

BTW If you have a habit of using /tmp to store backups or other useful things it's never too soon to break it. One day you'll find yourself using a Solaris machine where /tmp is in memory or another operating system where /tmp is cleaned out at boot time. I've done both of these in my time.

Enable MythTV DVB Support

If you built MythTV without DVB support you'll have to enable it now and recompile. Edit the file settings.pro in the top level mythtv directory. Find the DVB section and uncomment the lines. Edit the INCLUDEPATH line to point to the directory where you have the DVB driver source code. For example I have this:
# DVB support
CONFIG += using_dvb
DEFINES += USING_DVB
INCLUDEPATH += /opt/DVB-Kernel/dvb-kernel/linux/include

MythTV 0.17 and later includes a new option DVB_USING_EIT. This allows the use of the broadcast programme guide information. If you want to enable this then uncomment it in settings.pro.

Now run make distclean followed by make install. The compilation process may take a while but should not produce any errors. If there are any a likely cause is mistyping the path to the include directory.

If you're using the new 2.6 Linux Kernel then things are slightly different because it comes with the DVB drivers. You may not need to download them separately. Please read this section for notes about 2.6.

Load DVB Drivers at Boot Time

Last time when we were testing the card we manually loaded the DVB driver modules. Now we want them to load each time the machine starts or the DVB card is used. This can either be done by editing the /etc/modules.conf file or by manually running a script to insert the correct modules.

For the moment we'll use a script while we get everything working. If you haven't already done so run make install in the build-2.4 directory where the DVB driver source is located followed by depmod -a.

Now take the insmod.sh script and make a copy of it. Remove all the lines that refer to frontend chips that you don't have on your card(s) or to types of cards you don't have in your system. In my case I'm left with one of the Grundig frontends and the TDA10045 frontend. Both my cards a Nova-T models so I also need the modules for a PCI budget card plus the core DVB modules. One of the cards has a CAM interface connector and needs a slightly different module.

This gives me the following:
#!/bin/sh
#
# Load DVB Modules
#
modprobe v4l1-compat
modprobe v4l2-common
modprobe video-buf
modprobe dvb-core
modprobe grundig_29504-401
modprobe tda1004x
modprobe saa7146
modprobe saa7146_vv
modprobe ttpci-eeprom
modprobe dvb-ttpci-budget
modprobe dvb-ttpci-budget-ci
If you're using the 2.6 kernel the names have changed slightly. The last two lines become:
modprobe budget
modprobe budget-ci
Now arrange for this script to be executed as root towards the end of your boot sequence. It mythbackend is started automatically it needs to be run before the backend starts. Details of how to do this vary according to distribution. In many cases it can be placed in /etc/init.d and symlinked from /etc/rc5.d/S99localdvb. Consult the documentation for your Linux system for the correct way to do this.

Now reboot the machine. Run /sbin/lsmod and check that the modules listed above are present. Also run dmesg and check that they were loaded and the drivers registered adapters and frontends correctly. If everything worked during testing there should be no problems now because the process is essentially the same.

Now start the mythtv backend manually if it doesn't auto start on your setup.

Setting Up Channels

Note: If you are not migrating from an existing analogue set up then you can ignore this section and instead use the channel editor (or automatic scan in MythTV 0.17 or later) to setup your channels from scratch when setting up the card.

Note 2: The problem stopping the channel editor from editing DVB information with a mixture of card types in the system has now been fixed.

With MythTV 0.17 channel setup has been largely automated. It should now be possible to configure a DVB card without having to use SQL to manipulate the database manually at all. I've left the old documentation present below for now as it provides some information on the database layout.

If you are upgrading from 0.16 go to the first section "Upgrading a 0.16 Database" if you want to retain your existing channels. Otherwise you will have to re-enter xmltvids, favourites etc. and reset recording schedules among other things.

For 0.17 or later follow the first section "Scanning for Channels - The Really Easy Way". To use the channel editor method follow the directions in "The Channel Editor Way" below, to do things by hand jump to "The Hard Way".

Upgrading a 0.16 Database to 0.17

Prior to version 0.17 of MythTV DVB tuning data was channel specific and fixed PIDs were stored in the database. The newer code stores details of the DVB multiplexes in the database and scans for the PID values dynamically when a channel is selected. This meant several structural changes to the old database that need to be sorted out before it will work with the new code.

You can tell if this is the case for your setup if you have a dvb_channel table containing a row for each channel and no dtv_multiplex table. If so follow these steps to upgrade:

Shut down the backend. Back up the whole database - very important in case something goes wrong at any point. For example use the command:

$ mysqldump -a -c mythconverg > /home/mythtv/pre017.dump

Make a separate backup of just the data for the three tables: channel, dvb_channel and dvb_pids in the old schema. Use something like:

$ mysqldump -a -c mythconverg channel dvb_channel dvb_pids > /home/mythtv/channels.sql

Upgrade to and install the latest version of MythTV. This will either be 0.17 or current CVS depending on your installation.

Start the backend to get the database schema updates. There should be no errors from the schema upgrade but for the moment ignore any errors about missing database entries when it tries to tune. Stop the backend again when the database has been upgraded..

Make sure the dvb_channel table still exists. If the update removed it then restore it from your backup and keep it around until the following steps have been completed.

Now we have an empty dtv_multiplex table and new columns serviceid and mplexid in channel that need to be populated before we can use the system again.

The dtv_multiplex table contains some fields that are not present in the older version of the data so rather than try and convert the data over we'll use scan to fill in the multiplexes and avoid error prone scripting and cutting and pasting from tzap config files.

Run the setup program, go into the setup program and do a full scan. You will need to enter the frequency of one of the transports. Pick one from the values of frequency in the dvb_channel table. Let the scan proceed and it should find the set of available channels. This should have populated the dtv_multiplex table. In my case there were six rows in it after the scan.

Now get rid of the duplicate channels this will have created. You might want to save a copy in case there are new channels that were not present before. These can be added later with the channel editor. The duplicates will have the highest ids so this should show them up.

SELECT chanid,name FROM channel ORDER BY chanid;

If the first duplicate channel was id 194 then this command removes them:

DELETE FROM channel WHERE chanid >= 194;

To fix up the mplexid and serviceid columns carry out one of the following procedures depending on whether you are running MySQL version 3 or 4. Sorry for the pantomime with V3 but I couldn't see a better way of doing it given that it doesn't support multiple table updates.

MySQL 4 (the sensible way):

UPDATE channel,dvb_channel SET channel.serviceid = dvb_channel.service id
WHERE channel.chanid = dvb_channel.serviceid;

UPDATE channel,dvb_channel,dtv_multiplex SET channel.mplexid = dtv_multiplex.mplexid
WHERE channel.chanid = dvb_channel.chanid
AND dvb_channel.frequency = dtv_multiplex.frequency;

MySQL 3 (the silly way):

ALTER TABLE channel DROP COLUMN mplexid;
ALTER TABLE channel DROP COLUMN serviceid;
ALTER TABLE channel DROP COLUMN atscsrcid;

CREATE TABLE newchannel AS
SELECT channel.*,dtv_multiplex.mplexid,dvb_channel.serviceid
FROM channel,dvb_channel,dtv_multiplex
WHERE channel.chanid = dvb_channel.chanid
AND dtv_multiplex.frequency = dvb_channel.frequency;

ALTER TABLE newchannel ADD COLUMN atscsrcid int(11) DEFAULT null;

ALTER TABLE channel RENAME oldchannel;
ALTER TABLE newchannel RENAME channel;
DROP TABLE oldchannel;

Once this has been done the database is now ready for use with 0.17. Start the backend again and it should tune properly. Now run the frontend and drop into live tv. Everything should now be working.

You can now remove the dvb_channel and dvb_pids tables if you want though it doesn't do any harm to leave them there for now.

Scanning for Channels - The Really Easy Way (MythTV 0.17 and Later)

The process is now largely automatic. Start the MythTV setup progam. If you have existing channels that you want to get rid of and start again answer 'Y' to this question when asked. Note this is not advisable on an existing and heavily used setup as you will lose recording schedules etc. Once this has been done add the input source and connection to enable channel scanning.

Now go to the channel editor. Press 'Scan' and select the 'Full Scan'' options. You will need to enter the frequency of one of the DVB transports. You can get this from the channels.conf file we created with tzap earlier on. For example run this:
grep "BBC ONE" ~/.tzap/channels.conf | cut -f2 -d:
Paste the number that this prints into the frequency box. In most cases the other settings can be left at 'Auto'. Older cards may need them to be specified. If so then these parameters can also be derived from channels.conf.

Now start the scan and watch the progress. If all goes well then when the scan completes all the channels will be configured in the system. All you need to do now is review them and set the 'visible' and 'commercial free' flags appropriately to your needs.

The Channel Editor Way

Before you can use the channel editor the card must be configured and given a video source. Until this has been done the DVB parameter pages will not be shown by the channel editor.

The details on how to do this continue in the section below entitled Add Capture Card to MythTV. The following section relating to manual database inserts can be skipped entirely though you may want to glance at it as it covers the relation between the channels.conf file and the parameters that have to be entered into MythTV..

Once the card has been configured the channel editor can be used to enter DVB information both for existing channels and new ones. Examples of doing this and screenshots can be found in the section below called Adding the Remaining Freeview Channels.

I've now made a copy of my database tables available for channel, dvb_channel and dvb_pids. This is the for the Crystal Palace transmitter here in the UK and shows the necessary values to configure some of the channels.

The Hard Way

When I first tried to set up DVB I found an issue with the channel editor that stopped me using it (this has long since been fixed). I also wanted to carry out these initial steps without affecting my current analogue setup so I decided to add the DVB parameters for the 5 channels via SQL.

Note: This is now obsolete. None of this section applies to MythTV 0.17

First a record must be added to the dvb_channel table that specifies the DVB transmission parameters. Then a record must be added to dvb_pids for both the video and audio streams. I'm using the Crystal Palace transmitter and in my case for the BBC1 Channel I ran the following SQL:
USE mythconverg;
-- structure of dvb_channel
-- chanid | serviceid | networkid | providerid | transportid | frequency | 
-- inversion | symbolrate | fec  | polarity | satid | modulation | bandwidth |
-- lp_code_rate | transmission_mode | guard_interval | hierarchy |

INSERT INTO dvb_channel VALUES (1000,4164,NULL,NULL,NULL,
				505833330,'0',NULL,'3/4','h',0,
				'qam_16','8','3/4','2','1/32','n');

INSERT INTO dvb_pids VALUES (1000,600,'v','');
INSERT INTO dvb_pids VALUES (1000,601,'a','');
The explanation of that is fairly straightforward, if you understand DVB parameters. Almost all the values come from the channels.conf file we obtained from the scan utility back in part one.

The exception is the channel id. In my case 1000 is the existing channel id for BBC1 in the channel table. Yours will most likely be different. To find it use SELECT chanid,name,callsign FROM channel; and use the appropriate chanid.  The second field inserted is the service id. This is the last field in a channels.conf entry for DVB-T. Take a look at the corresponding line from my channels.conf:
BBC ONE:505833330:INVERSION_OFF:BANDWIDTH_8_MHZ:FEC_3_4:FEC_3_4:QAM_16:
TRANSMISSION_MODE_2K:GUARD_INTERVAL_1_32:HIERARCHY_NONE:600:601:4164
The remaining parameters in the first line of the insert are not available and are left as null. On to the others now. In some cases you can leave them at 'a' or 'auto'. However some frontend chips can't handle automatic parameter detection. In my case the TDA10045 frontend does but the Grundig doesn't so I've explicitly entered all the fields. Bear this in mind if you use the channel editor in Myth. All the fields for DVB default to Auto. This doesn't mean they'll work with your card, though most newer cards do.  Specifying all the parameters explicitly is always safe and should work on any card.

The second line of values inserts the frequency, inversion, symbolrate (not needed for DVB-T), fec (hp_code_rate), polarity (ignored for DVB-T anyway) and satid (ignored again).

The third line of the insert has the modulation, lp_code_rate, transmission_mode, guard_interval and hierarchy. In the example above as for many UK Freeview channels the hp_code_rate and lp_code_rate are the same. If not then the ordering of the columns in the scan output is the hp_code_rate followed by the lp_code_rate. For example for my Channel 4 setting:

Channel 4:481833330:INVERSION_OFF:BANDWIDTH_8_MHZ:FEC_2_3:FEC_1_2:QAM_64:
TRANSMISSION_MODE_2K:GUARD_INTERVAL_1_32:HIERARCHY_NONE:2827:2828:8384

The hp_code_rate is FEC_2_3 and the lp_code_rate is FEC_1_2 and these are the values you should enter into the channel setup form (described later).

The two lines inserting pid entries adds the video and audio pid values for this channel, again they come from the channels.conf file as the two entries before the service id.

At this point I didn't modify the XMLTV configuration because it's already collecting data for the channels being configured. I added entries for the other 4 channels I intended to use to start with in a similar manner to the example above.

Add Capture Card To MythTV

Now we can run the MythTV setup program and add the DVB card. Select the second option from the menu and choose the type corresponding to a DVB card. If this is your first or only card it should be number zero as prefilled in the card number slot. You should now see it display the frontend type of the card.

At this point the advanced menu allows you several options including one to do a signal test. You can do this if you like but we've already verified this back in part one so it's not really necessary. I also have some doubts whether all the frontend drivers correctly report this value. My card comes up at strength 19% on BBC1 which seems unlikely to be right as I also have a DVB set top box that reports a much higher figure.

I'm using an existing video source so I didn't need to add one. If you're starting from scratch you'll need to configure one. Details of doing this are in the main MythTV documentation.

Next go to the Input Connections option and connect the DVB card input to the data source. In my case this is called TV so this is what I set up. I entered a start channel of 33, which is analogue channel number of the existing BBC 1 channel in my database. If this isn't set to something valid then you'll see an error when myth starts as it tries to tune in the channel.

Now stop and restart the myth backend. The card should be initialised. You should see a message like this printed out by mythbackend:
2004-01-06 15:43:24 DVB#0 Using DVB card 0, with frontend Grundig 29504-401.
2004-01-06 15:43:24 mythbackend version: 0.14.20040102-1 www.mythtv.org
2004-01-06 15:43:24 Enabled verbose msgs : important general
Typical errors that can occur at this point relate to failures of the channel parameter check or incorrect channel values. For example if the tuning fails and no lock is obtained check the frequency. One of the channels I configured had a missing zero digit from the frequency. If the backend complains that parameters are invalid then recheck what was entered into the dvb_channel table for that channel.

If your card is slow to tune you may see a "Warning - Status: NO LOCK!" message. This is nothing to worry about as long as you don't then see a message about having failed to tune a channel.

One note of caution is that not all the channels available broadcast all the time, at least on Freeview. If you run scan during times when they are off air then they will give PID values of zero, at least here in the UK. These are not the actual PIDs and should not be used - they won't work. Wait for the channel to start broadcasting again and then rerun scan. You will then get the correct values.

At this point my system had two working capture devices so I tried out the picture in picture option for live TV. Seeing that this seemed to work I moved on to some more testing.

Testing the Card

I decided on two types of testing. A watching live TV test and a dual recording test. I broke the live tv test into a couple of cases. One was just leaving it running, the other was picture in picture or live tv while recording.

In all cases I'm looking for errors in the DVB stream reported by the card as 'transport stream continuity errors'. These indicate that there was a glitch in the stream. This could be for several reasons including a marginal signal, a driver error or a PCI issue.I mentioned in part 1 that the DVB cards (particularly 'budget' models like the Nova-T) use the PCI bus to make large DMA transfers and this can cause issues resulting in corrupt pictures.

For the record the hardware in my system is an Athlon 1800XP in an AOpen MK77 Micro ATX motherboard and 512MB of RAM. I've considered upgrading but the cooling in the current case is poor and I'm still trying to obtain a proper hi-fi  style case.

I've done a couple of tests, initially with inconclusive results but now looking more promising. I've just made some recordings off the card that look good but I still need to review them so I'll be updating this section of the document soon.

For now this is the kind of log messages that you should see for a successful recording. Note the Status: NO LOCK! means that the card took slightly longer to tune than Myth expected. This isn't a serious problem as the card is given a couple of chances to complete the operation.
2004-01-06 23:15:54 Started recording "The Warzone:Secrets of World War II" on channel: 1934 on cardid: 3, sourceid 1
2004-01-06 23:15:54 Changing from None to RecordingOnly
2004-01-06 23:15:54 DVB#0 WARNING - Status: NO LOCK!
2004-01-06 23:15:54 Changing from None to RecordingOnly
2004-01-06 23:15:54 DVB#0 Recorder: Card opened successfully.
Audiostream: Layer: 2  BRate: 192 kb/s  Freq: 48.0 kHz
Videostream: ASPECT: 4:3  Size = 720x576  FRate: 25 fps  BRate: 6.00 Mbit/s
2004-01-06 23:23:00 Changing from RecordingOnly to None
This is what happens when there are errors with the transport stream:
2004-01-09 19:30:02 Started recording "The Big Question with Ian Stewart" on channel: 1004 on cardid: 3, sourceid 1
2004-01-09 19:30:03 Changing from None to RecordingOnly
2004-01-09 19:30:03 DVB#0 WARNING - Status: NO LOCK!
2004-01-09 19:30:04 Changing from None to RecordingOnly
2004-01-09 19:30:04 DVB#0 Recorder: Card opened successfully.
Audiostream: Layer: 1  BRate: 96 kb/s  Freq: 48.0 kHz
Videostream: ASPECT: 16:9  Size = 720x576  FRate: 25 fps  BRate: 3.20 Mbit/s
2004-01-09 20:00:48 DVB#0 WARNING - Transport Stream Continuity Error. PID = 6017
2004-01-09 20:00:49 DVB#0 WARNING - Transport Stream Continuity Error. PID = 6017
2004-01-09 20:00:49 DVB#0 WARNING - Transport Stream Continuity Error. PID = 6017
2004-01-09 20:00:50 DVB#0 WARNING - Transport Stream Continuity Error. PID = 6017
2004-01-09 20:03:00 Changing from RecordingOnly to None
There were four occasions when we had a break in the stream. What this can't tell us, and it's frankly difficult to find out by other means, why the stream had these errors. There are many possibilities such as:
It's important not to leap to conclusions about what the problem really is. It's also worth noting that Myth logs every occasion the stream has an error and other applications may not do this. You don't get an error message popping up on a Set Top Box for example so if this error doesn't appear with another application it doesn't mean the problem has to be in MythTV.

When I watched the recording with the errors shown above I got a very minor glitch for a fraction of a second. The overall picture quality was much better than with the analogue tuner so if it happened once every few recordings it might be survivable, if hardly ideal. I'll know more when I've done more recordings.

After more testing I seem to get random errors of the type shown above, not every time. I'm doing more work to try to find out what's going on but it's not easy. It may need some more log messages in MythTV to try and delve a bit deeper. Watch this space.

Adding the Remaining Freeview Channels

Note that I delayed adding these channels until midway through testing because life gets more complicated if you have two cards that can't receive the same set of channels.

Adding new DVB channels is straightforward and can be done from within the MythTV setup program. The recently added DVB channel editor can be used to enter the necessary information. 

If you used the Scan feature to configure your channels then you can skip this section as it has already been done for you.

The screenshots below show the DVB related pages for the same channel as the BBC 1 example above. Larger versions can be seen by clicking on them.

DVB Channel Editor Settings Page
 DVB Channel Editor PIDs Page

The same set of parameters need to be added on the DVB settings page as were added manually via SQL inserts above. Again the values come from the channels.conf file obtained when the scan program was run.

In the example above as for many UK Freeview channels the hp_code_rate and lp_code_rate are the same. If not then the ordering of the columns in the scan output is the hp_code_rate followed by the lp_code_rate. For example for my Channel 4 setting:

Channel 4:481833330:INVERSION_OFF:BANDWIDTH_8_MHZ:FEC_2_3:FEC_1_2:QAM_64:
TRANSMISSION_MODE_2K:GUARD_INTERVAL_1_32:HIERARCHY_NONE:2827:2828:8384

The hp_code_rate is FEC_2_3 and the lp_code_rate is FEC_1_2 and these are the values you should enter into the channel setup form.

If you need more examples you can download a copy of my channel and dvb_channel tables from a backup taken a while ago.

Obtaining Extra XMLTV Data

I was using the tv_grab_uk grabber for XMLTV that gets data from Ananova. They don't have a listing for UK History for some reason and I wanted to add this Freeview channel to my system. The Ananova listings have now gone away so this section is probably of little relevance anymore. It may be removed in future and you should probably not need to use it.

I decided to use the alternative tv_grab_uk_rt to get this one channel from the Radio Times site. I wanted this to augment the existing data collection as I didn't want to disturb the currently working set up. The Radio Times grabber also needs to download many more pages to do its job.

I added this channel manually, though I should probably have used the DVB Channel Editor. I spend quite a bit of time using databases so it seems natural to do it the hard way. The channel record won't be automatically added by mythfilldatabase because of the options that will be used with it. I first inserted a channel record using the next available ID using this SQL:
INSERT INTO channel VALUES (1934,'90',1,'UKHistory','UK History','',0,'',
'801.radiotimes.beeb.com',32768,32768,32768,0,'',32768,'Default');
The XMLTV ID must match the one in the file downloaded from the data provider. You can't just make these up. I used the arbitrary channel number 90 (more comments on this below).

Then I added the dvb_channel and dvb_pids entries exactly as shown in the BBC1 example above.

The next step was to run tv_grab_uk_rt --configure and specify that it should download the single channel 'UK History'.

Note that though MythTV supports non numeric channel 'numbers' the current (as I write this) DVB code doesn't. I originally set the channel number to UKH and got a mystifying error claiming that the channel wasn't present in the database.  When I changed this to the arbitrary chosen channel 90 it worked.

Channel numbers as used in applications like Myth are arbitrary with DVB because several broadcasts are multiplexed into a single frequency. A channel number by itself does not identify a particular broadcast as it does in analogue TV.

The next step was to write a small script that downloads the data to an xml file and then uses mythfilldatabase to load it into MySQL. This is just:
#!/bin/sh
rm -f /tmp/ukh.xml
/usr/bin/tv_grab_uk_rt --days 5 --output /tmp/ukh.xml
/usr/local/bin/mythfilldatabase --no-delete --update --file 1 0 /tmp/ukh.xml
BTW the parameter 1 in the call to mythfilldatabase is the id of my video source in the database.

After testing this script I scheduled it with cron to run an hour before the main mythfilldatabase gets the rest of the channels. This was so that the 'last run' info on the status page will always refer to the main channel guide data collection.

Adding the Second DVB Card

Because I was finding it difficult to do proper testing with the mixture of DVB and analogue cards I decided to take the plunge and put the other card in.

This card is a Nova-T with a TDA10045 frontend and has support for a conditional access module. Note: This means a CI connector on the PCB to which a CAM module can be connected. You can't just use the budget Nova-T to handle a smartcard without additional hardware.

The second issue just meant adding the module dvb-ttpci-budget-ci to the list of modules I arrange to load at start up time.

The first means that this particular card needs a firmware file to operate correctly, unlike the card with the Grundig frontend. To get this file download v2.15a of the Windows driver software from the manufacturers web site and extract the file required.

To do this use unzip on the file, create the correct firmware directory and copy the file into place:
# cd /tmp
# unzip nova-pci215a.exe Software/OEM/PCI/App/ttlcdacc.dll
# mkdir -p /usr/lib/hotplug/firmware
# cp Software/OEM/PCI/App/ttlcdacc.dll /usr/lib/hotplug/firmware/tda1004x.mc
Having done that I backed up the database again (can't be too careful) and shut the machine down. I pulled the PVR250 card and added the second Nova-T card. Then I rebooted and the damn thing was showing up incorrectly in a PCI listing. It was being displayed as device class 0xffff and version 0xff. I shut down again and moved it to another slot. A second reboot and everything was (thankfully) fine:
00:08.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01)
00:0a.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01)
Now I loaded the device modules (not forgetting to add the one I mentioned above) and again things went well:
saa7146_core: found saa7146 @ mem e0ff4000 (revision 1, irq 18) (0x13c2,0x1005).
DVB: registering new adapter (TT-Budget/WinTV-NOVA-T  PCI).
DVB: registering frontend 0:0 (Grundig 29504-401)...
TT-Budget/WinTV-NOVA-T  PCI adapter 0 has MAC addr = 00:d0:5c:20:59:c4
saa7146: register extension 'budget_ci dvb'.
saa7146_core: found saa7146 @ mem e114f000 (revision 1, irq 16) (0x13c2,0x1011).
DVB: registering new adapter (TT-Budget/WinTV-NOVA-T  PCI).
tda1004x: Detected Philips TDA10045H.
tda1004x: Detected Philips TDM1316L tuner.
DVB: registering frontend 1:0 (Philips TDA10045H)...
TT-Budget/WinTV-NOVA-T  PCI adapter 1 has MAC addr = 00:d0:5c:22:0b:95
So both cards are now in there and working. You can't remove a card individually in the MythTV setup program so I deleted it from the system manually with SQL. The old card had id 1 so I did this:
DELETE FROM cardinput WHERE cardid = 1;
DELETE FROM capturecard WHERE cardid =1;
Then I ran the Myth setup utility and added the second card. This is exactly the same process as before, add the card, selecting card number 1 rather than 0. Then add an input connection from it to the existing TV source that the other card was using.

That's basically it for the installation. Now there's two tuners available with the same set of channels and testing should be much easier.

More on DVB Stream Errors

I've now been using the cards for a some time and have been able to draw some conclusions. I believe that the issues I'm seeing are signal related and are mostly on particular multiplexes.

I submitted a patch for Myth that should be available in CVS after the 0.14 release and I will document here when this happens. This collects and displays error information from the DVB card and the Myth DVB recorder.

Before that feature is available basic error information can be obtained by starting the mythbackend program with the option -v record. This causes additional log messages to appear, related to recording events.

The Impact of Errors

Firstly the presence of a small number of errors may pass entirely unnoticed. The decoder tries to mask errors and recover from them. As the number of errors clustered together increases then the impact becomes more noticeable as recovery becomes increasingly less effective. This might produce:
The number and frequency of the above events also effects how they are perceived and also on the quality of analogue reception you are used to. In my case I get much better picture quality than I used to and I have several channels where none of the above problems occur.

Types of Errors and Suggested Actions

If the log is reporting stream overflows then there is either a bug in MythTV or, much more likely, your hardware is not capable of reading the stream quickly enough. The error basically means that the buffer that the driver was trying to fill with data overflowed. When this happens data is discarded.

A sudden high load on the system can also trigger overflows even if your hardware is adequate. If the MythTV process doesn't get run often enough then the buffers fill up. I have seen this myself when a network backup client kicks in and grabs a large share of system resources.

The buffer size that Myth tells the driver to use is now configurable so it is possible to increase this and reduce the chance of an overflow due to a transient condition.

Otherwise if stream continuity errors are being logged then the most likely cause is the signal quality.. These are logged with messages indicating that the application expected a particular packet sequence number but got a different one. There are packets missing from the sequence. If signal problems are suspected I recommend recording several programmes on each channel over a period and looking for a pattern. If all the channels give similar levels of errors then your aerial may need to be upgraded.

If the log indicates corrupt packets are being received by Myth then there may be a driver bug or you may have a bad memory chip that corrupted the data on its way from the card -> driver -> application.

Some other statistics come from the frontend in the DVB card. These are displayed with the following abbreviations:
The values for SNR and SS should be high. They are scaled unsigned integers where 65535 (0xffff in hex) represents 100%. Therefore if you see a value of 32768 it represents 50%.

The values of BER and UB should both be low and UB should ideally be zero. The presence of uncorrected blocks is a sign that the signal is weak or suffering from interference, as is a high bit error rate..

Note that signal quality values are scaled into the appropriate range by the frontend driver. Comparing absolute values between two different makes of card may not make any sense.

Collecting Data on Signal Quality

The facility to collect DVB signal statistics was added to MythTV after version 0.14 so at the moment it's only available in CVS versions. It's my first real contribution of code to Myth so if it doesn't work I guess you can blame me.

You can easily tell if it's included by pointing your browser to port 6544 on the machine where the backend is running (e.g. http://your-backend-machine:6544/.  If you see a box at the bottom of the page labelled "DVB Signal Information" then you can use this facility.

To turn on data collection go into the Frontend Setup menus (not the separate setup program) and then select  TV Settings -> General. A new page will appear after the one for expiry settings. This will allow you set the frequency of data collection and the number of days quality data to retain.

You can now set these to suitable values. I've been using a 30 second sampling interval and keeping 3 days data.

Now schedule some recordings and while the recordings are made the card signal stats, and some MythTV error counters, will be sampled at the interval you specified.

To see a summary of this data go back to the status page you looked at before. It will now show the statistics for each recording period. For example you might see:
Recording period from Thu Feb 12 11:00:00 2004 to Thu Feb 12 12:00:00 2004
Card: 3 Min SNR: 59624 Avg SNR: 59850 Min BER: 217 Avg BER: 370 Cont Errs: 0 Overflows: 0
The names of the statistics should be familiar from the previous section. We can see that there were no errors in the stream, no overflows occurred, the bit error rate was fairly low throughout and SNR never dropped.

If you want to do more serious analysis of the statistics you can use another package to pull the data out of MySQL. OpenOffice is one program that can do this.

All you need to do is configure it with the MySQL ODBC driver and set up a data source pointing at the MythTV database. It may be best to create a user e.g. called mythstats in MySQL and just grant this user access to the dvb_signal_quality table in the mythconverg database. This will protect against accidental changes to important tables.

You can then copy the data out of the MySQL database and into a spreadsheet document. Then you can plot charts for example.

The QAM64 Issue / Saga

Here in the UK most of the channels are broadcast using a transmission mode known as QAM 16 (Quadrature Amplitude Modulation). A couple of the multiplexes are using QAM 64. This mode allows more digital channels to be transmitted in the multiplex but is also more susceptible to some types of interference. Looking at the results I'm seeing the biggest error rate problems on the QAM 64 muxes.

At one point the ITC were going to mandate that all transmisions switch over to QAM 16 but in the end decided to allow the existing QAM 64 muxes to continue operating in this mode. The argument seems to be basically that because these were mostly interference issues then they could be addressed by cable shielding and similar measures at the receiver end.

Personally I think this argument is flawed. I can think of at least three counter arguments:
There doesn't seem to be much to do about it though. I had my aerial and signal cable replaced last year and its pretty good quality. I'm not in an area served by cable so Freeview is the only realistic option. We can only hope that in future more digital bandwidth will become available and it won't be used to cram in more junk tv.

Adventures With a New Motherboard

Last week I got hold of a black hi-fi style case to house my Myth system. I'd tried to get a similar case before but it had been out of stock for weeks and I gave up. This one is an Accent Home Theater case which, while it's overpriced in my opinion, at least takes three hard drives plus a normal sized DVD driver, a standard ATX motherboard and power supply and is pretty well made. I ordered it from Quiet PC.

When I'd got everything moved over into its new home I switched it on. It got about to the end of the BIOS memory test and then nothing happened. I turned it off and on again a few times and still nothing. It was totally dead. A bit of fault finding later and I'd pointed the finger at a defective processor. Ooops. Luckily I'd built my original system out of some older bits I had lying around so at least I hadn't blown up something very expensive.

So I went and bought a replacement CPU and motherboard, deciding to move up to an Athlon with a 333MHz bus speed. Before too long I had everything in the case and powered up. Then I started to use it and discovered it seemed to be slower than the old system.

A bit of investigation later it seemed that the problem was something to do with IDE. Any time more than one thing accessed the disk everything ground to a halt. This meant some directory listings were taking 10-15 seconds. If I started watching a programme it would totally disrupt a concurrent recording with hundreds of  buffer underflow errors.

So I next did a lot of headscratching and testing of components. The first thing I checked was DMA. As expected I found that this was running in UDMA mode 5 (ATA 100) on the hard drives and UDMA 2 on the DVD. The hdparm utility can be used to check the transfer rates like this:
# hdparm -tT /dev/hda

/dev/hda:
 Timing buffer-cache reads:   1184 MB in  2.00 seconds = 592.00 MB/sec
 Timing buffered disk reads:  134 MB in  3.01 seconds =  44.52 MB/sec
If the buffered disk read figure comes out at something like 5 MB/sec then there's the problem somewhere.

Something was clearly wrong. I contacted AOpen technical support who were helpful. They pointed me at the VIA IDE patches, but these are already in recent kernels so that was a dead end.

So I still had a problem. I did some more tests and checking and didn't find much wrong. These are a few of the things I tried:
None of this had much effect. The PCI latency change did seem to make things slightly better. I'm now running with these lines in rc.local:
setpci -s 00:07.00 LATENCY_TIMER=80
setpci -s 00:09.00 LATENCY_TIMER=80
To try this you need to replace the first set of numbers with those returned by lspci for the DVB card(s) in your system.

Interrupt allocation on this board seems a bit strange. It always seems to want to share them even when others are spare and with all the onboard USB etc. switched on there only seems to be two that get shared between all 5 PCI slots.

To cut a long story short after another evening of frustrating playing about I finally got it to work. In the end I had to install a third hard drive I had spare and dedicate it to the operating system. This made no sense to me as I could reproduce the issues with the two Seagate drives when MythTV wasn't running so only one of them would have been in use anyway.

The most likely possibility is some quirk of the chipset with Seagate drives. I can't think of many other plausible reasons.  I originally planned to change the video storage disks to RAID 0 with LVM. I've decided for now that if there is some wacky problem  when both disks get used at once I don't want to do all that work to find this out.

Anyway, I now had a fully working and usable system again and it can now happily record two DVB streams at once at a high quality. Two simultaneous recordings and a frontend playing back another programme on the same machine still seem to cause a few buffering problems. Since there aren't that many times when there are two things on I actually want to watch that doesn't matter too much.

My System Specification

In case anyone is interested  this is my current hardware spec for my Myth system. I also have additional video storage space mounted off my NFS server.

Item
 Description
CPU Athlon 2800+ (2.08 GHz)
Motherboard
 AOpen AK77-600GN (KYT600 chipset)
Memory
 1 x 512MB PC2700
Disk 1
 IBM 60GB 60GXP (Operating System + Spare Space)
Disk 2
 Seagate 120GB (Video 1, LVM)
Disk 3
 Seagate 160GB (Video 2, LVM)
Capture Cards
 2 x Nova-T DVB PCI
DVD
 Sony DRU-510 DVD Writer
IR Interface
 IRMan (Serial port)
Case
 Accent Home Theater PC
OS
 Fedora Core 3 (Standard 2.6.10 kernel)
DVB Drivers
 2.6. kernel drivers
MythTV
 CVS version

In terms of hardware recommendations the Athlon chips used to run very hot but the new faster ones seem to be much better. The chipset is also very important - particularly for those using the SAA7146 budget DVB cards like the Nova-T. This doesn't matter quite as much for those with PVR / Analogue cards.

These days it's easily worth getting 512MB of RAM, given the cost, maybe more.

All TV tuners seem to run hot, a case with good airflow will help. This is one good thing about the Accent case.

Using the Freeview EPG For Programme Listings

I was using the Radio Times for TV listings for a while. They now offer an XMLTV friendly service but it doesn't include radio listings at the moment. As I'm big R4 listener I decided to use the DVB over the air programme guide. It's not as detailed as the Radio Times one and only has 7-8 days instead of 14 but that's not a big problem. Also the DVB guide can be updated in real time with scheduling changes and it's not using any internet bandwidth so can be downloaded more often. It would be a good option for dial-up users.

The guide data is broadcast in a standard format so the information below may be applicable to other countries than the UK. I don't know whether this is the case at the moment. There is no requirement for broadcasters to transmit a full programme guide and indeed the 8 day guide has only just been rolled out in the UK.

Switching guide data turned out to be a relatively simple process which I'll now run through.

To use this you need to get software to decode the transmitted guide and turn it into XMLTV format for use by MythTV. This uses a package called tv_grab_dvb written by Mark Bryars that you can get from http://www.darkskiez.co.uk/index.php?page=tv_grab_dvb  download the archive and unpack it somewhere convenient.

The current version 0.9 of the dvbepg software includes patches contributed by MythTV users. I suggest applying one of the two subtitle patches in the contrib directory. To do this do something like:
cd /opt/tv_grab_dvb-0.9 
patch -p1 < patches/subtitle-pct.patch
Now edit the tv_grab_dvb.c file and make sure you're happy with the locations specified by the CHANNELS_CONF and CHANIDENTS definitions. I changed these to:
#define CHANNELS_CONF "/home/mythtv/.tzap/channels.conf"
#define CHANIDENTS /usr/local/etc/chanidents
Now run make and copy the resulting tv_grab_dvb binary to /usr/local/bin and the chanidents file to /usr/local/etc.

Tune your first DVB card (#0) into a channel somehow, e.g. run up the mythbackend and then run:
./tv_grab_dvb -c -t 30 > /tmp/test.xml
If all is well a status display will then clock up the data as it is received. After a couple of minutes the program should exit and /tmp/test.xml should contain a set of XMLTV data.

Examine the first part of this file. Look for any channels that you care about that didn't match an entry in the chanidents file. They will have a channel id of dddd.dvb.guide rather than their XMLTV id e.g. a channel that matches might be listed as:
<channel id="itn.co.uk">
    <display-name>ITV News</display-name>
</channel>
Whereas one that doesn't match might be:
<channel id="4479.dvb.guide">
    <display-name>BBCi</display-name>
</channel>
If there are any missing channel ids then edit the chanidents file and put in the mapping. E.g. in this hypothetical example you might add a line to chanidents that reads: 
4479 bbci.bbc.co.uk
Run the test again and check that the ident has been picked up. When there are no channels unaccounted for then it's time to schedule the guide updates.

You can just pipe the output of  tv_grab_dvb into mythfilldatabase but I save it into a file that's on a network share and can be used by other XMLTV applications. I just run the following mythfilldatabase cron script every couple of hours. It's a minor edit of the standard script. 
#!/bin/bash
export QTDIR=/usr/lib/qt-3.1

rm -f /tmp/whatson.xml
nice /usr/local/bin/tv_grab_dvb -u -t 35 -s -c /usr/local/etc/chanidents \
    > /tmp/whatson.xml

nice /usr/local/bin/mythfilldatabase --no-delete --file 1 -1 /tmp/whatson.xml

# make the latest file accessible via NFS and Samba

mv /tmp/whatson.xml /var/video/guide

# The minimum number of days you will allow before you
# want to receive a notification message
MIN_DAYS=3

# The e-mail address to send the warning message to
EMAIL=root

DB=mythconverg
SQL='SELECT TO_DAYS(max(endtime)) - TO_DAYS(now()) FROM program;'

DAYS_LEFT=`mysql -pmythtv --skip-column-names -B -D $DB --execute "$SQL"`

if [ $DAYS_LEFT -lt $MIN_DAYS ]; then
       mail -s "[MYTHTV] Only $DAYS_LEFT days of programs left!" $EMAIL <<-END
               Maybe you should check if mythfilldatabase is configured
               correctly or that your XMLTV service provider is still
               on-line?
-END
fi
And that should be it. The guide data should now get regularly updated. I update every few hours.

Some Other Useful Things

There is now another page of things that have been contributed to the document.
Martin Smith
Last Updated March 2005. Hosted with the nice people at clued up hosting.