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 [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
