Hi!
Yesterday, here at Southern Finland one of the TV channels had "cut out" at DVB stream (like half hour). And because that stream disapeared little after than recoding has started, VDR started to restart itself every minute because there was no stream... What is point to that, that VDR do restart IF there is no stream what it should record.. That affected to all other recordings too because vdr was restarting itself constantly. Not good! Is there "setting" somewhere where you can say that "do not" restart if there is no stream.
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. 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();
----- Original Message ----- From: "JJussi" linux-dvb@jjussi.com To: "VDR Mailing List" vdr@linuxtv.org Sent: Friday, September 28, 2007 11:49 PM Subject: [vdr] Not good behaviour from vdr
Hi!
Yesterday, here at Southern Finland one of the TV channels had "cut out"
at
DVB stream (like half hour). And because that stream disapeared little
after
than recoding has started, VDR started to restart itself every minute
because
there was no stream... What is point to that, that VDR do restart IF there is no stream what it should record.. That affected to all other recordings too because vdr was restarting itself constantly. Not good! Is there "setting" somewhere where you can say that "do not" restart if
there
is no stream.
-- JJussi
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Klaus Schmidinger schrieb:
On 09/29/07 09:30, Timothy D. Lenz wrote:
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.
I think, thats a good idea :-)
Thomas
I like these ideas... NO SIGNAL image in recording during no signal. Or that if no signal then no writing to disk. And a warning in the log about a possible incomplete recording cuz of lost signal + identified in recordings menu by a special char like ? maybe.
These are all good options and would please everyone I think.
On 9/30/07, VDR User user.vdr@gmail.com wrote:
I like these ideas... NO SIGNAL image in recording during no signal. Or that if no signal then no writing to disk. And a warning in the log about a possible incomplete recording cuz of lost signal + identified in recordings menu by a special char like ? maybe.
I like the idea of appending the "?" symbol to every recording that triggers the "no signal" flag.
Best Regards.
Should be on loss if video, not just loss of signal. Doesn't happen often, but I have seen video go during a storm while femon still says there is a lock. ----- Original Message ----- From: Stone To: VDR Mailing List Sent: Sunday, September 30, 2007 11:38 AM Subject: Re: [vdr] Not good behaviour from vdr
I like the idea of appending the "?" symbol to every recording that triggers the "no signal" flag.
Best Regards.
VDR User wrote:
I like these ideas... NO SIGNAL image in recording during no signal. Or that if no signal then no writing to disk. And a warning in the log about a possible incomplete recording cuz of lost signal + identified in recordings menu by a special char like ? maybe.
I do not like the idea of an NO SIGNAL image. I don't want any subliminal messages for short losses of video. If you really want to pad the video, then either using the last frame of a black picture should be enough.
yours, Jouni
On 9/30/07, Jouni Karvo jouni.karvo@tkk.fi wrote:
VDR User wrote:
I like these ideas... NO SIGNAL image in recording during no signal. Or that if no signal then no writing to disk. And a warning in the log about a possible incomplete recording cuz of lost signal + identified in recordings menu by a special char like ? maybe.
I do not like the idea of an NO SIGNAL image. I don't want any subliminal messages for short losses of video. If you really want to pad the video, then either using the last frame of a black picture should be enough.
That's not exactly subliminal and it could easily be optional. Some guys will prefer it and some won't. For example it would be an easy indicator to identify what exact time in the recording the loss occured.
I see no bad reason these options can't be added, and no good reason they shouldn't be.
user.vdr@gmail.com(VDR User) 30.09.07 13:37
On 9/30/07, Jouni Karvo jouni.karvo@tkk.fi wrote:
VDR User wrote:
I like these ideas... NO SIGNAL image in recording during no signal. Or that if no signal then no writing to disk. And a warning in the log about a possible incomplete recording cuz of lost signal + identified in recordings menu by a special char like ? maybe.
I do not like the idea of an NO SIGNAL image. I don't want any subliminal messages for short losses of video.
In any normal recording currently you would not realize that there is missing anything (except(maybe): music).
So a "no signal" combined with "Signal information" would be helpful. If you want to cut it "no adds" will be able to find these "breaks". Currently "no adds" will not detect the interruptions! No chance!
If you really want to pad the video, then either using the last frame of a black picture should be enough.
That's not exactly subliminal and it could easily be optional. Some guys will prefer it and some won't. For example it would be an easy indicator to identify what exact time in the recording the loss occured.
Once uppon a time i wondered why some days some recordings were broken resp. where not done.
After weeks i realized that this happen only when an recording using the DVB-T card. That was caused because someone removed the terristic anntenna: "We ara all using sat" ;-)
If the recordings would consist of "no stream" and "zero signal level" or massbe BER the problem would have been obious.
I see no bad reason these options can't be added, and no good reason they shouldn't be.
ACK.
Rainer
Klaus Schmidinger wrote:
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.
I wonder whether reloading modules is still an appropriate action. Nowadays it's possible for example to bind/unbind drivers to/from specific devices. Ie if you have multiple dvb-ttpci cards it should be possible to reset a specific one. Maybe it would even be possible to implement some kind of reset ioctl in the kernel drivers so vdr doesn't need to rely on external scripts at all.
cu Ludwig
Ludwig Nussel ludwig.nussel@suse.de writes:
[...]
I wonder whether reloading modules is still an appropriate action. Nowadays it's possible for example to bind/unbind drivers to/from specific devices. Ie if you have multiple dvb-ttpci cards it should be possible to reset a specific one. Maybe it would even be possible to implement some kind of reset ioctl in the kernel drivers so vdr doesn't need to rely on external scripts at all.
Oh, that would be wonderful ! It's only my ff card that crashes. I'm running vdr inside a domU (unfortunatly atm it's running 2.6.18). And after a while the firmware doesn't get loaded anymore => "saa7146_vv: saa7146_vv_init(): out of memory. aborting." (iirc, it's an old bug resolved in recent kernels)
By the way, does the budget patch fix the crashing of FF cards ? (I know it's not a fix, since i'm only using software decoders i might consider the modification if it prevents the ff from crashing)
ludwig.nussel@suse.de(Ludwig Nussel) 01.10.07 14:28
Klaus Schmidinger wrote:
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,
That's long time ago and IMHO only a problem on unmodded v1.3 cards or "not perfect" ARM firmware at that time, 3 or more years ago (At least i got rid of the problem by -expensive- upgrading to 2.0 cards. (Someone interessted in 1.3 cards, 220E each?)). (see http://vdr-wiki.de/wiki/index.php/SpannungsMod). So it maybe only a problem for the unlucky owers of unmodded 1.3.
In a multi card system it would be possible to check if other cards are are having a stream and not to reboot while they are successfully recording.
In a single card system a check if other recordings (on the same transponder) are working would be a strong indication that a reset would not solve the problem and would make the problem worse my breaking the other recording too.
If no other recording is running a tuning attempt to a "well known good working" transponder/programm would allow to determine a broken driver/card from a missing antena oder broken hardware, where a reboot will usally not help.
and reloading the driver fixes this.
I wonder whether reloading modules is still an appropriate action.
That "hard way" has only historical reasons AFAIK. Once there was a time, when the hardware(!) tends to hang. (ARM bugs, bad power supply filtering, design errors of the card)
Nowadays it's possible for example to bind/unbind drivers to/from specific devices. Ie if you have multiple dvb-ttpci cards it should be possible to reset a specific one.
Maybe the PCI powermanagement can used to powerdown the one hanging card.
Maybe it would even be possible to implement some kind of reset ioctl in the kernel drivers so vdr doesn't need to rely on external scripts at all.
It would be very help full.
The first big step would be if it would be possible to suppress the restart process finally issued by VDR to reanimate "dead" cards. At least users of 2.0 cards will be made very happy on bad weather conditions! (Which usually cause VDR to restart/reboot making replay implassinble too. Too it is not possible to quickly dectivate the time for that recording: 60sec are too short to trigger that window (may i assume VDR blocks RC command processing during detecting a broken stream?))
Rainer
Rainer Zocholl:
That's long time ago and IMHO only a problem on unmodded v1.3 cards or "not perfect" ARM firmware at that time, 3 or more years ago (At least i got rid of the problem by -expensive- upgrading to 2.0 cards. (Someone interessted in 1.3 cards, 220E each?)). (see http://vdr-wiki.de/wiki/index.php/SpannungsMod). So it maybe only a problem for the unlucky owers of unmodded 1.3.
Is that somewhere to be read in english (or finnish) since my german is, well it does not exist :)
\Kartsa
Yesturday I had the same problem where a very bad but short storm caused my signal to drop and vdr again performed an emergency exit when it wasn't wanted. I already commented out the EmergencyExit request in recorder.c but this time it was generated in remux.c by:
if (!synced && skipped >= 0) { if (skipped > MAXNONUSEFULDATA) { esyslog("ERROR: no useful data seen within %d byte of video stream", skipped); skipped = -1; if (exitOnFailure) ShutdownHandler.RequestEmergencyExit(); } else skipped += used; }
Is it safe to comment this ShutdownHandler.RequestEmergencyExit(); as well?
Thanks.
On 10/9/07, VDR User user.vdr@gmail.com wrote:
I was hoping some of these ideas would have made it into the next release. But, since it didnt, does anyone have a patch put together?
Best Regards.
What is point to that, that VDR do restart IF there is no stream what it should record.. That affected to all other recordings too because vdr was restarting itself constantly. Not good! Is there "setting" somewhere where you can say that "do not" restart if there is no stream.
This has been discussed before, and the conclusion was that VDR cannot know if DVB-driver/card has failed or transponder. So it restarts itself to reload drivers.
I think easy fix should be that VDR tries to tune the same card to other channel, then to other transponder to see if data is received.
Symptom: cannot record data - recorded channel seems to be dead (no data received, previously VDR restart) - fix1: tune same card to another channel on same transponder - if works tune back - fix2: tune same card to another channel on another transponder - if works try recording again - fix3: restart VDR
So in theory VDR should do ping-pong loop between problem and fix1 (or fix2) the time of the timer. And try to avoid 100% CPU load with busy looping on this. So no restart if card seems to be working -> channel & transponder seams to be down.
Naturally if there is a CAM-module, reset of CAM-module should be taken into equasion. And reset of smart card etc.
Then setting on menu that "abandon timer if channel not available with-in [user defineable minutes] from timer start". This would free the DVB card for other recordings.
Also a logic for fix3. If this card it stuck, but there is another free card to record show, and other recordings on other transponders, do not restart.
How does that sound?
BR, Jori
jori.hamalainen@teliasonera.com wrote:
How does that sound?
Complicated. And you did not even consider cases such as: The card is receiving perfectly another channel on the same mux, so tuning to another mux would not be an option. Although it is easy to add conditions like this to the code, it would mean the system would not become stable for people that have no hardware problems (but only the uncontrollable controlled graceful restart loop problem) in a very long time.
The solution with three options sounds best: restart always, if no other (working) recordings, never.
It is simple and should fix the problem.
yours, Jouni
How does that sound?
Complicated. And you did not even consider cases such as: The card is receiving perfectly another channel on the same mux, so tuning to another mux would not be an option.
This was the FIX1. Transponder = mux = 'kanavanippu'. The tests was for VDR to better understand if DVB card is functioning. If it is working OK, like receiving another channel on same mux, or on different mux then card / DVB driver is fine, no need to restart VDR.
Because I've seen this restart cycle many times, and only way out of it is editing via [your favorite editor] the timers.conf file.
Because between restart cycles you don't have enough time to enter timers menu and disable timer. I don't know if this has changed on current code, but this was problem earlier (1.3.x VDRs) on my setup.
jori.hamalainen@teliasonera.com wrote:
How does that sound?
Complicated. And you did not even consider cases such as:
...
Because I've seen this restart cycle many times, and only way out of it is editing via [your favorite editor] the timers.conf file.
I have seen the problem too. Just removing timers for the failing channel does not help if you use autotimers. The way out of it is to comment out a line or two in recorder.c-file, which I did on Saturday, but my wife lost interest in watching prof. Capellari's investigations during the time it took.
But I think you missed my point - which is not a wonder, considering my writing. So I'll try to say it more clearly:
- the restarting cycle tries to solve a faulty hardware driver problem for some specific cards - outside the hardware driver - ideally, the driver would work without reloading - reloading is done as it seems the hardware driver will not get fixed. (I hope moving to DVB-S2 will make this problem obsolete, btw.) - as it is just a hack that is in the wrong place, and hopefully later obsolete, a simple solution should be chosen. - the configuration option is a simple solution.
yours, Jouni
Moin,
The solution with three options sounds best: restart always, if no other (working) recordings, never.
But this doesn't stop the "VDR started to restart itself every minute"- problem completely. If there was already one emergency exit shortly before and the stream didn't come back, it doesn't help to restart again. And again. And again ...
So an additional parameter "Minimal time between emergency exits (minutes)" IMHO would help
Gruss, Walter
Walter Koch schrieb:
Moin,
The solution with three options sounds best: restart always, if no other (working) recordings, never.
But this doesn't stop the "VDR started to restart itself every minute"- problem completely. If there was already one emergency exit shortly before and the stream didn't come back, it doesn't help to restart again. And again. And again ...
So an additional parameter "Minimal time between emergency exits (minutes)" IMHO would help
Maybe a solution for all the ideas in here ? Let vdr call a command and decide based on exit status ? This could be simply set to /bin/false for never restart or any sophisticated logic for everything else ?
Maybe a solution for all the ideas in here ? Let vdr call a command and decide based on exit status ? This could be simply set to /bin/false for never restart or any sophisticated logic for everything else ?
The main problem for me is that my reception is not that great. During bad weather, I often lose signal. Now, if vdr happens to be recording when that signal is lost, it will do an emergency exit. Restarting isnt going to make the weather get any better. It will just keep restarting, over and over. As soon as the rain stops, the signal comes back and vdr is fine. Perhaps having to reload the drivers is only a problem for people using old kernels. I just want to know if my recordings are corrupted or not w/o having to watch them first. If I am not home when the problem occurs, I want to be able to tell which ones are bad w/o having to watch it and notice the end of the show is missing. Marking the recording in the Recordings Menu with any symbol you want is good enough for me, but forcing vdr reload the drivers over and over during every storm doesnt seem like the right thing to do either. When the reception comes back, vdr works just fine.
Best Regards.
Best Regards.
There are some great suggestions in the beginning of this thread, please let's not create a complicated solution where it's unnecessary to have one. Let the user decide the behavior he wants and leave it at that. No need/want for vdr to try auto-tuning this channel or that transponder, or emergency, or emergency in X minutes, etc... Using auto-solutions is exactly what the users don't want! They want to choose the behavior themselves!
-
JJussi -
jori.hamalainen＠teliasonera.com -
Jouni Karvo -
Kartsa -
Klaus Schmidinger -
Ludwig Nussel -
Steffen Barszus -
Stone -
syrius.ml＠no-log.org -
Thomas Creutz -
Timothy D. Lenz -
UseNet-Posting-Nospam-74308-＠zocki.toppoint.de -
VDR User -
Walter Koch