[mythtv-users] EIT (DVB-S) data problems
knowledgejunkie at gmail.com
Tue Dec 22 01:35:21 UTC 2009
2009/12/19 Christian <CvB at kruemel.org>:
> Thanks for your response, Nick.
>> Some initial suggestions:
>> i) turn off the 'useonairguide' flag for those channels you don't want
>> data for
> I did that. useonairguide is only set for 15 out of the 559 channels in
> the database here.
>> ii) check the EIT scanning timeouts in mythtv-setup
> EIT Transport Timeout is set to 5 mins (was the default setting). "Cross
> Source EIT" is enabled, and "Backend idle before EIT Crawl" is set to 60
> secs. Signal timeout is set to 7,000 ms, tuning timeout to 10,000 ms. "Use
> quick tuning" is set to "Never".
> Would you suggest to change any of these, and if so, to which setting?
I would disable cross-source EIT. The other values look fine, although
I suppose you could double the signal and tuning timeouts to see if
that makes a difference for your card/driver.
>> iii) run the backend with extra 'eit,siparser,channel' verbose logging
>> to highlight any potential problems
> Ok, I have enabled this. I am not sure what to make of the log, though.
> There is quite some EIT data in there now, lots for channels for which EIT
> data shall not be used.
> I have, e.g., a lot of these (for various shows, of course):
> 2009-12-19 09:00:55.887 GM : LIVING GOSPEL - Bibel TV new best match
> LIVING GOSPEL - Bibel TV with score 11000
> This specific channel is set to not to use EIT guide, but it's clear that
> data will be received. So I guess these messages are ok.
> I also have a lot of these:
> 2009-12-19 09:02:05.491 PESPacket: Failed CRC check 0x656d2046 !=
> 0xab7bb2dd for StreamID = 0x60
> 2009-12-19 09:02:05.493 Discarding broken PES packet
> 2009-12-19 09:02:07.091 PESPacket: Failed CRC check 0x89768009 !=
> 0x173882e9 for StreamID = 0x60
> 2009-12-19 09:02:07.093 Discarding broken PES packet
> Is this normal?
CRC errors can be caused by a weak signal, errors in the stream, or
when comparing missing CRC values (e.g. some EIT tables do not use
CRCs). The 0x60 table_id is used for "other TS, event schedule
information" (ETSI EN 300 468 V1.9.1). I can't say whether this error
is a problem or not.
> I also have this, by the way:
> 2009-12-19 08:58:47.801 Program #51 not found in PAT!
> Program Association Table
> PSIP tableID(0x0) length(240) extension(0xf00)
> version(14) current(1) section(251) last_section(120)
> tsid: 3840
> programCount: 58
> program number 63488 has PID 0x 100 data 0xf8 0x 0 0x 1 0x 0
> program number 34168 has PID 0x d9 data 0x85 0x78 0x60 0xd9
> program number 34492 has PID 0x12ff data 0x86 0xbc 0xf2 0xff
> program number 20465 has PID 0x1b03 data 0x4f 0xf1 0x1b 0x 3
> program number 1781 has PID 0x 1 data 0x 6 0xf5 0x 0 0x 1
> program number 7 has PID 0x 85 data 0x 0 0x 7 0x 0 0x85
> program number 335 has PID 0x177b data 0x 1 0x4f 0xf7 0x7b
> program number 55184 has PID 0x 730 data 0xd7 0x90 0x 7 0x30
> program number 33024 has PID 0x d1a data 0x81 0x 0 0x4d 0x1a
> program number 17477 has PID 0x1515 data 0x44 0x45 0x55 0x15
> program number 21608 has PID 0x 520 data 0x54 0x68 0x65 0x20
> program number 22369 has PID 0x1265 data 0x57 0x61 0x72 0x65
> program number 26735 has PID 0x1573 data 0x68 0x6f 0x75 0x73
> program number 25888 has PID 0x1072 data 0x65 0x20 0x50 0x72
> program number 28522 has PID 0x 563 data 0x6f 0x6a 0x65 0x63
> program number 29696 has PID 0x ec6 data 0x74 0x 0 0x4e 0xc6
> also contains 1 + 41 dummy programs
> 2009-12-19 08:59:06.283 Program #51 not found in PAT!
> Program Association Table
> PSIP tableID(0x0) length(0) extension(0x344)
> version(2) current(1) section(85) last_section(68)
> tsid: 836
> programCount: 0
> 2009-12-19 08:59:06.284 ProcessPAT: Program not found in PAT.
> Rescan your transports.
> 2009-12-19 08:59:06.286 No program found in PAT. This recording will not
> play in MythTV.
> 2009-12-19 08:59:06.287 Desired program #51 not found in PAT.
> Can Not create single program PAT.
> I see "Rescan your transports" - I just wonder where this message comes
> from. There is no program (neither chanid nor channum) 51 in my database.
> Why is mythtv looking for this?
Again, this is a question for someone with more DVB knowledge than I
currently possess - the usual response is to do a rescan as MythTV
database's list of muxes/channels and their associated DVB IDs is out
I do see this message in my 0.22 DVB-S logs however, and do not have
any tuning/EIT problems that I am aware of (yet!).
>> iv) check your database health with optimize_mythdb.pl
> This is run nightly.
>> v) do a full rescan to ensure multiplex/channel tuning information is
> Which approach would you suggest for rescanning? As I have DVB-S here,
> there are a couple of thousand channels to be scanned (and set to
> invisible and not to use EIT data, if a new configuration would be
> required). I'd like to keep, of course, recording schedules etc. in a
> format which will still be current after a rescan.
When investigating DVB-S problems I would use a full (tuned) scan,
starting on a known good mux frequency. I (you may not either want to,
or need to) would also clear out the old channel/mux/video source
information to ensure a clean starting point. If the database is using
old IDs for DVB streams you can expect to have problems.
Double check your eit_cache and program tables are healthy. Are there
any entries in the eit_cache table?
The new chanel scanner can ignore encrypted channels and also
selectively scan for TV and radio channels. I use a simple script to
hide and turn off EIT collection for channels I don't want to use, and
to ensure those channels I do want are visible and have EIT guide data
MythTV Official wiki: http://mythtv.org/wiki/
MythTV users list archive: http://www.gossamer-threads.com/lists/mythtv/users
"An investment in knowledge always pays the best interest." - Benjamin Franklin
More information about the mythtv-users