Hi,
recently I got the evil VDSB error (with kernel 2.4.X :-(). After self restarting VDR continued the recording - but this fails with the "no tuner lock" error.
cStatus::Recording() was not called in this case. But the function was called to signal the end of this (never really startet) timer. Therefore there is a imbalance between start and stop status notifications - which may lead to some plugin misbehavior :-(
I'was not able to find quickly the way cTimer::Stop() was executed so I have no solution yet ...
Greetings, Bernd
----- Original Message ----- From: "Bernd Juraschek" vdr@bjusystems.de To: "VDR Liste" vdr@linuxtv.org Sent: Tuesday, October 25, 2005 11:09 AM Subject: [vdr] Status plugin interface bug?
Hi,
recently I got the evil VDSB error (with kernel 2.4.X :-(). After self restarting VDR continued the recording - but this fails with the "no tuner lock" error.
cStatus::Recording() was not called in this case. But the function was called to signal the end of this (never really startet) timer. Therefore there is a imbalance between start and stop status notifications - which may lead to some plugin misbehavior :-(
A few days ago i have another problem with the same effect. I want see EbS on Eutelsat received with dvb0, primary device was dvb1. No problem with dvb0 im "livemode", but in "transfermode" vdr can't set the 32 AudioPids (30 AudioPids in Transfermode are ok, but in a recording are only 27 show). I have start a recording, but nothing is recording. I must say that i use also the numbers of recordings in a plugin over status beginning with 0, when a recording starts, i increase the number and vice versa, and i have seen -1. Not so good, but it is the same you reported.
I'was not able to find quickly the way cTimer::Stop() was executed so I have no solution yet ...
Greetings, Bernd
Bernd Juraschek wrote:
Hi,
recently I got the evil VDSB error (with kernel 2.4.X :-(). After self restarting VDR continued the recording - but this fails with the "no tuner lock" error.
cStatus::Recording() was not called in this case. But the function was called to signal the end of this (never really startet) timer. Therefore there is a imbalance between start and stop status notifications - which may lead to some plugin misbehavior :-(
I'was not able to find quickly the way cTimer::Stop() was executed so I have no solution yet ...
Please try the following:
- add a funtion
bool IsAttached(void) { return device != NULL; }
to cReceiver (in receiver.h)
- call this function in cRecordControl::Stop():
void cRecordControl::Stop(void) { if (timer) { bool WasAttached = recorder->IsAttached(); // new line DELETENULL(recorder); timer->SetRecording(false); timer = NULL; if (WasAttached) { // new line cStatus::MsgRecording(device, NULL); cRecordingUserCommand::InvokeCommand(RUC_AFTERRECORDING, fileName); } // new line } }
Let me know if this helps.
Klaus
Klaus Schmidinger wrote:
Bernd Juraschek wrote:
Hi,
recently I got the evil VDSB error (with kernel 2.4.X :-(). After self restarting VDR continued the recording - but this fails with the "no tuner lock" error.
cStatus::Recording() was not called in this case. But the function was called to signal the end of this (never really startet) timer. Therefore there is a imbalance between start and stop status notifications - which may lead to some plugin misbehavior :-(
I'was not able to find quickly the way cTimer::Stop() was executed so I have no solution yet ...
Please try the following:
add a funtion
bool IsAttached(void) { return device != NULL; }
to cReceiver (in receiver.h)
call this function in cRecordControl::Stop():
I am confused as to where this new line above goes into receiver.h. Is it about line 50 (just before virtual ~cReceiver)?
Regards,
C.Y.M wrote:
Klaus Schmidinger wrote:
Bernd Juraschek wrote:
Hi,
recently I got the evil VDSB error (with kernel 2.4.X :-(). After self restarting VDR continued the recording - but this fails with the "no tuner lock" error.
cStatus::Recording() was not called in this case. But the function was called to signal the end of this (never really startet) timer. Therefore there is a imbalance between start and stop status notifications - which may lead to some plugin misbehavior :-(
I'was not able to find quickly the way cTimer::Stop() was executed so I have no solution yet ...
Please try the following:
- add a funtion
bool IsAttached(void) { return device != NULL; }
to cReceiver (in receiver.h)
- call this function in cRecordControl::Stop():
I am confused as to where this new line above goes into receiver.h. Is it about line 50 (just before virtual ~cReceiver)?
Yes, you can put it there - or better _after_ that line (doesn't make any difference, but that's e.g. where it is in player.h).
Klaus