Am 10.01.2010 22:36, schrieb Udo Richter: > Am 22.12.2009 23:59, schrieb Steffen Barszus: > >> Ian Bates schrieb: >> >>> On 22 Dec 2009, at 21:36, Ian Bates wrote: >>> If a timer is currently recording, or a recording would start within the >>> next 30 minutes (default for the "Min. event timeout" setup >>> parameter), and >>> the user insists in shutting down now, the first and second parameter >>> will >>> correspond to a time that is "Min. event timeout" minutes in the future. >>> >>> Before the shutdown program is called, the user will be prompted to >>> inform >>> him that the system is about to shut down. If any remote control key is >>> pressed while this prompt is visible, the shutdown will be cancelled (and >>> tried again later). The shutdown prompt will be displayed for 5 >>> minutes, which >>> should be enough time for the user to react. >>> >>> >> So its really a "feature" - Whats the use case for this - except for the >> surprise ? Should a shutdown script try to "fix" that ? >> > There are several cases: > 1. Timer more than 30min in the future > - no problem with that. > agree > 2. Timer less than 30min in the future > - In that case, the critical question is whether VDR can complete a > whole shutdown within that time. Worst case may be that VDR will never > wake up on its own, because VDR is still shutting down at the wakeup time. > That is some special requirement then, which should be handled in shutdown script. Even worse from shutdown script you can not find out whats happening (real timer time or changed one) > 3. Timer is running > - What time should be the best time to wake up? The internal functions > of VDR currently cannot even determine the next timer, only the first > (running) timer. > This should deliver not running but next timer. - not sure how feasible that is. > Other concerns: If you force shutdown to do maintenance, you might be > surprised by a waking up VDR five minutes later. (You probably just > forgot to unplug power, right?) > We should not increase complexity to cover some not likely situations. > The current solution was a compromise that was realizable with not too > much effort. The 30mins were simply long enough and a better value than > never to wake up at all. > I would like less complexity and least surprise. I think this checking should be done in the shutdownscript. > >From today's point of view, I would probably prefer a solution that > wakes up at the next timer that is more than 30min in the future, > however this requires a better GetNextActiveTimer function. > I'll think again about it ... _______________________________________________ vdr mailing list vdr@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
