[vdr] Re: vdr[3330]: ERROR: can't record MPEG1! - possible cause

[Usenet-372111@zocki.toppoint.de (Rainer Zocholl)]

andreas@aschultz.net(Andreas Schultz)  22.09.01 15:09

Once upon a time Andreas Schultz shaped the electrons to say...

>Rainer Zocholl wrote:

>> andreas@aschultz.net(Andreas Schultz)  21.09.01 13:19
>>
>> Once upon a time Andreas Schultz shaped the electrons to say...

>> I added a mean Software delay loop.
             ~~~~

>>
>> volatile int iTime=0;
>> void cTS2PES::instant_repack(const uint8_t *Buf, int Count)
>> {
>>   int c = 0;
>>
>>   while(iTime< 40000)
>>   {iTime++;};
>>   iTime=0;
>>
>>
>>  (the 40000 was "hand optimized", 100000 leads
>> "buffer 100%" messages...)
>> That seems to be better, but no solution.
>> (It's of cause not the right place.
>> Too the power consumption rises from below 50W to over 75W!)


>the loop is to tight, you have to insert an usleep here. 

But I don't want to gave up the cpu "voluntary"! :-)
(I assume usleep() would do? I mention the increased power
comsuption only as a proof, that the loop is really running.)

The loop delays enough because the "volatile" and the
"outside" declaration prevents compiler from optimzing it
away. (Optimizer else would say: "Ey i know that iTime will
always be 40001, so i left away the dummy looping."
Clearin iTimer after the loop (which looks maybe seldom,
but on the first view everybody normaly would clear a counter 
before the loop, and not after wards) prevents the optimizer too 
to assume anything about the (final) contents of iTime.)

>But busy loops, and especialy tight one like yours, are always a bad idea.
>Avoid them, whenever possible.

Yes, of cause.
That's absolutely clear.
I did that only to "proof" if my card would maybe be broken.


With that delay:
only seldom the error message
after removing the delay: immediately the bad message
after starting a recording on the second card.

In both cases:
The records are unusable.
The lower part of the image is scrambled of longer parts
of the recording.