Mailing List archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Andreas.Schultz@aschultz.net(Andreas Schultz)  23.09.01 13:31

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

>Klaus Schmidinger wrote:

>> What _could_ be changed is the setting of 'lockingPid = getpid()',
>> which would make sense to be done only inside the 'if' branch. But
>> then agian, I don't think that that would make any difference.
>>
>> Please correct me if I'm wrong, but as far as I can see there is no
>> race condition here, so I guess using recursive mutexes won't get us
>> any further (except that channel switching will hang).


>Meanwhile, i believe that it is very unlikely that we would hit this
>race under normal circumstances.

Emm, software have to work always, and not sometimes/mostly... ;-)
and can be made so.
Else you will debug forever.. ;-)

Just a question:

pthread_mutex_lock(&mutex); 
does not return any error value?
Or is it just "not likely" that will be any problem?

(remember: 
Writes never fails, resources like memory are unlimited... ;-) )


"Unlock" should be implemented as "RestoreLock"
This avoid the biesty error given up the lock in a
subroutine accidently. (See how interrupt/smp-locks are
implemented in kernel).



But you are right that this seems not be the
problem why the data in the buffer seems to be garbage.

The change of the mutex handling with your patch did not 
change the behavoir of VDR on my maschine when recording 
on the second board.
The "MPEG!" occurs sometimes in the first 1 second
(i don't know how long is will last until the buffer is full)

The recordings done with the second card are unusable.
The recordings done with the frist card are -almost- error free.
(I now found/see some smal/seldom artefacts there too)

Only one thing that "advances" record quality was the
"mean"(q&d) softwaredelay.


Next week i will see if i can lent somewhere another 
nova, to ensure that the card is not broken tho.
Or is there an other way to test the card to make
shure that there is no hardware flaw?

But if the card is broken, why does this lead to Kernel Panic?




Home | Main Index | Thread Index