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

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

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
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.

Any ideas?

Oliver

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.



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