[vdr] Re: AW: Re: ARM crashed while cutting, VDR watchdog timer failed.

[Carsten Koch <Carsten.Koch@icem.de>]

Gunter Niedermeier wrote:
...
> you can easily produce an ARM crash by doing the following
...
> 4. When cutting has finished, replay the new file and jump between
>    the marks with the 7 and 9 keys, jump with the yellow and green
>    keys ( only for testing ) and you will see that ARM crashes.
>    There is no way to get the vdr running correctly again, until
>    you restart the complete DBV drivers and then the vdr.

I have done one more test and this time the ARM already crashed while 
I was trying to set the second mark. With the progress bar on screen, 
I was changing rapidly between pause, slow reverse, slow forward and 
play, trying to find the best point for the second mark.

The problem may have nothing to do with cutting at all. 
It is a well-known fact that the ARM firmware produces glitches 
in playback when the OSD is on. I assume that these glitches are
due to bugs in the firmware memory management? If that is the
case and if that means the ARM code is randomly overwriting memory, 
then of course it is just a matter of coincidence whether this bug
merely produces A/V glitches or a total crash.

I wonder why Klaus could not reproduce this.
It took me less than 5 minutes to crash the ARM and I did not
even try to. I only wanted to cut that recording.
So far, I tried cutting 2 recordings in 2 days and I got 2 ARM
crashes out of it. :-(

Assuming that the driver developers are unable or not willing to
fix this, does anyone have an idea for a workaround?
I still have hopes that an intelligently-placed usleep call in 
VDR can cure this.

Maybe the reason why Klaus is not seeing these is the fact that
his AMD K6/II 450 is just slow enough to not push the firmware
beyond its limits? 

Klaus, do you have a suggestion where I should place a usleep
before trying again?

Carsten.