Hi
thanks for this future option, I have the same problem not caused directly by card or drivers but in a multiple frontend system (dvb-s + dvb-t) if at least one provider did not send signal , you loose all other concurrent records
It can be interresting to use the emergency shutdown only when there are no other records running at the same time
Regards
Le samedi 29 septembre 2007 11:06, Klaus Schmidinger a écrit :
On 09/29/07 09:30, Timothy D. Lenz wrote:
I don't know about it restarting. The crashing with loss of signal is suposed to be a safe guard against creating blank recordings. Seems like a bad idea to me to. Just delete the bad recordings, don't crash the system.
Well, let me just comment on the nomenclature here ;-) When VDR does an "emergency exit" because there is no video data for a while, this is a *controlled* action that shall allow the driver to be reloaded. Full featured cards sometimes have the problem that they completely lock up, and reloading the driver fixes this.
So this can *not* be called "crashing", and especially not "crashing the system", because I'm pretty sure your Linux system will not be affected by this.
Here is the fix we've been using:
Locate the line in recorder.c and comment it out.
esyslog("ERROR: video data stream broken");
ShutdownHandler.RequestEmergencyExit();
- // ShutdownHandler.RequestEmergencyExit();
Since several users have been complaining about this in the past, I'll make this a setup parameter in one of the next versions, so everybody can decide for themselves whether they prefer lost recordings or an occasional restart.
Klaus
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
-------------------------------------------------------
dom.plu wrote:
It can be interresting to use the emergency shutdown only when there are no other records running at the same time
Sounds like a good idea: Emergency exit on failing to record: * Never * Only if this doesn't break other recordings * Always
Maybe this could even be based on recording priority: Only do an emergency exit if there's no other recording of same or higher priority that would be interrupted by this.
(btw, the emergency exit saved dozens of recordings for me, as reloading the DVB driver also powers down the sat system, and this fixes mysterious tuning / band switching issues for me)
Cheers,
Udo
Coincidently, I just had this "broken video stream" emergency exit the other day because of bad weather that came & went. I don't run some kind of auto-restart script so vdr stayed unloaded and coincidently caused several other timers to be missed.
For those who would say 'just add auto-restart', I respond by saying that I don't want it. If my vdr system crashes, I want to know about it and then look into the reason why so it can be fixed properly thus making a more stable system. Also, in the case the reason for the crash requires human intervention, I don't want my vdr system stuck in a continuous restart loop. Many people seem to share these opinions so I guess the vdr community has mixed feelings about it.
As far as empty recordings, it's my personal opinion that who cares? If you had a timer set then you intended to use the diskspace anyways so it doesn't matter if it's filled with blank or the actual show you wanted to record.
A quick note to Klaus.. Thanks for adding the ability to have this emergency exit an option to the user! Please consider Udo's suggestion in what options should be available. Also, its been some time since I've had a Nexus-S lockup. Long enough that I can't remember the last time (although I've experienced it before). I update my drivers frequently (basically along with every kernel update that's released, stable and testing) and it's possible the lockup issue was fixed quite some time ago. Rather then have vdr shutdown, unload dvb drivers, reload dvb drivers, reload vdr...maybe the better solution is to just update your drivers. :)
Thanks guys!
-Derek
Since the recording is scheduled, I would assume the user has room on the disk (so disk space usage is not really the problem). The only problem I can see is that you might get a blank recording if the signal goes out (and you think its recorded but its not). So, perhaps vdr should NOT do a emergency exit, but instead, just mark the recording as possible incomplete?
Regards.
On Sunday, 30. Septemberta 2007 10:35:07 Stone wrote:
Since the recording is scheduled, I would assume the user has room on the disk (so disk space usage is not really the problem). The only problem I can see is that you might get a blank recording if the signal goes out (and you think its recorded but its not). So, perhaps vdr should NOT do a emergency exit, but instead, just mark the recording as possible incomplete?
How about, when there is no stream - no writing to HD.. OK, if there is 15 minutes break middle of stream, then recording "jump" those 15 minutes during playback. OR when no stream, in a recording there is recorded (in a picture) word "no stream", static picture takes little space and who is watching knows that what has happend!
JJussi wrote:
On Sunday, 30. Septemberta 2007 10:35:07 Stone wrote:
Since the recording is scheduled, I would assume the user has room on the disk (so disk space usage is not really the problem). The only problem I can see is that you might get a blank recording if the signal goes out (and you think its recorded but its not). So, perhaps vdr should NOT do a emergency exit, but instead, just mark the recording as possible incomplete?
How about, when there is no stream - no writing to HD.. OK, if there is 15 minutes break middle of stream, then recording "jump" those 15 minutes during playback. OR when no stream, in a recording there is recorded (in a picture) word "no stream", static picture takes little space and who is watching knows that what has happend!
Static picture is a good idea! The timeline would be correct (sometimes it matters), it would clearly state that there is problem with the stream and it does not take too much space from HD.
Br, Pasi
On 9/30/07, JJussi linux-dvb@jjussi.com wrote:
On Sunday, 30. Septemberta 2007 10:35:07 Stone wrote:
Since the recording is scheduled, I would assume the user has room on
the
disk (so disk space usage is not really the problem). The only problem
I
can see is that you might get a blank recording if the signal goes out
(and
you think its recorded but its not). So, perhaps vdr should NOT do a emergency exit, but instead, just mark the recording as possible incomplete?
How about, when there is no stream - no writing to HD.. OK, if there is 15 minutes break middle of stream, then recording "jump" those 15 minutes during playback. OR when no stream, in a recording there is recorded (in a picture) word "no stream", static picture takes little space and who is watching knows that what has happend!
I think most importantly that we know that there is a possible problem with the recording because a flag got set that the signal was lost. But, I understand what you are saying... perhaps VDR should be integrated with femon :)
Best Regards.
JJussi wrote:
How about, when there is no stream - no writing to HD.. OK, if there is 15 minutes break middle of stream, then recording "jump" those 15 minutes during playback.
To clear things up: Of course, if there's no stream for whatever reasons, VDR already does NOT write anything to disk, as there is no incoming data that could be written.
In fact, the emergency exit is triggered because there was 0 bytes of data in one minute of recording.
Cheers,
Udo
-
dom.plu -
JJussi -
Pasi Juppo -
Stone -
Udo Richter -
VDR User