Then the message appears: "Next recording in -xx minutes - Shutdown anyway ?" When I now press ok the shutdown routine will be called and the timer given to the shutdown script is in the past, so the machine will shut down but never wake up again. Any easy solutions for this ?
There's no simple solution to this, I think. I remember that this has been discussed before, however without results. Using nvram-wakeup, the nvram script will complain next and shutdown will not work, you have to disable all running timers and all close timers, or nvram-wakeup wont shut down.
And with acpi it will shutdown but never wake up, depending on the shutdown script.
The current solution just uses the remaining time to the next timer, and thats the running one of course.
Thats not a solution - thats a bug :) The shutdown script should get the starttime of the next timer in the future, not a time in the past.
A proper solution would have to skip over the offending timers to get the next timer that is at least xx minutes in the future. Probably the easiest and most radical solution is to really disable (or skip) all offending timers after each confirmation.
I've made some tries into this direction, but none of these are working correct with repeatable timers. The only solution which works reliable is to disallow shutdown when a recording is active.
Bye Helmut
vdr@helmutauer.de wrote:
Thats not a solution - thats a bug :) The shutdown script should get the starttime of the next timer in the future, not a time in the past.
Even if the next timer is, lets say, 10 seconds in the future? Will your machine shut down and reboot within 10 seconds?
You have to skip all timers that are a few minutes in the future, or the machine may still not wake up.
I've made some tries into this direction, but none of these are working correct with repeatable timers.
Repeating timers can be disabled by calling cTimer::Skip(). One-shot timers should be disabled, not deleted, probably using ClrFlags(tfActive).
Cheers,
Udo
Hi list,
Based on a first patch by Helmut Auer, here's a patch to solve the shutdown on running timers issue. I did some simple tests and it seemed to work, however the patch is still experimental.
The patch basically disables the offending timers up to MinEventPause minutes in the future. There's also some endless loop detection that imho should be impossible to trigger.
Some issues: - If you decide to cancel the shutdown after confirming it first, timers will remain disabled. Thats probably not what the user expects.
- Disabling pending timers up to MinEventPause may not what the user expects either. I have set MinEventPause to 11 minutes (5 for shutdown, 5 for wakeup, 1 to avoid race conditions). But if an user has set this to 120 minutes for example, then the question "Recording in 100 minutes, shut down anyway?" doesn't sound like VDR wont wake up for it.
- A clean implementation should merge both loops into one function and move the code into cTimers (API change!). (the two loops are required to skip negative values for "Recording in xx minutes")
Cheers,
Udo
--- vdr-1.4.1-orig/vdr.c 2006-07-25 15:48:14.000000000 +0200 +++ vdr-1.4.1/vdr.c 2006-07-25 16:39:38.943900248 +0200 @@ -1007,6 +1007,27 @@ if (cRecordControls::Active()) { if (!Interface->Confirm(tr("Recording - shut down anyway?"))) break; + // Stop all running timers + time_t Now = time(NULL); + cTimer *timer = Timers.GetNextActiveTimer(); + time_t Next = timer ? timer->StartTime() : 0; + while (timer && Next - Now < 0) { + if (timer->IsSingleEvent()) + timer->ClrFlags(tfActive); + else + timer->Skip(); + timer->Matches(); + + cTimer *nextTimer = Timers.GetNextActiveTimer(); + time_t nextNext = nextTimer ? nextTimer->StartTime() : 0; + if (nextNext < Next || (nextNext == Next && nextTimer == timer)) { + esyslog("Loop detected while disabling running timers"); + break; + } + Next=nextNext; + timer=nextTimer; + } + Timers.SetModified(); } if (cPluginManager::Active(tr("shut down anyway?"))) break; @@ -1020,6 +1041,27 @@ free(buf); if (!confirm) break; + // Stop all pending timers until MinEventTimeout + time_t Now = time(NULL); + cTimer *timer = Timers.GetNextActiveTimer(); + time_t Next = timer ? timer->StartTime() : 0; + while (timer && Next - Now <= Setup.MinEventTimeout * 60) { + if (timer->IsSingleEvent()) + timer->ClrFlags(tfActive); + else + timer->Skip(); + timer->Matches(); + + cTimer *nextTimer = Timers.GetNextActiveTimer(); + time_t nextNext = nextTimer ? nextTimer->StartTime() : 0; + if (nextNext < Next || (nextNext == Next && nextTimer == timer)) { + esyslog("Loop detected while disabling pending timers"); + break; + } + Next=nextNext; + timer=nextTimer; + } + Timers.SetModified(); } ForceShutdown = true; break;
Udo Richter wrote:
Hi list,
Based on a first patch by Helmut Auer, here's a patch to solve the shutdown on running timers issue. I did some simple tests and it seemed to work, however the patch is still experimental.
The patch basically disables the offending timers up to MinEventPause minutes in the future. There's also some endless loop detection that imho should be impossible to trigger.
Some issues:
- If you decide to cancel the shutdown after confirming it first, timers
will remain disabled. Thats probably not what the user expects.
- Disabling pending timers up to MinEventPause may not what the user
expects either. I have set MinEventPause to 11 minutes (5 for shutdown, 5 for wakeup, 1 to avoid race conditions). But if an user has set this to 120 minutes for example, then the question "Recording in 100 minutes, shut down anyway?" doesn't sound like VDR wont wake up for it.
- A clean implementation should merge both loops into one function and
move the code into cTimers (API change!). (the two loops are required to skip negative values for "Recording in xx minutes")
Cheers,
Udo
--- vdr-1.4.1-orig/vdr.c 2006-07-25 15:48:14.000000000 +0200 +++ vdr-1.4.1/vdr.c 2006-07-25 16:39:38.943900248 +0200 @@ -1007,6 +1007,27 @@ if (cRecordControls::Active()) { if (!Interface->Confirm(tr("Recording - shut down anyway?"))) break;
// Stop all running timerstime_t Now = time(NULL);cTimer *timer = Timers.GetNextActiveTimer();time_t Next = timer ? timer->StartTime() : 0;while (timer && Next - Now < 0) {if (timer->IsSingleEvent())timer->ClrFlags(tfActive);elsetimer->Skip();timer->Matches();cTimer *nextTimer = Timers.GetNextActiveTimer();time_t nextNext = nextTimer ? nextTimer->StartTime() : 0;if (nextNext < Next || (nextNext == Next && nextTimer == timer)) {esyslog("Loop detected while disabling running timers");break;}Next=nextNext;timer=nextTimer;}Timers.SetModified(); } if (cPluginManager::Active(tr("shut down anyway?"))) break;@@ -1020,6 +1041,27 @@ free(buf); if (!confirm) break;
// Stop all pending timers until MinEventTimeouttime_t Now = time(NULL);cTimer *timer = Timers.GetNextActiveTimer();time_t Next = timer ? timer->StartTime() : 0;while (timer && Next - Now <= Setup.MinEventTimeout * 60) {if (timer->IsSingleEvent())timer->ClrFlags(tfActive);elsetimer->Skip();timer->Matches();cTimer *nextTimer = Timers.GetNextActiveTimer();time_t nextNext = nextTimer ? nextTimer->StartTime() : 0;if (nextNext < Next || (nextNext == Next && nextTimer == timer)) {esyslog("Loop detected while disabling pending timers");break;}Next=nextNext;timer=nextTimer;}Timers.SetModified(); } ForceShutdown = true; break;
This is getting *way* too complex for my taste.
How about this: if the user presses the "Power" key to turn off VDR, and VDR tells him/her that there is a recording going on, or a timer will hit in a few minutes, and the user still insists in shutting down VDR *now*, what could be the reason for this? IMHO the only real reason is that the user wants to do some maintenance, for which the device must be turned off (like, for instance, install some hardware or relocate it to a different place). At any rate, chances are the user will turn it on again anyway after the action that was so important that it was worth interrupting an ongoing recording is finished.
As a safety precaution, in case the user turned off VDR and ignored all the warnings, let's just tell the shutdown script to reboot it at, say, five minutes in the future (in case a recording is going on) or whenever the next timer hits after that time.
If the user doesn't want this to happen, then he/she can simply go into the Timers menu and turn timers off as desired. I don't think VDR should make that decision behind the user's back.
Klaus
Klaus Schmidinger wrote:
As a safety precaution, in case the user turned off VDR and ignored all the warnings, let's just tell the shutdown script to reboot it at, say, five minutes in the future (in case a recording is going on) or whenever the next timer hits after that time.
I'm not sure whether I like the idea that VDR starts again after 5 minutes, probably just in that moment when I am plugging a PCI card or something like that. (Yes, you're *supposed* to pull the plug first. You really do? ;) )
Anyway, 5 mins is too short, anything less that 10 mins will be denied by nvram-wakeup default configuration.
If the user doesn't want this to happen, then he/she can simply go into the Timers menu and turn timers off as desired.
I don't have a problem with disabling the offending timers manually. I just wrote the patch because of the request.
Its just a bit strange that VDR requires extra confirmation, and then nvram-wakeup denies shutdown anyway. (or other shoudown scrips doing even more strange things)
On a side note: With some scripting-fu, it should be possible to disable the offending timers from the shutdown script via SVDRP, and then request the new reboot time also via SVDRP.
Cheers,
Udo
Udo Richter wrote:
Klaus Schmidinger wrote:
As a safety precaution, in case the user turned off VDR and ignored all the warnings, let's just tell the shutdown script to reboot it at, say, five minutes in the future (in case a recording is going on) or whenever the next timer hits after that time.
I'm not sure whether I like the idea that VDR starts again after 5 minutes, probably just in that moment when I am plugging a PCI card or something like that. (Yes, you're *supposed* to pull the plug first. You really do? ;) )
Anyway, 5 mins is too short, anything less that 10 mins will be denied by nvram-wakeup default configuration.
Well, then let's use Setup.MinEventTimeout. After all, the user has confirmed that any onging recording as well as any timer starting withing Setup.MinEventTimeout doesn't matter.
If the user doesn't want this to happen, then he/she can simply go into the Timers menu and turn timers off as desired.
I don't have a problem with disabling the offending timers manually. I just wrote the patch because of the request.
Sure, and I'm not critizising that. It just showed to me that if we go down that road things will become ever more complex, and sure enough somebody will come up with yet another level of complexity.
Its just a bit strange that VDR requires extra confirmation, and then nvram-wakeup denies shutdown anyway. (or other shoudown scrips doing even more strange things)
On a side note: With some scripting-fu, it should be possible to disable the offending timers from the shutdown script via SVDRP, and then request the new reboot time also via SVDRP.
My suggestion would be: as soon as ForceShutdown is set and Delta is less than Setup.MinEventTimeout, let's just set Delta to Setup.MinEventTimeout (and adjust Next accordingly). The worst that can happen is that VDR restarts after half an hour (default for MinEventTimeout) and continues to do whatever it takes. If the user turns it on earlier, all programmed timers will still be there and even recordings that were interrupted will be continued.
Please try the attached patch.
Klaus
Klaus Schmidinger wrote:
Udo Richter wrote:
Klaus Schmidinger wrote:
As a safety precaution, in case the user turned off VDR and ignored all the warnings, let's just tell the shutdown script to reboot it at, say, five minutes in the future (in case a recording is going on) or whenever the next timer hits after that time.
I'm not sure whether I like the idea that VDR starts again after 5 minutes, probably just in that moment when I am plugging a PCI card or something like that. (Yes, you're *supposed* to pull the plug first. You really do? ;) )
Anyway, 5 mins is too short, anything less that 10 mins will be denied by nvram-wakeup default configuration.
Well, then let's use Setup.MinEventTimeout. After all, the user has confirmed that any onging recording as well as any timer starting withing Setup.MinEventTimeout doesn't matter.
If the user doesn't want this to happen, then he/she can simply go into the Timers menu and turn timers off as desired.
I don't have a problem with disabling the offending timers manually. I just wrote the patch because of the request.
Sure, and I'm not critizising that. It just showed to me that if we go down that road things will become ever more complex, and sure enough somebody will come up with yet another level of complexity.
Its just a bit strange that VDR requires extra confirmation, and then nvram-wakeup denies shutdown anyway. (or other shoudown scrips doing even more strange things)
On a side note: With some scripting-fu, it should be possible to disable the offending timers from the shutdown script via SVDRP, and then request the new reboot time also via SVDRP.
My suggestion would be: as soon as ForceShutdown is set and Delta is less than Setup.MinEventTimeout, let's just set Delta to Setup.MinEventTimeout (and adjust Next accordingly). The worst that can happen is that VDR restarts after half an hour (default for MinEventTimeout) and continues to do whatever it takes. If the user turns it on earlier, all programmed timers will still be there and even recordings that were interrupted will be continued.
Please try the attached patch.
I just realized that a Next and Delta of '0' has special meaning to the shutdown script, so here's another version of this patch, taking into account if there is a 'timer' at all.
Klaus
Klaus Schmidinger wrote:
Please try the attached patch.
Did some simple tests, seems ok so far.
One thing remains: After "Recording - shut down anyway?", we should not ask "Recording in x minutes, shut down anyway?", as the 'next' recording is always the currently running one, and x is a negative value. The real next recording is unknown in this situation.
Cheers,
Udo
On Sat, 29 Jul 2006, Udo Richter (UR) wrote:
UR> UR> Its just a bit strange that VDR requires extra confirmation, and then UR> nvram-wakeup denies shutdown anyway. (or other shoudown scrips doing even UR> more strange things)
as far as I remember, one of the parameters passed to the shutdown script indicates if the shutdown is requested by the user.
in this case you could just call nvram-wakeup -d and shutdown. keeping in mind, that the machine will not wakeup again at all.
Sergei
I am sorry I have to bring this up after a few months, i came over it and had to realize that the new behavior is not what the user expects.
Now i am a little bit afraid that you are going to change this again. (see vdr shutdown handling / streamdev plugin)
How about this: if the user presses the "Power" key to turn off VDR, and VDR tells him/her that there is a recording going on, or a timer will hit in a few minutes, and the user still insists in shutting down VDR *now*, what could be the reason for this? IMHO the only real reason is that the user wants to do some maintenance, for which the device must be turned off (like, for instance, install some hardware or relocate it to a different place).
This assumption is not correct. Not anyone ist going to do some maintenance if he shuts down his box. They are not all freaks like us ;) In fact i found out that there are two main reasons: 1. Saving power. Well, *we* know that shutting down for some minutes isn't really saving anything, but a user thinks "ok, its still 15 minutes to the next recording so its save to shut it down. And the vdr isn't telling him a warning that wakeuptime is shifted if he does so. So it's not intuitive. A timer is a "holy kow" - it should not be modified automatically. 2. Users always think "my box will (has to) return to the same state as it was before the recording". So they shut it down. They do not know that there is this (hidden) feature in the vdr that lets it shut down if he ignores the message and then keeps away his fingers from the remote (as it is no informational message but a question).
On the other hand, the user expects that a running recording is disabled and he says "yes" to the question to shut down anyway.
So here is my solution: - if a recording is running and User presses "Power" tell him the box will shutdown after the current recording - If he presses "Power" a second time, ask if he realy wants to do this (like before) *and* stop any running recordings (i reused the code from Udo which work very well, thanks)
- if a timer is pending within MinEventTimeout ask if he really wants to do so but do *not* modify any timers or wakeup times. I think it's the task of whoever adopts vdr to a mainboard or box to program a valid wakeup time, not the vdr itself.
Cheers, Tim
patch:
Thiemo wrote:
So here is my solution:
- if a recording is running and User presses "Power" tell him the box will
shutdown after the current recording
- If he presses "Power" a second time, ask if he realy wants to do this (like
before) *and* stop any running recordings (i reused the code from Udo which work very well, thanks)
I agree that the shutdown-not-confirmed state should be more visible to users by some message that VDR is just waiting for background tasks to complete before shutdown. A solution I thought of was to put up a message after not confirming shutdown that VDR will shut down as soon as whatever is done - maybe even keeping that message on screen all the time.
The idea of pressing power button twice is also nice, though it will confuse scripts that send power key presses. Plus, effectively, while you currently confirm shutdown with "power, ok", you now confirm with "power, power". And together with the other numerous reasons for not shutting down, this gets confusing: Use power button to override running timers, and use ok button to override timers in a few minutes?
- if a timer is pending within MinEventTimeout ask if he really wants to do so
but do *not* modify any timers or wakeup times.
So you *do* want running timers to be disabled, but *not* want to ignore timers in a few minutes?
I think it's the task of whoever adopts vdr to a mainboard or box to program a valid wakeup time, not the vdr itself.
Then we can also go back to what it was before, leave all timers alone and report wakeup in -30 minutes to the shutdown script. In the end it doesn't matter if any timers are running when VDR is killed.
Cheers,
Udo
On Sat, Dec 09, 2006 at 05:48:47PM +0100, Udo Richter wrote:
The idea of pressing power button twice is also nice, though it will confuse scripts that send power key presses. Plus, effectively, while you currently confirm shutdown with "power, ok", you now confirm with "power, power".
Furthermore, some cRemote implementations have incorrectly omitted the kRepeat flag from repeat events in the past. As far as I remember, the latest report of this on this list was not resolved. It was with some RF remote control unit, as far as I remember. To be exact, it was in the kernel input event driver in that case, but there have been bugs in user-space drivers as well.
Users of such RCUs could accidentally send "power, power" with a single press of the button.
And together with the other numerous reasons for not shutting down, this gets confusing: Use power button to override running timers, and use ok button to override timers in a few minutes?
I hope you will find some logical solution. And I'm sure someone will complain, no matter what you come up with. :-)
Marko
Am Samstag, 9. Dezember 2006 17:48 schrieb Udo Richter:
Thiemo wrote:
So here is my solution:
- if a recording is running and User presses "Power" tell him the box
will shutdown after the current recording
- If he presses "Power" a second time, ask if he realy wants to do this
(like before) *and* stop any running recordings (i reused the code from Udo which work very well, thanks)
I agree that the shutdown-not-confirmed state should be more visible to users by some message that VDR is just waiting for background tasks to complete before shutdown. A solution I thought of was to put up a message after not confirming shutdown that VDR will shut down as soon as whatever is done - maybe even keeping that message on screen all the time.
The idea of pressing power button twice is also nice, though it will confuse scripts that send power key presses.
No it won't. VDR still remembers the "shutdown-after-recording"-state with my changes. The only difference here is that the user is told whats going on.
A script never knows if it has to confirm the kPower or not (except if you would parse the timers to see if one is running). So if a script wants to shutdown vdr regardless of its state (i.e. for some maintenance ;) ) then sending kPower via svdrp isn't the right action at all. (one should use "killall -1 vdr" or similar and prevent vdr from starting up again).
Plus, effectively, while you currently confirm shutdown with "power, ok", you now confirm with "power, power". And together with the other numerous reasons for not shutting down, this gets confusing: Use power button to override running timers, and use ok button to override timers in a few minutes?
No, you still confirm with Ok, theres just one additional step before. I suggest you try it out - thats easier than describing it here.
- if a timer is pending within MinEventTimeout ask if he really wants to
do so but do *not* modify any timers or wakeup times.
So you *do* want running timers to be disabled, but *not* want to ignore timers in a few minutes?
exactly. If you would alter a timer (or the wakeuptime whats the same in the end) you would have to give a clear warning "Your timers will be shifted by xx minutes. Are you sure". But as i wrote in the previous post, it's not a good idea to alter a timer at all.
I think it's the task of whoever adopts vdr to a mainboard or box to program a valid wakeup time, not the vdr itself.
Then we can also go back to what it was before, leave all timers alone and report wakeup in -30 minutes to the shutdown script. In the end it doesn't matter if any timers are running when VDR is killed.
No, it's an improvement to what is was before. Users treat negative times as bugs. (And it *is* a bug to ask "recording in -x min" instead of "a recording is active")
Tim
Thiemo wrote:
Plus, effectively, while you currently confirm shutdown with "power, ok", you now confirm with "power, power". And together with the other numerous reasons for not shutting down, this gets confusing: Use power button to override running timers, and use ok button to override timers in a few minutes?
No, you still confirm with Ok, theres just one additional step before. I suggest you try it out - thats easier than describing it here.
Ok, I try to sum it up: If there's a good reason not to shut down, then hitting power once just switches to non-interactive mode. Hitting power twice in a short time starts the usual confirm marathon, and you'll need at least "power, power, ok" before anything happens.
Now what if nothing blocks shutdown? Going to non-interactive mode doesn't make sense, since VDR will start the 5-minute-shutdown then. So in that case VDR could power down on single power button. But is this intuitive? Hmmm.
So you *do* want running timers to be disabled, but *not* want to ignore timers in a few minutes?
exactly. If you would alter a timer (or the wakeuptime whats the same in the end) you would have to give a clear warning "Your timers will be shifted by xx minutes. Are you sure". But as i wrote in the previous post, it's not a good idea to alter a timer at all.
In my opinion, disabling a timer *is* altering. I tend to agree that timers shouldn't be altered, especially since the external shutdown script may just ignore the shutdown, in which case the timers should keep running. Also, I wouldn't bring down VDR with Interrupted=1, thats the job of the external script too.
But at the end, the shutdown script needs some advice when to start up again. It doesn't make sense to pass negative values, and it doesn't make sense to pass values in a few minutes, as shutdown and reboot takes more time. And SVDRP'ing for the next timer that is realistically rebootable in time is a too difficult task for an external script. So what now?
Cheers,
Udo
-
Klaus Schmidinger -
Marko Mäkelä -
Sergei Haller -
Thiemo -
Udo Richter -
vdr＠helmutauer.de