Opened 10 years ago

Closed 9 years ago

Last modified 9 years ago

#8099 closed defect (invalid)

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

Reported by: Derek Atkins <warlord@…> 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)

mythlog.txt (12.1 KB) - added by Derek Atkins <warlord@…> 10 years ago.
Backend log using -v channel,record,siparser
myth-db.txt (1.7 KB) - added by Derek Atkins <warlord@…> 10 years ago.
Database entries for 3 channels on the freqid, where 2 fail and 1 works
trunk-log.txt (9.1 KB) - added by Derek Atkins <warlord@…> 10 years ago.
Log file from trunk as of today

Download all attachments as: .zip

Change History (13)

Changed 10 years ago by Derek Atkins <warlord@…>

Attachment: mythlog.txt added

Backend log using -v channel,record,siparser

Changed 10 years ago by Derek Atkins <warlord@…>

Attachment: myth-db.txt added

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

comment:1 Changed 10 years ago by stuartm

Milestone: unknown0.23

comment:2 Changed 10 years ago by robertm

Resolution: duplicate
Status: newclosed

Dupe of #6539.

comment:3 Changed 10 years ago by robertm

Resolution: duplicate
Status: closednew

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

Changed 10 years ago by Derek Atkins <warlord@…>

Attachment: trunk-log.txt added

Log file from trunk as of today

comment:4 Changed 10 years ago by Derek Atkins <warlord@…>

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

comment:5 Changed 10 years ago by danielk

Owner: changed from danielk to Nigel
Priority: majorminor
Severity: highmedium
Status: newassigned

comment:6 Changed 9 years ago by 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.

comment:7 Changed 9 years ago by Janne Grunau

Resolution: invalid
Status: assignedclosed

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 9 years ago by Derek Atkins <warlord@…>

Resolution: invalid
Status: closednew

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 9 years ago by robertm

Resolution: invalid
Status: newclosed
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 9 years ago by Janne Grunau

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

Note: See TracTickets for help on using tickets.