DVB channels messed up after scanning or importing from channels.conf

[mc-mythtv at dontcare.sganawa.org]

I've been an happy Mythtv user for several months, until I recently deleted channels data by accident. To define them with current Mythtv version has proven to be impossible. I live in Italy, and I'm using a Liveview FlyDVB-T Hybrid card.

What's happening: I launch dvb-utils's scan with

scan -5 -n -v it-Roma > .tzap/channels.conf

it works flawless; I get a list of channels and I'm able to tune each of them by tzap <channel name>, or watch them with mplayer dvb://<channel name> or whatever. So I assume there is no problem with DVB kernel modules or LinuxTV drivers.

However Mythtv is unable to get a single working channel, using internal scanner, but also by importing channels.conf definitions. If I use the internal scanner, for instance by defining a transport then scanning it, Mythtv seems to work - tune, signal lock, adding channels, adding transports... But when I launch Mythfrontend and I select any channel, after a few seconds I get a message "you should be able to get a lock by now...". No lock occurs ever. So I've checked channels and dtv_multiplex tables; dtv_multiplex contains inconsistent transports data. Several - if not all - rows contain non-existent or absurd frequencies (like 100000), wrong FEC values, bandwith is 7 MHZ instead of 8... Things like that. Apparently, my local DVB stations are sending junk informations about their own settings. I've also seen these junk data while dvb-utils is scannning; but while dvb-util's scan throws them away (probably it double checks broadcasted data and remembers settings that have worked), Mythtv is believing them blindly: it insert this junk in transport definitions, replacing the correct ones! Sure, it wouldn't happen if no junk data was sent by broadcaster, but since dvb-utils can deal with them, I see no reason why Mythtv couldn't.

There is no way of getting around this problem. If I try to import channels.conf in Mythtv, a check occurs that corrupts all transports data same way. Moreover, since there is no "ignore timeout" in import channels.conf (there is, on other scanning options), some of them are skipped after a too small delay. I've also tried to fix each transport data, then scan it one at a time with "Hierarchy=None" option, which should prevent getting other transports data; but it doesn't work: other existing transports are still updated with bad data, and final setup doesn't work either. I've also noticed that some transports are defined with sistandard="dvbt" (lowercase), an unselectable setting that I don't know where it comes from. All of this effectively renders Mythtv useless, as even if you try to manually define each channel, you can't still enter some necessary detail (namely serviceid).

To have back a working configuration, I finally had to write myself a script to convert channels.conf to SQL statements, then import them with mysql client. But it's not a viable solution for most of the users.

Considerations:

• I think it's conceptually wrong that "import channels.conf" scanner option rescans each channel; it should simply integrate them with missing informations - channel number, xmltv id... This option should be a "safety net", in case internal scanner doesn't work, or simply the user doesn't want to use it. I remember that, when I first installed Mythtv several versions ago, I concluded that internal scanner was broken either, but nontheless I was able to use this option to get an usable configuration. With recent upgrades, this is no longer possibile.
• Possibly, the very same dvb-utils scan logic should be implemented in Mythtv, as it seems more foolproof;
• Even easier, Mythtv could drop internal scanning and rely on dvb-utils to do this job, so as to avoid reinventing the wheel.

My current version of mythtv is 0.20.2-0ubuntu10 on Ubuntu 7.10 (Gutsy). I attach channels.conf (working) and the resulting channel and dtv_multiplex (broken) tables, after importing.

[anonymous]

I have the same problem here. Scanning for channels puts garbage into transport and channel tables

[anonymous]

Same problem here.

[anonymous]

Similar problem with DVB-s for Astra 19.2E: Mythtv scan results only in a small subset of channels, while scan works well.

Could the original reporter please attach his script to convert channels.conf into Mythtv-SQL? This would be a proper workaround.

[panachoi@…]

I have a similar situation, but with a DVB-C tuner. I've generated a channels.conf using scan/w_scan, and can use it with czap,xine,mplayer, etc without problems. Its even worse when the provider sends "misinformation" -- I can regularly crash the scanner in mythtv-setup.

I've even entered the dtv_multiplexes by hand (parsed from channels.conf), and doing either a scan existing transport, or full scan of existing transports. Either way the scanner usually crashes, either before or after entering the garbage into the dtv_multiplex and channel tables.

This is still a problem with the SVN version I'm using (0.21.20071202-1).

If you have the code to do the magic to take an existing channels.conf, and fill the dtv_multiplex and channels tables with correct information so that myth works, I'm sure I'm not the only one who would appreciate it. Perhaps it should go into the contrib folder.....

[anonymous]

There is a script channels.conf-import.pl attached to

​http://www.mail-archive.com/mythtv-dev@mythtv.org/msg09417.html

but it doesn't seem to work either.

[am@…]

I have the same problem with mythbuntu 7.10. I confirm that importing channels.conf worked well with version 0.19 on Fedora Core 5.

As a temporary workaround, It should be useful to get that script that converts channels.conf to SQL statements.

Thanks.

[mc-mythtv at dontcare.sganawa.org]

Due to popular demand :), I've attached the script I wrote to import channels.conf in Mythtv SQL DB. I've recently used it and seems to work fine. Basically the steps are:

• Export channel and dtv_multiplex tables in two text files;
• Run script on exported tables, reading channel.conf;
• Import back modified tables in mysql.

The exact needed commands are inside script's comments. The script tries to modify the least possible about existing configuration, however it could be smarter in doing this (it assumes that during updates pid is maintained, which is not always the case). If you want to check exactly what's going on (recommended!), you can set "debug" variable to level 1-4 (i.e. <scriptname> -v debug=3 channels.conf). Levels above 4 are at "programming" level and probably are too verbose. ...so have fun!

[chalserogers@…]

I think I was seeing this same bug - scanning would always result in "no tables found", even when I imported from channel.conf, and other players worked fine.

Now using the mythbuntu trunk build packages 0.20.99+trunk15578-0ubuntu0~mythbuntu1 I no longer have this problem.

[stuartm]

Fixed in trunk.

[mc-mythtv at dontcare.sganawa.org]

Modified to deal with Mythtv 0.21

[mc-mythtv at dontcare.sganawa.org]

Well... I've switched to version 0.21.20080304-1 (16838), but I'm still having troubles. I fear mythtv's DVB-T channel scanning is somehow too fast for my DVB card. "Ignore timeout" option doesn't help (it seems not to extend timeout). So I'm still using this workaround. Since DB format has changed from version 0.20, I've slightly modified my script. Here is attached.