Oliver Endriss wrote:
Did this by chance happen while replaying (recording started by timer)?Klaus Schmidinger wrote:I guess I can now safely remove the DO_REC_AND_PLAY_ON_PRIMARY_DEVICE macro from dvbdevice.c. In one test I even did three simultaneous recordings plus one replay on my primary device without the slightest problem. The OSD, however, does get rather sluggish in such a scenario, but with the typical case one recording plus replay (which also covers time shift) everything works just fine now.
I suggest not to remove the DO_REC_AND_PLAY_ON_PRIMARY_DEVICE option because the firmware problem which caused the RTL recording bug has never been fixed. If they decide to change their transmissions again we should be able to use an old 0.9.4 firmware as a workaround. This is impossible without this option...
BTW, vdr 1.1.25 runs very stable here. I've been using both the vanilla 1.0.0pre2 driver and the development driver (dvb-kernel). During the last weeks I turned OSD on while cutting, fast forward, rewind. I was not able to produce a single ARM crash this way. Very good.
I noticed the following (very rare) problems:
(1) ARM crash when starting a recording
I had that with the 1.0.0pre2 driver. I downgraded to a snapshot from 29. Jan 03 (trying to do the binary driver checks you suggested on the DVB ML) and have not observed it after that, but I will wait for the 3sat Tagesschau today which often had a/v sync problems (parallel transmission on ARD is OK). The driver snapshot works with the new firmware.(2) A/V out of sync
(3) video ok, audio missing on ARD Each of these problems occurred once or twice in the last weeks, so it is nearly impossible to debug them.
Oliver
-- Info: To unsubscribe send a mail to listar@linuxtv.org with "unsubscribe vdr" as subject.