[mythtv] Empty PAT Un-Recordable?

[Dave Allen Barker Jr]

Janne Grunau wrote, On 08/18/2007 02:35 PM:
> On Sunday 12 August 2007 15:05:08 Dave Allen Barker Jr wrote:
>   
>> I've had a working installation for some years. Last week, a single
>> ATSC channel (WPBA <http://en.wikipedia.org/wiki/WPBA>) generated
>> scheduled recording files of zero size, and failed to play live
>> (stalling at "La___"). "mplayer" though is able to play this trouble
>> channel successfully.
>>     
>
> The backend doesn't see the serviceid (program number) in the PAT. Try 
> rescanning the transport.
>
>   
>> Investigating into realms I know little of lead me to the idea that
>> the station has stopped transmitting the PIDs in the PAT (again, I'm
>> not familiar with such things—hopefully you can make some sense).
>> Some folks on #mythtv-users suggested I mention here what I've found.
>>     
>
> It might transmit the channel under a different program number or on a 
> different channel.
>
>   
>> I can provide backend logs if you'd like.  Here's what "dvbsnoop -s
>> pidscan" had to say.
>>
>>     $ dvbsnoop -s pidscan
>>     dvbsnoop V1.4.00 -- http://dvbsnoop.sourceforge.net/
>>
>>     ---------------------------------------------------------
>>     Transponder PID-Scan...
>>     ---------------------------------------------------------
>>     PID found:    0 (0x0000)  [SECTION: Program Association Table
>> (PAT)] PID found:   48 (0x0030)  [SECTION: Program Map Table (PMT)]
>> PID found:   49 (0x0031)  [PES: ITU-T Rec. H.262 | ISO/IEC 13818-2 or
>> ISO/IEC 11172-2 video stream]
>>     PID found:   52 (0x0034)  [PES: private_stream_1]
>>     PID found: 4433 (0x1151)
>>     PID found: 8191 (0x1fff)
>>     $
>>
>> Could it be that the station is actually broadcasting a broken
>> stream?  Why should mplayer work and mythtv not?  Is there anything I
>> can do to help fix it (mythtv or the channel)?
>>     
>
> It finds a PAT and a PMT. I would need the decoded PAT and PMT and the 
> relevant entries of the channel and dvb_multiplex tables to tell what's 
> wrong. But rescanning that transport should fix it.

Rescanning did fix it, thank you. Sorry for bothering the dev list. I
did find some differences though that may be of interest.

The critical difference between the channel's old channel table entry
and the new one after rescanning were its "atsc_major_chan" and
"atsc_minor_chan" entries. Unlike all the other digital channels
(including the problem channel's old entry), both the "atsc_major_chan"
and "atsc_minor_chan" were set to "0" for the new rescanned entry.

Noticing that the rescanned channel didn't sort properly in the EPG,
even though I had its "channum" in the channel table correct, I updated
its "atsc_major_chan" and "atsc_minor_chan". The channel then sorted
correctly in the EPG, but /the old non-tuning behavior returned/!

So, I guess there are two curiosities, why:

    * A channel can't be tuned if the its "atsc_[major,minor]_chan" are
      set to a non-zero value
    * The EPG is sorting by "atsc_[major,minor]_chan" instead of "channum"

Thanks, y'all.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
Url : http://mythtv.org/pipermail/mythtv-dev/attachments/20070921/691db5d0/attachment.pgp