Backend fails to tune a few HD channels from hdhomerun (but VLC plays them fine)

[Derek Atkins <warlord@…>]

I just moved, upgraded my myth to 0.22, and reconfigured my system to use the HDHR on Comcast Cable. I've upgraded the HDHR firmware to the most recent version (20100213), and when I run the hdhomerun_config_gui with VLC I can watch every channel just fine! However MythTV cannot tune a couple channels.

When I try to tune the channel on MythTV I get:

Signal 91% | (LAM_V) Partial Lock

The mythtv database matches what I see the HDHR Config GUI, that this channel (803, WSBDT) is on 98.3.

I have three channels on this physical channel and two of them have problems (the other failing channel is number 804, WAGADT, on 98.804, whereas WSBDT2 on 98.248 is just fine). I suppose there could be a tuning problem on this major channel but more likely I think Myth is not reading the PMT correctly. I've attached the backend log with -v channel,record,siparser, which shows that it's reading the streams:

 programCount: 3
  program number   804 has PID 0x  30   data  0x 3 0x24 0xe0 0x30
  program number     3 has PID 0x  32   data  0x 0 0x 3 0xe0 0x32
  program number   248 has PID 0x  40   data  0x 0 0xf8 0xe0 0x40

 Stream #0 pid(0x33) type(video-mpeg2  0x2)
 Stream #1 pid(0x36) type(audio-ac3  0x81)
  ISO-639 Language: code(eng) canonical(eng) eng(English)
 Stream #2 pid(0x37) type(private-data  0x6)
 Stream #3 pid(0x38) type(private-sec  0x5)
 Stream #4 pid(0x39) type(private-sec  0x5)

However then the log shows some failures looking for the PMT:

2010-02-22 08:52:15.659 ATSCStreamData::HandleTables(): Unknown table 0xc0
2010-02-22 08:52:15.669 SM(192.168.248.4-0)::AddFlags: Seen(PMT,) Match() Wait()
2010-02-22 08:52:15.669 DTVSM(192.168.248.4-0)::GetStatusList: WaitForPMT seen(1) matching(1)
2010-02-22 08:52:15.726 DTVSM(192.168.248.4-0) Error: Wrong PMT; pmt->pn(248) desired(3)
2010-02-22 08:52:15.730 SM(192.168.248.4-0)::AddFlags: Seen(PMT,) Match() Wait()
2010-02-22 08:52:15.732 DTVSM(192.168.248.4-0) Error: Wrong PMT; pmt->pn(804) desired(3)

And then lots more of the Unknown Table errors. The full log is attached.

[Derek Atkins <warlord@…>]

Backend log using -v channel,record,siparser

[Derek Atkins <warlord@…>]

Database entries for 3 channels on the freqid, where 2 fail and 1 works

[robertm]

Dupe of #6539.

[robertm]

Actually going to re-open, as #6539 only addressed the message and not the tuning failure

[Derek Atkins <warlord@…>]

Log file from trunk as of today

[Derek Atkins <warlord@…>]

Unfortunately the tuning problem still exists in trunk. I just attached the backend log.

[Janne Grunau]

The signal monitor waits for the master guide table which doesn't seems to be broadcasted. The Unknown Table 0xc0 suggest the the channels use SCTE service information.

Please try a rescan off that transport. If that doesn't help set tvformat for the failing channels to and atsc_major|minor_chan to 0.

[Janne Grunau]

closing as invalid since this seems to a configuration problem.

We should probably implement a timeout for non essential tables as long as we don't see contradictionary data

[Derek Atkins <warlord@…>]

A rescan did not help; it looks the same as it did before. Manually resetting the table entries for those two channels *DID* help. Thank you.

Still, I'm not sure this is a configuration problem; the scanner did input that information all by itself. Are you saying that users have to manually go and determine that the scanner inserted broken results into the database and correct it by hand? Is that what you mean by "configuration problem"? To me it seems like a broken scanner that's inserting incorrect data, which would seem to be a bug in the scanner, no?

[robertm]

It would be better to request it be re-evaluated on the dev list if you disagree with the resolution.

[Janne Grunau]

please create a new ticket with a -v chanscan,siparser,channel log of scanning that transponder.