Opened 14 years ago
Closed 14 years ago
Last modified 14 years ago
#8099 closed defect (invalid)
Backend fails to tune a few HD channels from hdhomerun (but VLC plays them fine)
Reported by: | Owned by: | Nigel | |
---|---|---|---|
Priority: | minor | Milestone: | 0.23 |
Component: | MythTV - Recording | Version: | 0.22-fixes |
Severity: | medium | Keywords: | hdhomerun |
Cc: | Ticket locked: | yes |
Description
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.
Attachments (3)
Change History (13)
Changed 14 years ago by
Attachment: | mythlog.txt added |
---|
Changed 14 years ago by
Attachment: | myth-db.txt added |
---|
Database entries for 3 channels on the freqid, where 2 fail and 1 works
comment:1 Changed 14 years ago by
Milestone: | unknown → 0.23 |
---|
comment:3 Changed 14 years ago by
Resolution: | duplicate |
---|---|
Status: | closed → new |
Actually going to re-open, as #6539 only addressed the message and not the tuning failure
comment:4 Changed 14 years ago by
Unfortunately the tuning problem still exists in trunk. I just attached the backend log.
comment:5 Changed 14 years ago by
Owner: | changed from danielk to Nigel |
---|---|
Priority: | major → minor |
Severity: | high → medium |
Status: | new → assigned |
comment:6 Changed 14 years ago by
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.
comment:7 Changed 14 years ago by
Resolution: | → invalid |
---|---|
Status: | assigned → closed |
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
comment:8 Changed 14 years ago by
Resolution: | invalid |
---|---|
Status: | closed → new |
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?
comment:9 Changed 14 years ago by
Resolution: | → invalid |
---|---|
Status: | new → closed |
Ticket locked: | set |
It would be better to request it be re-evaluated on the dev list if you disagree with the resolution.
comment:10 Changed 14 years ago by
please create a new ticket with a -v chanscan,siparser,channel log of scanning that transponder.
Backend log using -v channel,record,siparser