On 20.01.2009 22:18, Oliver Endriss wrote:
> Klaus Schmidinger wrote:
>> On 20.01.2009 16:01, Frank Schmirler wrote:
>>> On Tue, 20 Jan 2009 14:43:22 +0100, Alexw wrote
I have attached a raw TS capture (~10M) containing the PMT pid 132
which is revealing the problem.
>>> Hum - PID 132 is
Klaus Schmidinger wrote:
> On 20.01.2009 16:01, Frank Schmirler wrote:
> > On Tue, 20 Jan 2009 14:43:22 +0100, Alexw wrote
> >> I have attached a raw TS capture (~10M) containing the PMT pid 132
> >> which is revealing the problem.
> >
> > Hum - PID 132 is a french dolby track, not a PMT PID...
>
On Tue, Jan 20, 2009 at 04:11:17PM +0100, Klaus Schmidinger wrote:
> On 20.01.2009 16:01, Frank Schmirler wrote:
> > On Tue, 20 Jan 2009 14:43:22 +0100, Alexw wrote
> >> I have attached a raw TS capture (~10M) containing the PMT pid 132
> >> which is revealing the problem.
> >
> > Hum - PID 132 i
On Tue, Jan 20, 2009 at 04:01:17PM +0100, Frank Schmirler wrote:
> On Tue, 20 Jan 2009 14:43:22 +0100, Alexw wrote
> > I have attached a raw TS capture (~10M) containing the PMT pid 132
> > which is revealing the problem.
>
> Hum - PID 132 is a french dolby track, not a PMT PID...
>
> Cheers,
>
oops, it's a mistake. I am making reference to PMT pid 100 (sid 1537)
Thanks for having spotted that.
Cheers,
Alex
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
On Dienstag, 20. Januar 2009, Klaus Schmidinger wrote:
>
> VDR uses the (fixed) "pseudo" PMT pid 0x0084, which is 132.
> This was taken from some patch that implemented PAT/PMT handling
> (don't remember which one it was, maybe it was even the code from
> reel multimedia - not sure if I've missed m
On 20.01.2009 16:01, Frank Schmirler wrote:
> On Tue, 20 Jan 2009 14:43:22 +0100, Alexw wrote
>> I have attached a raw TS capture (~10M) containing the PMT pid 132
>> which is revealing the problem.
>
> Hum - PID 132 is a french dolby track, not a PMT PID...
VDR uses the (fixed) "pseudo" PMT pid
On Tue, 20 Jan 2009 14:43:22 +0100, Alexw wrote
> I have attached a raw TS capture (~10M) containing the PMT pid 132
> which is revealing the problem.
Hum - PID 132 is a french dolby track, not a PMT PID...
Cheers,
Frank
___
vdr mailing list
vdr@linux
Hi Mika,
I have already applied the mentioned patch ;-) But unfortunately it does not
solve the issue.
Cheers,
Alex
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
> I did check the TS stream with dvbsnoop and it is not containing corrupted TS
> packets.
>
> Apparently VDR is able to parse the PMT the first time the data buffer is
> used. Then, it seems to loose the sync inside the payload.
>
> I have attached a raw TS capture (~10M) containing the PMT pid 13
Hi,
I did check the TS stream with dvbsnoop and it is not containing corrupted TS
packets.
Apparently VDR is able to parse the PMT the first time the data buffer is
used. Then, it seems to loose the sync inside the payload.
I have attached a raw TS capture (~10M) containing the PMT pid 132 wh
On Mon, 19 Jan 2009 13:32:07 +0100, Alexw wrote
> Yes Frank you are right. The problem is coming from bad CRC in the
> PMT (and the same apply to bad PAT). If Pmt.CheckCRCAndParse() fails,
> bad PMT data should be skipped.
Bad CRC is caught by CheckCRCAndParse(). What I had in mind is a wrong va
Yes Frank you are right. The problem is coming from bad CRC in the PMT (and
the same apply to bad PAT). If Pmt.CheckCRCAndParse() fails, bad PMT data
should be skipped.
@Klaus: will you look at this enhancement before rolling out 1.7.4?
___
vdr m
On Mon, 19 Jan 2009 11:20:45 +0100, Alexw wrote
> I have already tested the inversion. Reducing the length and after
> moving to the new offset. This change does not solve the issue. The
> Length variable can still decrease to a negative value.
>
> What happen when the byte offset is greater tha
On 19.01.2009 11:06, Frank Schmirler wrote:
> Hi,
>
> On Mon, 19 Jan 2009 10:44:18 +0100, Alexw wrote
>> I have noticed a PMT parsing issue with VDR version 1.7.x. The bug
>> is still present in version 1.7.3 but the behaviour is worst because
>> it segfaults.
>>
>> First I found out that 2 line
I have already tested the inversion. Reducing the length and after moving to
the new offset. This change does not solve the issue. The Length variable can
still decrease to a negative value.
What happen when the byte offset is greater than 188?
_
Hi,
On Mon, 19 Jan 2009 10:44:18 +0100, Alexw wrote
> I have noticed a PMT parsing issue with VDR version 1.7.x. The bug
> is still present in version 1.7.3 but the behaviour is worst because
> it segfaults.
>
> First I found out that 2 lines where added in the ParsePmt method.
>
> Data +
Hi Klaus,
I have noticed a PMT parsing issue with VDR version 1.7.x. The bug is still
present in version 1.7.3 but the behaviour is worst because it segfaults.
First I found out that 2 lines where added in the ParsePmt method.
Data += Data[0] + 1; // this is the first packet
Length
18 matches
Mail list logo
