[linux-dvb] Re: Driver doesn't replay recordings from RTL

[Holger Waechtler <holger@convergence.de>]

Oliver Endriss wrote:
> Klaus Schmidinger wrote:
> 
>>Marcus Metzler wrote:
>>
>>>Klaus Schmidinger writes:
>>> > Oliver Endriss wrote:
>>> > > Klaus Schmidinger wrote:
>>> > > > Since yesterday (maybe even earlier) the driver (CVS version
>>> > > > 2002-12-08) doesn't replay (new) recordings from RTL any
>>> > > > more. It behaves just as if it had been set into "pause"
>>> > > > mode.
>>> > >
>>> > > Maybe this is the same bug I wrote about in the thread
>>> > >
>>> > > "Hard time reading MPEG2s + Sat lock with Hauppage WinTV Nexus DVB-s":
>>> > > | Some recordings done with vdr 1.0.4 won't replay cleanly. I
>>> > > | started looking into this and found that the problem
>>> > > | disappeared when I replaced the firmware (Root, Dpram) of
>>> > > | the new driver with that of the 1.0.4 driver.
>>> > >
>>> > > Could you try the old firmware with the new driver?
>>> >
>>> > Ok, looks like the problem is in the firmware.
>>> > I tried the firmware from 2002-06-23 with driver 2002-12-08 and
>>> > VDR 1.1.20 and it replayed new RTL recordings just fine.
>>> >
>>> > Further tests showed that the problem was introduced between
>>> > 2002-09-18 and 2002-09-19, which is apparently the date when the
>>> > firmware switched from
>>> >
>>> >  254324 Apr 15  2002 Root
>>> >
>>> > to
>>> >
>>> >  254444 Aug 30 12:50 Root
>>> >
>>> > Since I have been using this new firmware for quite a while and
>>> > it always worked fine with recordings from RTL I still assume
>>> > that RTL must have changed something in their data format that
>>> > triggers a bug in the new firmware.
>>> >
>>> > So, once again, we're at a point where we have to hope that one
>>> > of the driver developers will find the time to fix this in the
>>> > firmware...
>>>
>>>Are you sure it's the playback, not the recording process? Did you
>>>try playing with mplayer? It works with rtuxplayer and our current
>>>firmware, which should not be different from the CVS firmware, of
>>>course the driver is much different now.
>>
>>One more thing: there appears to be a "matrix" of possibilities here:
>>
>>                     CVS driver        "Metzler" driver
>>
>>old firmware            ok                    ???
>>
>>new firmware          not ok                   ok
>>
>>So a new recording can be replayed with the CVS driver only when the
>>old firmware is used, but _your_ driver can replay it even with the
>>new firmware (don't know about your driver and the old firmware, but
>>that's probably not really interesting). This would indicate that
>>only the combination of CVS driver and new firmware can't replay new
>>RTL recordings, and that the problem should be fixable in the CVS
>>driver. However, although I did do several tests with it and
>>generated lots of debug output, I couldn't find anthing that could be
>>changed in order to fix this. I always ended up seeing the driver
>>wait for some activity of the firmware...
> 
> 
> Assuming that the "Metzler" driver is just the old driver,
> I can't confirm this. A few minutes ago I tested

I talked with Klaus, this was not his test result, he just assumed that 
the Metzler driver and firmware would work consistently. This is 
unfortunally not the case.


> vdr-1.0.4 + old driver + new firmware
> and got exactly the same problem...
> 
> Back to the new driver + new firmware.
> Here are the results of my debugging session(s):
> When the problem occurres, the video ringbuffer fills up 
> because  gpioirq()/DATA_MPEG_PLAY/pes_play(...&av7110->avout...) is 
> not called anymore. Apparently, the interrupt for the video data 
> stream does not occur anymore. Audio interrupts still occur, that's 
> why the audio ringbuffer is empty after a short time.
>
> After the problem occurred, it's no problem to replay a non-RTL 
> recording, so there is no hard deadlock in the firmware or something 
> similar.

thanks for this info, this will help to find the problem.


> P.S.:
> Are there any specs available which describe the protocol between the 
> ARM and the host processor? Even some simple diagrams would be useful.

No. unfortunally this protocol is derived from the original Technotrend 
Firmware, so we can't give any information. You'll have to document this 
on your own...

Holger



-- 
Info:
To unsubscribe send a mail to listar@linuxtv.org with "unsubscribe linux-dvb" as subject.