[vdr] Re: [PATCH] (DVB-T) statmux fix vbr tagging for pic header

[Oliver Endriss <o.endriss@gmx.de>]

Gregor Lawatscheck wrote:
> At 17:32 18/05/2003, you wrote:
> >Has anyone encountered problems after applying the patch?
> >
> >For me everything works fine.
>
> The patch itself doesn't make it worse, it certainly makes it better.
> I've tested the driver without the patch and tuned to a channel which
> usually works with it (meaning it doesn't deadlock straigh away).
> After about an hour there was the same ARM crash with the buffer
> running full. It appears related and the patch doesn't cover it or
> it's a completely different deadlock situation.

Please post your system setup. Are you watching in transfer mode?

Arm crashes might have some other reasons:
- hw failure
- bad signal with full-featured cards
- interrupt sharing/not enough cpu power (???)

> My first thought then was it could be the PCR that is going out of
> sync after a while and eventually crashes things (then again it
> should only be non-lipsync) so I made sure every channel had the
> correct PCR PID set. Same result.

PCR is never used in transfer mode, only during *live* view. 
Therefore, PCR is not included in recordings.

> I've read through the Texas Instruments av711x documentation (
> http://www.linuxdvb.tv/documentation/AV711x_3_1.pdf ) which states in
> section 11.2 that the decoder is "free running" i.e. not synced on
> tuning to a channel, then activates PCR, then looks for PTS. The
> whole process to sync can take around 3 minutes or so it says.
>
> What I'm wondering at the moment is whether the deadlock can be
> reproduced with a specially crafted MPEG2 file or whether there is
> some kind of unpredicable crash.

If it is related to the vbf_delay, this should be possible.

> I don't yet comprehend things about
> av7110 debitypes in av7110.c. Has this to do with the typ of card or
> system (i.e MHz of processor) etc. so could it be that some people
> get deadlocks and others don't. Odd.

debitype has nothing to do with card/system types. It is used in debi 
and gpio interrupt/tasklet processing. IIRC I could produce a debi/gpio 
irq oops if I overloaded the system (not enough cpu power).

> What was changed in the firmware to include timshifting on one card?
> Are the buffers smaller or in another part of the RAM or something?

I don't know. Only the driver developers can answer this question. 
As these changes trigger the RTL bug, it might be possible to locate the 
bug in the firmware.

Oliver


-- 
Info:
To unsubscribe send a mail to ecartis@linuxtv.org with "unsubscribe vdr" as subject.