Just an additional info for the ones who want to help - the pvrinput-plugin passes through the TS from the HD PVR to
vdr, there's nothing changed.
So hopefully the plugin is not the one to blame for... :-)
I posted a sample PAT and PMT of the HD PVR in february, perhaps it can be
used to clarify something.
Am 02.09.2010 15:21, schrieb Rob Davis:
How do you go about understanding AC-3 within a VDR context?
(apart from reading up on it online - which now has my head spinning).
I have a Hauppauge PVR-HD and two ATSC cards. The ATSC cards work as they
should and with the new atsc/dn patch on
1.7.15 now have the correct dpids.
However, if I turn on add new transponders or update pids, then my Hauppauge
PVR channels lose their dpid values..
Sep 1 19:10:33 oac vdr:  changing pids of channel 920 from
4113+4097=27:0;4352=...@106:0:0 to 4113+4097=27:0:0:0
If I keep automatic channel updates off, then xineliboutput and streamdev work
for these channels, but vdr-vnsi (xbmc)
and vdr-xine don't (no audio)..
I'm assuming vdr parses the ac3 headers in some way and sends information onto
the playback frontend. How would I go
about seeing what those headers might be and looking into patching pat.c
I noticed all the comments about e-ac3 and wonder if a similar patch should be
made for this device.
As an aside, vdr recordings from these channels play back fine in vdr-xine.
So, more specifically, I suppose I would like to know how to find out the
I'm pretty sure it falls under this:
case 6: // STREAMTYPE_13818_PES_PRIVATE
But I'd be interested in seeing the flow through this section of pat.c and what
is happening.. Mainly to see if
something needs to be forced on?
I can create a five second VDR recording if someone wants to see what the TS
stream looks like.. But I'd be interested
in diagnosing it myself..
vdr mailing list