MythTV DVB Setup Guide Part 2
Compiled by Martin Smith
V0.20 March 2005 (For MythTV Version
Hardware Working? Now What?
If you read part one of this document
you'll remember that it focussed on getting the DVB hardware installed
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
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
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
mysqldump -c -a -p mythconverg > /somewhere_safe/mythsql.dump
The backup file may be quite large, my current backup ended up at
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
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
then uncomment it in settings.pro.
CONFIG += using_dvb
DEFINES += USING_DVB
INCLUDEPATH += /opt/DVB-Kernel/dvb-kernel/linux/include
Now run make distclean
followed by make install.
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
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.
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
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
This gives me the
If you're using the 2.6 kernel the names have changed slightly. The
last two lines become:
# Load DVB Modules
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
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
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
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
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
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
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
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
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):
SET channel.serviceid = dvb_channel.service id
WHERE channel.chanid =
channel,dvb_channel,dtv_multiplex SET channel.mplexid =
WHERE channel.chanid =
AND dvb_channel.frequency =
MySQL 3 (the silly way):
ALTER TABLE channel DROP
ALTER TABLE channel DROP COLUMN
ALTER TABLE channel DROP COLUMN
CREATE TABLE newchannel AS
WHERE channel.chanid =
AND dtv_multiplex.frequency =
ALTER TABLE newchannel ADD COLUMN
atscsrcid int(11) DEFAULT null;
ALTER TABLE channel RENAME
ALTER TABLE newchannel RENAME
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
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
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
wanted to carry out these
steps without affecting my current analogue setup so I decided to add
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:
-- 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,
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.
INSERT INTO dvb_pids VALUES (1000,600,'v','');
INSERT INTO dvb_pids VALUES (1000,601,'a','');
is the channel id. In my case 1000 is the existing channel id for BBC1
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
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:
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
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
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.
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
backend complains that parameters are invalid then recheck what was
entered into the dvb_channel
table for that channel.
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
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
2004-01-06 23:15:54 Started recording "The Warzone:Secrets of World War II" on channel: 1934 on cardid: 3, sourceid 1
This is what happens when there are errors with the transport stream:
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
2004-01-09 19:30:02 Started recording "The Big Question with Ian Stewart" on channel: 1004 on cardid: 3, sourceid 1
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:
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
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.
- Poor signal quality
- DVB Driver problem
- PCI bus transfer issue
- Hardware not fast enough to process the stream properly
- A Problem with 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.
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:
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
Obtaining Extra XMLTV Data
I was using the tv_grab_uk grabber for XMLTV that gets data from
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
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,'',
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
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
rm -f /tmp/ukh.xml
BTW the parameter 1 in the call to mythfilldatabase is the id of my
video source in the database.
/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
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
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:
# 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
00:08.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:
00:0a.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01)
saa7146_core: found saa7146 @ mem e0ff4000 (revision 1, irq 18) (0x13c2,0x1005).
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:
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
DELETE FROM cardinput 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.
DELETE FROM capturecard WHERE cardid =1;
That's basically it for the installation. Now there's two tuners
available with the same set of channels and testing should be much
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
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
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.
- Audio squeals or pops
- Picture breakup or blockiness for a moment
- A sudden jump in playback for a few seconds.
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 ->
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%.
- SNR - Signal to Noise Ratio
- SS - Signal Strength
- BER - Bit Error Rate
- UB - Uncorrected blocks
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
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
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.
Card: 3 Min SNR: 59624 Avg SNR: 59850 Min BER: 217 Avg BER: 370 Cont Errs: 0 Overflows: 0
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
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
Personally I think this argument is flawed. I can think of at least
three counter arguments:
- They're trying to sell DVB-T to the general population including
a large percentage of people who are only interested in the current
channels and not in the technology. These people aren't going to want
to shell out for replacement aerials and cabling as well
as set top boxes. There's also no guarantee that the interference can
be eliminated in a particular case.
- They haven't ensured that the five channels people get already
will be received with the same or improved quality. So rather than
being in a situation where everybody gets better reception of their
current channels plus some extra ones, which are all new and a bonus,
some people may see switching to Freeview as a step backwards.
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
in an area served by cable so Freeview is the only realistic option. We
hope that in future more digital bandwidth will become available and it
won't be used to cram in more junk tv.
- The additional channels that are being squeezed into the QAM 64
muxes are poor quality and already available on satellite and/or cable.
This means I
get worse reception of Channel 4 in return for additional channels that
I haven't even bothered to set up on Myth because I'll never watch them.
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
for weeks and I gave up. This one is an Accent Home Theater case which,
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
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
If the buffered disk read figure comes out at something like 5 MB/sec
then there's the problem somewhere.
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
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:
- Changing just about every parameter in the BIOS
- Using the BIOS 'turbo' defaults
- Moving the DVB cards to different slots
- Playing with setpci to change the PCI latency timer settings
- Changing the DVB driver to use different PCI transfer settings
- Using a different network card instead of the onboard one
- Replacing the PC2100 memory with PC2700
- Disabling all onboard devices except sound to free up interrupts
setpci -s 00:07.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.
setpci -s 00:09.00 LATENCY_TIMER=80
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.
||Athlon 2800+ (2.08 GHz)
|AOpen AK77-600GN (KYT600 chipset)
|1 x 512MB PC2700
|IBM 60GB 60GXP (Operating System
+ Spare Space)
|Seagate 120GB (Video 1, LVM)
|Seagate 160GB (Video 2, LVM)
|2 x Nova-T DVB PCI
|Sony DRU-510 DVD Writer
|IRMan (Serial port)
|Accent Home Theater PC
|Fedora Core 3 (Standard 2.6.10
|2.6. kernel drivers
In terms of hardware recommendations the Athlon chips used to run very
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,
All TV tuners seem to run hot, a case with good airflow will help. This
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:
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:
Whereas one that doesn't match might be:
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:
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
You can just pipe the output of tv_grab_dvb into
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
And that should be it. The guide data should now get regularly updated.
I update every few hours.
rm -f /tmp/whatson.xml
nice /usr/local/bin/tv_grab_dvb -u -t 35 -s -c /usr/local/etc/chanidents \
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
# The e-mail address to send the warning message to
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
Some Other Useful Things
There is now another page of things that
have been contributed to the document.
Last Updated March 2005.
Hosted with the nice people at clued