At 11:00 14/05/2003, you wrote:
I have to admit there seems to be an issue with loading and unloading various firmwares in succession. So it's hard reliably reproduce it working with old firmware. The one time I managed to play this file with the current CVS and 0.9.4 firmware it did hang at 0.3 seconds for about 4 seconds and then played the rest. Usually it just locks up but then again that I could could as well be because the firmware is so old.> It only happens at the start of the stream never anywhere in the > middle - so it's basically the inital sync. Drivers in question are > newstruct ever since it was forked (I've tried this out) - the "bug" > then found it's way into the new head and remains there. I've also > tested all firmwares from Jan 2002 (0.9.4) to April 2003 - it doesn't > appear related. No, this is *not* true. I tested your file and it works with 0.9.4 firmware and the current CVS driver. Please check again. Don't forget to recompile the driver after replacing Root and Dpram (make clean; make)!
Interesting. OK, I guess rather than trying to explain why the old firmware and drivers did things differently we ought to see whether the current firmware and drivers can be made to play these channels / recodings reliably.IMHO it's the good old RTL bug which strikes again. All firmware releases which support 'timeshift with one card' have this problem. This bug has never been fixed.
Yes, indeed this sounds very much like it. I believe this happens with the new firmware / drivers when a stream is VBR but not tagged as one. Could it be that the RTL mux played around testing statmux VBR for a while and then went back to constant bitrate? Are there statellite muxes that use statistical multiplexing or are most programmes still at a constant bitrate?This is what I found when I debugged the RTL problem last year: | 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.