Hi list,
The program code for automatic and manual shut down and for automatic restarts for timer recordings is in VDR 1.4.x very complex and error-prone, and behaves strange in some situations. With Klaus' permission I am working on a re-implementation for the upcoming 1.5.x developer builds of VDR.
I now want to publish a first draft version for testing and further comments. Not all issues are fixed yet, but it already gives an impression of the new code.
http://www.udo-richter.de/vdr/patches.html#shutdown http://www.udo-richter.de/vdr/patches.en.html#shutdown
New: - Shutdown related code is now in shutdown.[ch]. vdr.c mainly delegates the work to the cShutdown class, that does all necessary steps for manual or automatic shutdown. - cShutdown tracks whether there is an interactive user or not. (eg. Min User Inactivity run out) - cRemote tracks time of last key press separately and autonomously. - The old 5-minute "Press any key to cancel..." message got replaced by a 5 minute countdown message that counts in 10-second steps - Since the new code is modularized, plugins will have access to activity tracking, can mess with inactivity state, and can initiate shutdown behavior similar to the kPower button. (But, please, only if you have to. ;) )
Fixed: - Pressing power button while recording playback works again, instead of doing nothing visible. (and not shutting down within 5 seconds at playback end.) - Show 5-minute shutdown message after background activity ends, if power button was pressed but not confirmed - Not freezing the VDR main loop while 5-minute shutdown message - Background activity now cancels the 5-minute shutdown message - Not messing with watchdog (and forgetting to re-enable) while 5-minute shutdown message - Timers set via SVDRP while in 5-minute shutdown message did not start and were not considered for reboot time. - Calling the main menu action of a plugin and closing a menu doesn't count as user activity any more
Todo: - Start the 5-minute countdown 5 minutes _before_ min user inactivity runs out. (also does not add 5min to SHUTDOWNRETRY any more) - Fix negative time in shutdown confirm if VPS timer is in run-out phase
Possible changes: - Make the 'inactive' mode (waiting for background activity to end, then shut down) more visible to the user: - Suggestion was to put up a message 'VDR will shut down when idle. Press power button again to force shutdown' before starting the confirms. - Alternative may be a message 'VDR will shut down later when idle' if shutdown was not confirmed - Alternative may be to permanently put up a message 'VDR is waiting for background tasks to complete'.
- What should happen if a user confirms to shut down while a running / pending timer is scheduled. Currently, VDR will reboot after MinEventTimeout, but VDR could also reboot at the next timer that starts after MinEventTimeout - or never.
- There is a feature request that the caller should be able to notify VDR whether VDR was started manually or automatically. (VDR currently guesses by searching for nearby timers)
- There is a feature request to start the external shutdown script asynchronously, so the shutdown script does not block VDR any more.
- A 'bug' in the old code allows to automatically shut down VDR at the end of a playback, though this was probably never intended. It could however be re-added as 'feature'.
There's some debug output code to monitor the various timers on console. If you don't want that, you can disable it in vdr.c, search for #define DebugTimeouts and comment it out.
Cheers,
Udo
Hi,
Udo Richter wrote:
I now want to publish a first draft version for testing and further comments. Not all issues are fixed yet, but it already gives an impression of the new code.
Further feature request: At least on single card systems it would be nice to have VDR wakeup e. g. at 03:01 to do just an EPG scan and shutdown afterwards.
Bye.
Reinhard Nissl wrote:
Further feature request: At least on single card systems it would be nice to have VDR wakeup e. g. at 03:01 to do just an EPG scan and shutdown afterwards.
This opens up the discussion about whether VDR should handle external tasks together with timers. I think that VDR should only handle its own tasks.
A timed start could trivially be done by setting a daily timer. More elegant, the shutdown script could check whether the wakeup time is past 3:01 and simply set a different wakeup time. With some reminder it could also realize that the machine did wake up because of the 3:01 tweak, and give special instructions - like starting EPG scan and shutting down (or going inactive) after 10 minutes.
Cheers,
Udo
Hi,
Udo Richter wrote:
Further feature request: At least on single card systems it would be nice to have VDR wakeup e. g. at 03:01 to do just an EPG scan and shutdown afterwards.
This opens up the discussion about whether VDR should handle external tasks together with timers. I think that VDR should only handle its own tasks.
I don't think that an EPG scan is an external task.
A timed start could trivially be done by setting a daily timer. More elegant, the shutdown script could check whether the wakeup time is past 3:01 and simply set a different wakeup time. With some reminder it could also realize that the machine did wake up because of the 3:01 tweak, and give special instructions - like starting EPG scan and shutting down (or going inactive) after 10 minutes.
That's why I posted this feature request. Why is it necessary to have such complex solutions twice -- inside VDR and outside VDR?
Ok for a start (and to test the new implementation), scheduling the automated EPG scan could be implemented by a plugin. When the new implementation asks the plugin concerning shutdown it will request 03:01 as next restart time.
This leads to the open question regarding manual start detection. As there is no timer, VDR will run in manual mode when it is started at 03:01 and the user inactivity timeout must first pass before VDR will start the EPG scan internally.
As you can see, an external solution is much more complex than adding a simple additional restart request for 03:01 -- shure, this time shouldn't be hard coded ;-)
Bye.
Reinhard Nissl wrote:
Ok for a start (and to test the new implementation), scheduling the automated EPG scan could be implemented by a plugin.
Plugins cannot modify the restart time currently, doing this as a plugin would require the complete shutdown mechanism to be re-implemented in the plugin. Doing it in runvdr and shutdown script would be easier.
However, it might be worth thinking about giving plugins the ability to set a different wakeup time, so that a scheduled EPG scan plugin can be written.
As you can see, an external solution is much more complex than adding a simple additional restart request for 03:01 -- shure, this time shouldn't be hard coded ;-)
Actually, whether this is internally or externally, the complexity stays the same. It would probably work mostly the same way: Tweak the wakeup time, detect this on wakeup, start the EPG scan, go offline.
Cheers,
Udo
Hi,
Udo Richter wrote:
Actually, whether this is internally or externally, the complexity stays the same. It would probably work mostly the same way: Tweak the wakeup time, detect this on wakeup, start the EPG scan, go offline.
perhaps this is too trivial, but why not create a daily or whatever timer as you suggested before with a special name like '@epgscan' and react on that? VDR would not create a recording for this timer but start an EPG scan and shut down, if no other timer is active. I think this is quite simple to implement. One could even extend this to a more generic approach: '@command1' as timer file could execute a command in line 1 of commands.conf, that is e.g. an external EPG update script.
BR,
Christian
Christian Wieninger wrote:
perhaps this is too trivial, but why not create a daily or whatever timer as you suggested before with a special name like '@epgscan' and react on that?
This would be a dirty ugly hack. There must be some pseudo-recording running so VDR does not restart the recording over and over again. And then we'll end up with a recording hack that looks like a timer but does not block devices and does not write to disk and has no recording folder and and and...
The alternative would be to implement a generic task scheduler and make timers one special type of schedule. This would get REALLY big.
Cheers,
Udo
2006/12/30, Udo Richter udo_richter@gmx.de:
However, it might be worth thinking about giving plugins the ability to set a different wakeup time, so that a scheduled EPG scan plugin can be written.
I also think that this would be very helpful for some plugins. Manual start detection could also include a call to the plugins. A plugin that did "schedule" an EPG-scan or similar could tell VDR during start up, that VDR woke up because of this scheduled event set by this plugin. At the moment I use a relatively complex patch that does some "maintainance" task during the night. If it would be possible to modify the wakeup-time in a plugin I could re-implement the complete patch as a plugin.
Regards, Joachim
On Sunday 31 December 2006 13:36, Joachim Wilke wrote:
2006/12/30, Udo Richter udo_richter@gmx.de:
However, it might be worth thinking about giving plugins the ability to set a different wakeup time, so that a scheduled EPG scan plugin can be written.
I also think that this would be very helpful for some plugins. Manual start detection could also include a call to the plugins. A plugin that did "schedule" an EPG-scan or similar could tell VDR during start up, that VDR woke up because of this scheduled event set by this plugin. At the moment I use a relatively complex patch that does some "maintainance" task during the night. If it would be possible to modify the wakeup-time in a plugin I could re-implement the complete patch as a plugin.
I think a much easier solution (implementable in runvdr/vdr-initscript) is: Write down wakeup-time when shutting down and comparing that to time when system/vdr starts (with some margin).
Matthias
2006/12/31, Matthias Schwarzott zzam@gentoo.org:
I think a much easier solution (implementable in runvdr/vdr-initscript) is: Write down wakeup-time when shutting down and comparing that to time when system/vdr starts (with some margin).
Thats right, this is even more robust. But I think this should be implemented in the vdr core not in scripts.
Regards, Joachim.
On Sunday 31 December 2006 14:15, Joachim Wilke wrote:
2006/12/31, Matthias Schwarzott zzam@gentoo.org:
I think a much easier solution (implementable in runvdr/vdr-initscript) is: Write down wakeup-time when shutting down and comparing that to time when system/vdr starts (with some margin).
Thats right, this is even more robust. But I think this should be implemented in the vdr core not in scripts.
How could vdr know what the system does otherwise. I think here the principle of KISS should be applied: keep it simple stupid.
Matthias
Matthias Schwarzott schrieb:
On Sunday 31 December 2006 13:36, Joachim Wilke wrote:
2006/12/30, Udo Richter udo_richter@gmx.de:
However, it might be worth thinking about giving plugins the ability to set a different wakeup time, so that a scheduled EPG scan plugin can be written.
I also think that this would be very helpful for some plugins. Manual start detection could also include a call to the plugins. A plugin that did "schedule" an EPG-scan or similar could tell VDR during start up, that VDR woke up because of this scheduled event set by this plugin. At the moment I use a relatively complex patch that does some "maintainance" task during the night. If it would be possible to modify the wakeup-time in a plugin I could re-implement the complete patch as a plugin.
I think a much easier solution (implementable in runvdr/vdr-initscript) is: Write down wakeup-time when shutting down and comparing that to time when system/vdr starts (with some margin).
That's exactly what my Gen2VDR distribution is doing, and it works fine. It's not the job of vdr to guess why it was started, but it would be nice if vdr offers an option to shutdown after next recording ( maybe via svdrp call ).
On Sunday 31 December 2006 15:02, Helmut Auer wrote:
Matthias Schwarzott schrieb:
On Sunday 31 December 2006 13:36, Joachim Wilke wrote:
2006/12/30, Udo Richter udo_richter@gmx.de:
However, it might be worth thinking about giving plugins the ability to set a different wakeup time, so that a scheduled EPG scan plugin can be written.
I also think that this would be very helpful for some plugins. Manual start detection could also include a call to the plugins. A plugin that did "schedule" an EPG-scan or similar could tell VDR during start up, that VDR woke up because of this scheduled event set by this plugin. At the moment I use a relatively complex patch that does some "maintainance" task during the night. If it would be possible to modify the wakeup-time in a plugin I could re-implement the complete patch as a plugin.
I think a much easier solution (implementable in runvdr/vdr-initscript) is: Write down wakeup-time when shutting down and comparing that to time when system/vdr starts (with some margin).
That's exactly what my Gen2VDR distribution is doing, and it works fine. It's not the job of vdr to guess why it was started, but it would be nice if vdr offers an option to shutdown after next recording ( maybe via svdrp call ).
In gentoo vdr package we added a small hack (attached), which implements a svdrp call "down" to tell vdr it is inactive and will shutdown in X minutes.
We call this from shutdown-scripts to let vdr retry shutdown in 5 min (or other value if needed).
Matthias
Matthias Schwarzott wrote:
In gentoo vdr package we added a small hack (attached), which implements a svdrp call "down" to tell vdr it is inactive and will shutdown in X minutes.
We call this from shutdown-scripts to let vdr retry shutdown in 5 min (or other value if needed).
Question is: Is this still needed?
VDR already retries after an acceptable time, and VDR probably knows better whether an user is currently active or not. The only reason I could think of is that VDR was started without a timer nearby, and the start script knows that this is not an user start. And sending a kPower key press will also let VDR go inactive.
Things were different in old versions, where VDR retried shutdown after 3 hours or so, but that has changed.
Cheers,
Udo
Udo Richter wrote:
Matthias Schwarzott wrote:
In gentoo vdr package we added a small hack (attached), which implements a svdrp call "down" to tell vdr it is inactive and will shutdown in X minutes.
We call this from shutdown-scripts to let vdr retry shutdown in 5 min (or other value if needed).
Question is: Is this still needed?
VDR already retries after an acceptable time, and VDR probably knows better whether an user is currently active or not. The only reason I could think of is that VDR was started without a timer nearby, and the start script knows that this is not an user start. And sending a kPower key press will also let VDR go inactive.
Things were different in old versions, where VDR retried shutdown after 3 hours or so, but that has changed.
I assume that with the ability to force a reload by sending SIGHUP to the vdr process (which will be included in the upcoming version 1.5.1) this should not be necessary any more.
Klaus
Matthias Schwarzott wrote:
I think a much easier solution (implementable in runvdr/vdr-initscript) is: Write down wakeup-time when shutting down and comparing that to time when system/vdr starts (with some margin).
That would be the way I would do it. Reconstructing the reason for shutdown after the restart is ok for just timers, but with different reasons this is way too complex and error-prone.
Cheers,
Udo
Hi list,
I've finished a second version of the shutdown rewrite. This time, there are two patches available, one for VDR 1.5.0, and one with slight changes for 1.4.x.
http://www.udo-richter.de/vdr/patches.html#shutdown http://www.udo-richter.de/vdr/patches.en.html#shutdown
- Fixed negative time in shutdown confirm in case a VPS timer is in run-out phase. Will now be shown as 'running' recording.
- If power pressed while background activity: "VDR will shut down later. Press power to force."
- Countdown timer will now start 5 minutes *before* Min User Inactivity is reached, unless there's background activity. In any case the countdown will run for 5 minutes. SHUTDOWNRETRY is now 6 minutes, so the next shutdown countdown will start 1 minute after the last one did run out.
- Playback of recordings now counts as background activity and requires confirmation on shutdown. If not confirmed, VDR will shut down at the end of playback. (sleeptimer!)
- Plugins can schedule to wake up VDR from shutdown by returning a time_t from cPlugin::NextWakeupEvent(). Any time that is not in the future will be ignored. To keep VDR awake, the plugin should also reply on Active() at the given time. If needed, I can provide a simple example code that wakes VDR every day at a given time for 5 minutes or similar.
- The scheduled wakeup time of the last call to the shutdown script is now remembered in setup.conf. If VDR wakes up within 10 minutes of this time, VDR assumes that this was an automatic start.
- Introduced separated shutdown retry counter that ensures the SHUTDOWNRETRY wait time. That way VDR will stay in non-interactive mode after an shutdown attempt.
- The shutdown script may now be called with a wakeup time but with 0 channel and no file, in case a plugin requested the wakeup.
- The shutdown command is now called in the background in a separate session, so it can run separately from VDR and can continue to run after the VDR process got killed.
- Dropped cRemote::TouchLastActivity() from 1.5 version of the patch, as it is not needed any more.
Todo / Possible changes:
- Maybe make backgrounding of shutdown script selectable like this: -s "/my/shutdown/script &" - this could also be adapted for recording commands and command menu commands
- What to do with SVDRP NEXT command? This was once the same as the time passed to the shutdown script, but it sill can be less than min event pause, even negative, and does not honor plugin scheduled restarts.
- Move SystemExecSession into tools.c and/or merge it with the existing SystemExec.
- Adapt newplugin and PLUGINS.html
- Add i18n entries
Cheers,
Udo
On Wed, Jan 10, 2007 at 02:28:24PM +0100, Udo Richter wrote:
Hi list,
I've finished a second version of the shutdown rewrite. This time, there are two patches available, one for VDR 1.5.0, and one with slight changes for 1.4.x.
http://www.udo-richter.de/vdr/patches.html#shutdown http://www.udo-richter.de/vdr/patches.en.html#shutdown
I had a short look at this patch: http://www.udo-richter.de/vdr/files/vdr-1.4.5-shutdown-rewrite-0.2.diff
A minor cosmetic thing: the '#' of pre-processor directives should always be located at the first column of the line. You can add spaces after the '#' if you want to indent the directives. This is probably not a problem, if VDR is only compiled with GCC. At least the compiler on SGI IRIX (r.i.p.) would choke on such code.
A more important suggestion: Could you please add a notification method to status.h for notifying plugins whether VDR is currently in interactive mode? This would be useful for at least these three plugins: softdevice, subtitles, and relay (my own plugin for controlling a solid-state relay that powers the display on or off). Here are the relevant chunks from my suspend patch http://www.iki.fi/~msmakela/software/vdr/#suspend, which is to my knowledge included in some VDR distributions:
diff -pu vdr-1.4.0/status.h vdr-1.4.0-suspend/status.h --- vdr-1.4.0/status.h 2005-12-31 17:15:25.000000000 +0200 +++ vdr-1.4.0-suspend/status.h 2006-05-01 21:42:34.000000000 +0300 @@ -44,6 +44,9 @@ protected: virtual void SetAudioChannel(int AudioChannel) {} // The audio channel has been set to the given value. // 0=stereo, 1=left, 2=right, -1=no information // available. + virtual void SetSuspend(bool Suspend) {} + // Suspend or resume audio/video playback. + // true=suspend, false=resume. virtual void OsdClear(void) {} // The OSD has been cleared. virtual void OsdTitle(const char *Title) {} @@ -77,6 +80,7 @@ public: static void MsgSetVolume(int Volume, bool Absolute); static void MsgSetAudioTrack(int Index, const char * const *Tracks); static void MsgSetAudioChannel(int AudioChannel); + static void MsgSetSuspend(bool Suspend); static void MsgOsdClear(void); static void MsgOsdTitle(const char *Title); static void MsgOsdStatusMessage(const char *Message);
I'd suggest a method SetInteractive(bool Interactive). When VDR is in non-interactive mode, the display would be powered off and the software decoding of video would be suspended. For full-featured cards, the suspendoutput plugin could perhaps be adapted: http://users.tkk.fi/~phintuka/vdr/vdr-suspendoutput/
If you implemented the method, it would make my vdr-suspend patch unnecessary. I could then try your patch and adapt the three plugins I use (relay, softdevice, and subtitles, in that order).
Marko
Marko Mäkelä wrote:
A minor cosmetic thing: the '#' of pre-processor directives should always be located at the first column of the line.
The only indented directives are for the debug output I think, and this will probably be removed before the final integration anyway.
A more important suggestion: Could you please add a notification method to status.h for notifying plugins whether VDR is currently in interactive mode?
You can poll this state on your own by calling Shutdown.IsUserInactive(). There is currently no internal notification anyway, VDR itself does poll it and would need to poll it to call MsgSetSuspend. The function itself is a light-weighted inline function, so its no problem to poll it once a second from cPlugin::MainThreadHook or similar.
Cheers,
Udo
On Sat, Jan 13, 2007 at 09:48:47PM +0100, Udo Richter wrote:
A more important suggestion: Could you please add a notification method to status.h for notifying plugins whether VDR is currently in interactive mode?
You can poll this state on your own by calling Shutdown.IsUserInactive(). There is currently no internal notification anyway, VDR itself does poll it and would need to poll it to call MsgSetSuspend.
Can you please explain to me why this could not be based on events?
While VDR is running, I would guess that the only way it can become interactive is by receiving button events from the remote control unit. You could have the RCU dispatcher thread (or any other place that changes the flag) call MsgSetInteractive(). If this is not possible, then you could declare a condition variable. The main loop of the main thread would check it with pthread_cond_timedwait() and call MsgSetInteractive() when the status changes.
The function itself is a light-weighted inline function, so its no problem to poll it once a second from cPlugin::MainThreadHook or similar.
Users would certainly prefer not to wait for a random time (0..1 seconds) for VDR to become active.
In softdevice, this delay could be bypassed when softdevice is in charge of the remote control unit. But softdevice (or DirectFB) doesn't support all types of remote control units.
Marko
Marko Mäkelä wrote:
While VDR is running, I would guess that the only way it can become interactive is by receiving button events from the remote control unit.
Hmm, ok, I was mainly thinking of becoming inactive - since this is after a certain time has passed, it can only be polled. For lots of cases the current patch wont poll this state at all for a long time.
But becoming active again is a different thing of course.
Users would certainly prefer not to wait for a random time (0..1 seconds) for VDR to become active.
Actually, the key press lets the VDR main loop spin, and directly after the key press was handled, there's a call to MainThreadHook, so its not that long.
Anyway, I'll think about that.
Cheers,
Udo
On Tue, Jan 16, 2007 at 12:15:32AM +0100, Udo Richter wrote:
Marko Mäkelä wrote:
While VDR is running, I would guess that the only way it can become interactive is by receiving button events from the remote control unit.
Hmm, ok, I was mainly thinking of becoming inactive - since this is after a certain time has passed, it can only be polled. For lots of cases the current patch wont poll this state at all for a long time.
Right, becoming inactive is not that time-critical. I will give your suggestion a try: in the MainThreadHook of each plugin, poll Shutdown.IsUserInactive().
Actually, the key press lets the VDR main loop spin, and directly after the key press was handled, there's a call to MainThreadHook, so its not that long.
Okay, this sounds reasonable. It is also good that every plugin will notice the change of Shutdown.IsUserInactive() virtually at the same time.
One more thing: are the timeouts for interactive->inactive->shutdown configureable? Is there a way to force VDR to enter inactive mode without immediate shutdown?
Marko
Marko Mäkelä wrote:
Right, becoming inactive is not that time-critical. I will give your suggestion a try: in the MainThreadHook of each plugin, poll Shutdown.IsUserInactive().
It should work, though the first key press may trigger some longer work, and the MainThreadHook will be called at the end. For softdevice and skins it may be interesting to watch for skin / osd activity while inactive.
One more thing: are the timeouts for interactive->inactive->shutdown configureable? Is there a way to force VDR to enter inactive mode without immediate shutdown?
Inactive mode is triggered by the Min User Inactivity timeout config option, by default 3 hours. 3 hours after the last key press VDR changes to inactive.
At most 5 minutes before this timeout, but only if there's no background activity, the countdown timer starts. If the countdown runs to 0 and there is no further activity, VDR will initiate the shutdown. After that the 6 minutes retry counter starts, to retry the shutdown. (there's no way how the shutdown script can report failure.) These timeouts are hard-coded as constants in vdr.c.
To force inactive mode, one can call Shutdown.SetUserInactive(); - the power key does it for example. This will lead to a shutdown as soon as there's no more activity - if you want to be inactive, but avoid shutdown, you can announce your activity by cPlugin::Active().
Cheers,
Udo
Udo Richter wrote:
Marko Mäkelä wrote:
One more thing: are the timeouts for interactive->inactive->shutdown configureable? Is there a way to force VDR to enter inactive mode without immediate shutdown?
Inactive mode is triggered by the Min User Inactivity timeout config option, by default 3 hours. 3 hours after the last key press VDR changes to inactive.
How about a new two level inactivity timeout ? After VDR starts the inactivity timeout uses a first short timeout (e.g. 5min) assuming that VDR has automaticly being started. Only after seeing any real user activity the normal Inactivity timeout (e.g. 2..3h) is used. Of course this can be combined with override functions on VDR startup (e.g. force plugin or timer start) as already suggested.
Last but not least I would personally wish for an new anti-timeout-plugin that would block VDR from shutting down on request. I sometimes watching TV in the workshop via RF modulated TV from my master VDR. Sometimes you miss the shutdown countdown and are surprised that the TV turns to noise only, sometimes it's just anoying to go up to switch the countdouwn off ;-))
However the last one now look like it's just a very simple plugin.
kind regards Peter
Peter Dittmann wrote:
How about a new two level inactivity timeout ? After VDR starts the inactivity timeout uses a first short timeout (e.g. 5min) assuming that VDR has automaticly being started.
Actually, even in worst case you'll see the 5-minute-countdown, so you already have enough time to become interactive.
Last but not least I would personally wish for an new anti-timeout-plugin that would block VDR from shutting down on request.
You could just set the Min User Inactivity to 0, and VDR will not shut down automatically. (unless you hit the power key - this will even work delayed, eg. after a recording ends.)
However the last one now look like it's just a very simple plugin.
It is. Just type ./newplugin Noshutdown, then edit Noshutdown.c so that cPluginNoshutdown::Active() always returns a string. Done.
Cheers,
Udo
On Sat, Jan 13, 2007 at 09:48:47PM +0100, Udo Richter wrote:
A more important suggestion: Could you please add a notification method to status.h for notifying plugins whether VDR is currently in interactive mode?
You can poll this state on your own by calling Shutdown.IsUserInactive().
Thanks, this seems to work: the display is powered off after the "press any button to cancel shutdown" timeout. However, after a failed shutdown attempt (renaming the shutdown script so that it won't be found), vdr does something to the file descriptor that my plugin opens, and the relay control will fail.
This might have something to do with the fact that it is file descriptor 0. There is no stdin, because my runvdr script closes it:
exec <&- >> /tmp/vdr.log 2>&1
The problem seems to lie in shutdown.c, in SystemExecSession(). It won't close file descriptor 0, but it will close anything above STDERR_FILENO (which is normally 2). This function appears to show up in strace output as "clone()". Adding close(0) to the function fixes the problem. Do you see any reason why the shutdown script would need to access stdin? (I can see reasons why it would want to access stdout or stderr.)
I made a simple patch to softdevice (attached) that seems to work. A similar patch would be needed for the subtitles plugin, to prevent subtitles from appearing on the suspended video screen.
Marko
Marko Mäkelä wrote:
The problem seems to lie in shutdown.c, in SystemExecSession(). It won't close file descriptor 0, but it will close anything above STDERR_FILENO (which is normally 2). This function appears to show up in strace output as "clone()". Adding close(0) to the function fixes the problem. Do you see any reason why the shutdown script would need to access stdin? (I can see reasons why it would want to access stdout or stderr.)
Actually, the SystemExecSession() is just a modified version of SystemExec() in thread.c, that was used before to call the shutdown script. They only differ in the fact that VDR continues instead of waiting for the child process, and that the child process is detached into its own session. There's no serious difference regarding the file handles. Since the shutdown script runs in the background, the stdin could probably be closed. After all, VDR should continue to 'own' stdin, and running in the background would probably cause a conflict. However, running the script with a closed file handle may cause other side effects.
Cheers,
Udo
On Tue, Jan 23, 2007 at 10:19:57PM +0100, Udo Richter wrote:
Since the shutdown script runs in the background, the stdin could probably be closed. After all, VDR should continue to 'own' stdin, and running in the background would probably cause a conflict. However, running the script with a closed file handle may cause other side effects.
I can't think of any side effect. The shutdown script is not supposed to be interactive, and system tools generally do not read stdin.
There are two reasons why my runvdr script closes stdin and redirects stdout and stderr to a file. First, scrolling console output on the bitmap framebuffer could interfere with softdevice-dfb or slow down the playback. Second, I may occasionally launch the runvdr script via an ssh session, and the ssh session would refuse to close if stdin, stdout, or stderr are being used after exiting the shell.
I guess I could work around this bug by leaving file descriptor 0 open before starting vdr, e.g., by replacing the <&- with </dev/null in my runvdr script. But I would very much appreciate it if you could add close(STDIN_FILENO) after the fork() call.
Are you planning to maintain the 1.4 branch of the patch? If yes (and I hope so), can plugins use some #ifdef to see if Shutdown.IsUserInactive() is available?
Marko
Marko Mäkelä wrote:
On Tue, Jan 23, 2007 at 10:19:57PM +0100, Udo Richter wrote:
Since the shutdown script runs in the background, the stdin could probably be closed. After all, VDR should continue to 'own' stdin, and running in the background would probably cause a conflict. However, running the script with a closed file handle may cause other side effects.
I can't think of any side effect. The shutdown script is not supposed to be interactive, and system tools generally do not read stdin.
Well, strange things happen. I've had such a side effect on my runvdr extreme with a closed stdout, see here: (German) http://www.vdr-portal.de/board/thread.php?postid=542948#post542948
In this case, printf on kanotix complained heavily on a closed stdout, and the only workaround was to replace >&- with the traditional >/dev/null.
Are you planning to maintain the 1.4 branch of the patch? If yes (and I hope so), can plugins use some #ifdef to see if Shutdown.IsUserInactive() is available?
For now I'll maintain it, currently the differences are only minor. Adding some #ifdef detection is a good idea, I'll add that for the next 1.4 patch.
Cheers,
Udo
On Wed, Jan 24, 2007 at 06:49:10PM +0100, Udo Richter wrote:
Well, strange things happen. I've had such a side effect on my runvdr extreme with a closed stdout, see here: (German) http://www.vdr-portal.de/board/thread.php?postid=542948#post542948
In this case, printf on kanotix complained heavily on a closed stdout, and the only workaround was to replace >&- with the traditional >/dev/null.
Closing stdout is a different matter. But I agree with you, it may be not a wise idea to close stdin either. The workaround </dev/null did not occur to me until today. And even without the workaround, it's not that bad, because usually the shutdown does succeed.
Are you planning to maintain the 1.4 branch of the patch? If yes (and I hope so), can plugins use some #ifdef to see if Shutdown.IsUserInactive() is available?
For now I'll maintain it, currently the differences are only minor. Adding some #ifdef detection is a good idea, I'll add that for the next 1.4 patch.
Thank you! I plan to keep using 1.4 at least until 1.5 supports DVB subtitles (which I hope it will support at some point) or UTF-8.
Marko
On Sat, Jan 13, 2007 at 09:48:47PM +0100, Udo Richter wrote:
Marko Mäkelä wrote:
A minor cosmetic thing: the '#' of pre-processor directives should always be located at the first column of the line.
The only indented directives are for the debug output I think, and this will probably be removed before the final integration anyway.
A more important suggestion: Could you please add a notification method to status.h for notifying plugins whether VDR is currently in interactive mode?
You can poll this state on your own by calling Shutdown.IsUserInactive().
I attach my patches to the subtitles and softdevice plugins. I intentionally kept them simple: I'm using the existing configuration flags for disabling output. It would be better to introduce a separate variable for the configuration setting, and in MainThreadHook assign the enable flag to either FALSE or the configured setting. In that way, the output could be permanently disabled from the plugin menus, as it can be done now.
I'll post improved patches when the presence of the shutdown patch can be tested with #ifdef.
Marko
Hi list,
I've finished a third version of the shutdown rewrite. Again there are two patches available, one for VDR 1.5.0, and one with slight changes for 1.4.x.
http://www.udo-richter.de/vdr/patches.html#shutdown http://www.udo-richter.de/vdr/patches.en.html#shutdown
- Shutdown command called with /dev/null as stdin
- Shutdown script now called with plugin name as 4th parameter if the wakeup time is set by a plugin. Summarized: No restart: shutdown.sh 0 0 0 "" Force Timer restart: shutdown.sh Time Delta Channel "Timer-Name" Force Plugin restart: shutdown.sh Time Delta 0 "Plugin-Name" Force
- Changed cPluginManager::NextWakeupEvent into cPluginManager::GetNextWakeupEventPlugin to return the plugin that schedules the next event, instead of just the time_t.
- Merged SystemExecSession into SystemExec of thread.c
- Added #define PATCH_SHUTDOWN_REWRITE to detect the patch Use #if VDRVERSNUM >= 105xx || defined(PATCH_SHUTDOWN_REWRITE) after final integration into VDR.
- Adapted newplugin script.
- Adapted PLUGINS.html.
- Adapted INSTALL for new shutdown behavior.
Todo:
- i18n strings: "VDR will shut down later. Press power to force." "VDR will shut down in %s minutes" "Replaying - shut down anyway?" "Cutting - shut down anyway?" "Plugin activity in %ld minutes, shut down anyway?"
Cheers,
Udo
Udo Richter wrote:
Hi list,
I've finished a third version of the shutdown rewrite. Again there are two patches available, one for VDR 1.5.0, and one with slight changes for 1.4.x. ...
I would suggest to rename NextWakeupEvent() to WakeupTime(), because there isn't really an "event" involved, and the word "event is generally used in a different context (for EPG events). Plus, the individual plugin only has a single wake-up time, so there's no need for "Next".
Accordingly GetNextWakeupEventPlugin() should be renamed to GetNextWakeupPlugin(). Here the "Next" makes sense, because the function returns the plugin with the earliest wake-up time. The "Time" part could be dropped because the function returns a cPlugin* and there is no time involved.
Klaus
Klaus Schmidinger wrote:
I would suggest to rename NextWakeupEvent() to WakeupTime(), because there isn't really an "event" involved, and the word "event is generally used in a different context (for EPG events). Plus, the individual plugin only has a single wake-up time, so there's no need for "Next".
Accordingly GetNextWakeupEventPlugin() should be renamed to GetNextWakeupPlugin(). Here the "Next" makes sense, because the function returns the plugin with the earliest wake-up time. The "Time" part could be dropped because the function returns a cPlugin* and there is no time involved.
I agree, s/event/time/g makes things a lot more consistent. I didn't like GetNextWakeupEventPlugin either.
I also renamed the setup parameter NextWakeupEvent to NextWakeupTime, and renamed some local variables accordingly. I can provide a patch if needed.
Cheers,
Udo
Udo Richter wrote:
Klaus Schmidinger wrote:
I would suggest to rename NextWakeupEvent() to WakeupTime(), because there isn't really an "event" involved, and the word "event is generally used in a different context (for EPG events). Plus, the individual plugin only has a single wake-up time, so there's no need for "Next".
Accordingly GetNextWakeupEventPlugin() should be renamed to GetNextWakeupPlugin(). Here the "Next" makes sense, because the function returns the plugin with the earliest wake-up time. The "Time" part could be dropped because the function returns a cPlugin* and there is no time involved.
I agree, s/event/time/g makes things a lot more consistent. I didn't like GetNextWakeupEventPlugin either.
I also renamed the setup parameter NextWakeupEvent to NextWakeupTime, and renamed some local variables accordingly. I can provide a patch if needed.
I'll wait for the final result for version 1.5, once everybody has agreed on it ;-)
Klaus
On Sun, Jan 28, 2007 at 05:50:46PM +0100, Udo Richter wrote:
Hi list,
I've finished a third version of the shutdown rewrite. Again there are two patches available, one for VDR 1.5.0, and one with slight changes for 1.4.x.
http://www.udo-richter.de/vdr/patches.html#shutdown http://www.udo-richter.de/vdr/patches.en.html#shutdown
- Shutdown command called with /dev/null as stdin
Thank you, this fixes the bug that I reported.
- Added #define PATCH_SHUTDOWN_REWRITE to detect the patch Use #if VDRVERSNUM >= 105xx || defined(PATCH_SHUTDOWN_REWRITE) after final integration into VDR.
Thank you. I adapted my patches to the subtitles and softdevice plugins and made them available at http://www.iki.fi/~msmakela/software/vdr/#shutdown.
I have two more feature requests.
First, and more important: Can you please suspend the playback of recordings when Shutdown.IsUserInactive() holds? Here is the relevant hunk from my vdr-suspend patch:
diff -pu vdr-1.4.0/dvbplayer.c vdr-1.4.0-suspend/dvbplayer.c --- vdr-1.4.0/dvbplayer.c 2006-04-17 15:45:48.000000000 +0300 +++ vdr-1.4.0-suspend/dvbplayer.c 2006-05-01 21:42:34.000000000 +0300 @@ -393,7 +393,7 @@ void cDvbPlayer::Action(void)
// Read the next frame from the file:
- if (playMode != pmStill && playMode != pmPause) { + if (!Setup.Suspend && playMode != pmStill && playMode != pmPause) { if (!readFrame && (replayFile || readIndex >= 0)) { if (!nonBlockingFileReader->Reading()) { if (playMode == pmFast || (playMode == pmSlow && playDir == pdBackward)) {
Without this fix and with my patched softdevice plugin, if Shutdown.IsUserInactive() starts to hold while playing back a recording, VDR will fast-forward to the end of the recording (supplying data to softdevice as fast as it can read from the file system). This problem exists also with the suspend function of the softdevice plugin. Alternatively, could you suggest how to fix this in softdevice?
Second request: Consider modifying cDevice::Action() so that non-recording tuners will not be read during user inactivity. The kernel would then be able to turn off unnecessary tuners. Actually, it'd be nice to turn off any unneeded tuners, also during interactive use (multi-tuner setups, or watching recordings).
During the time when playback is suspended, cDevice::Action() will read live stream from the tuner and supply it only to cRecording threads. It would be better to turn off the tuner completely if no recordings are in progress.
- i18n strings:
Here are my suggested Finnish translations, and some comments and questions.
"VDR will shut down later. Press power to force."
"VDR sammuu myöhemmin. Pakota painamalla virtanappia."
"VDR will shut down in %s minutes"
"VDR sammuu %s minuutin kuluttua."
Why %s instead of a numeric format such as %ld?
"Replaying - shut down anyway?"
"Sammutetaanko kesken toiston?"
For some reason, vdr won't ask this every time when playing back a recording.
"Cutting - shut down anyway?"
"Sammutetaanko kesken leikkauksen?"
If this is not confirmed, will it shut down after finishing the cutting, like it worked before your patch?
"Plugin activity in %ld minutes, shut down anyway?"
"Liitännäinen toimii %ld minuutin päästä, sammutetaanko?"
Better: "Plugin %s activity" ("liitännäinen %s") where %s is the name of the first plugin to run.
Best regards,
Marko
On Tuesday 30 January 2007 19:28, Marko Mäkelä wrote:
On Sun, Jan 28, 2007 at 05:50:46PM +0100, Udo Richter wrote:
"Plugin activity in %ld minutes, shut down anyway?"
"Liitännäinen toimii %ld minuutin päästä, sammutetaanko?"
IIRC "plugin" has been translated to "laajennos" elsewhere in VDR - no matter if it's laajennos or liitännäinen, consistency would be good. And "toimii" sounds a bit weird to me in this context, but I don't have better suggestions right now.
On Tue, Jan 30, 2007 at 08:08:27PM +0200, Ville Skyttä wrote:
On Tuesday 30 January 2007 19:28, Marko Mäkelä wrote:
On Sun, Jan 28, 2007 at 05:50:46PM +0100, Udo Richter wrote:
"Plugin activity in %ld minutes, shut down anyway?"
"Liitännäinen toimii %ld minuutin päästä, sammutetaanko?"
IIRC "plugin" has been translated to "laajennos" elsewhere in VDR - no matter if it's laajennos or liitännäinen, consistency would be good. And "toimii" sounds a bit weird to me in this context, but I don't have better suggestions right now.
Point taken. I'm not entirely satisfied with that translation either, although I gave most thought to this translation. It's hard to come up with a clear and concise translations of this. Although "toimii" may sound weird, it is the verb that corresponds to the noun "toiminta", the direct translation of "activity".
Marko
On Tue, 30 Jan 2007, Marko Mäkelä wrote:
Here are my suggested Finnish translations, and some comments and questions.
I'd use passive sentencies and no comma at the ends and try to use the current style.
"VDR will shut down later. Press power to force."
"VDR sammuu myöhemmin. Pakota painamalla virtanappia."
"VDR sammutetaan myöhemmin - pakota virtakytkimellä"
"VDR will shut down in %s minutes"
"VDR sammuu %s minuutin kuluttua."
"VDR sammutetaan %ld minuutin kuluttua"
"Replaying - shut down anyway?"
"Sammutetaanko kesken toiston?"
"Toisto kesken - sammutetaanko?"
This should be similar to current: "Recording - restart anyway?"
"Cutting - shut down anyway?"
"Sammutetaanko kesken leikkauksen?"
"Leikkaus kesken - sammutetaanko?"
"Plugin activity in %ld minutes, shut down anyway?"
"Liitännäinen toimii %ld minuutin päästä, sammutetaanko?" Better: "Plugin %s activity" ("liitännäinen %s") where %s is the name of the first plugin to run.
"Laajennos aktivoituu %ld kuluttua - sammutetaanko?"
BR, -- rofa
On Tue, Jan 30, 2007 at 09:56:36PM +0200, Rolf Ahrenberg wrote:
I'd use passive sentencies and no comma at the ends and try to use the current style.
I agree with you that it is good to maintain a consistent style.
However, "The passive voice should be avoided." I quickly browsed some tooltips in GNOME, and I didn't see the passive form anywhere.
"Plugin activity in %ld minutes, shut down anyway?"
"Liitännäinen toimii %ld minuutin päästä, sammutetaanko?" Better: "Plugin %s activity" ("liitännäinen %s") where %s is the name of the first plugin to run.
"Laajennos aktivoituu %ld kuluttua - sammutetaanko?"
I would rather write "käynnistyy" instead of the foreign "aktivoituu".
But this is not in passive form, is it? To be consistent with your suggestion "VDR sammutetaan" ("VDR will be shut down"), it should be "Laajennos aktivoidaan" or "Laajennos käynnistetään" ("Plugin will be activated"). That sounds unnecessarily complicated to me, as does "VDR sammutetaan". The passive form is used when the subject is not known. We know that it is VDR that shuts down itself or activates a plugin. The active form is also shorter than the passive form.
Marko
On Tue, 30 Jan 2007, Marko Mäkelä wrote:
I was in a bit hurry when writing those translations, so don't take them as written into stone - they do need some polishing.
I agree with you that it is good to maintain a consistent style. However, "The passive voice should be avoided." I quickly browsed some tooltips in GNOME, and I didn't see the passive form anywhere.
Sure, and my Finnish teacher told that one many times too. However, I'm more familiar with it when the object is non-living.
I would rather write "käynnistyy" instead of the foreign "aktivoituu".
But VDR starts ("käynnistää") all plugins already at the beginning and depending on the plugins behaviour it's activated on main menu action, external trigger, ... So, using the "käynnistää" as activate confuses me a bit and I'd avoid using it here, but I can live with it.
But this is not in passive form, is it? To be consistent with your suggestion "VDR sammutetaan" ("VDR will be shut down"), it should be "Laajennos aktivoidaan" or "Laajennos käynnistetään" ("Plugin will be activated"). That sounds unnecessarily complicated to me, as does "VDR sammutetaan". The passive form is used when the subject is not known. We know that it is VDR that shuts down itself or activates a plugin. The active form is also shorter than the passive form.
Yes and no :) The passive is hidden in to the end ("sammutetaanko?") and the explanation at the start ("Laajennos käynnistyy %ld minuutin kuluttua") doesn't have to be as we aren't expecting any response to it.
Does VDR really shut _itself_ off ("VDR sammuu")? I've always think that it just listens signals from OS that can be generated via the external shutdown script.
BR, -- rofa
On Wed, Jan 31, 2007 at 09:02:58AM +0200, Rolf Ahrenberg wrote:
I would rather write "käynnistyy" instead of the foreign "aktivoituu".
But VDR starts ("käynnistää") all plugins already at the beginning and depending on the plugins behaviour it's activated on main menu action, external trigger, ... So, using the "käynnistää" as activate confuses me a bit and I'd avoid using it here, but I can live with it.
I didn't think of that. If the verb is already used in some translation string, it might be good to avoid using the verb in another context. What about "Laajennos herää" (Plugin wakes up)?
Does VDR really shut _itself_ off ("VDR sammuu")? I've always think that it just listens signals from OS that can be generated via the external shutdown script.
When VDR invokes the external shutdown script, I would say that it indeed does shut itself off, or at least attempts to. But it might be a little funny to write "VDR attempts to shut down in %ld minutes" or "VDR yrittää sammua %ld minuutin päästä". That would make sense if the vdr-shutdown script could deny the operation because some other application on the VDR box is being used.
Marko
Hi,
I have been using VDR for about two years now, without any big problems. :)
Now I built a new system with two cards. One is my old hauppaude nova-t, other is technotrend nova-t with CI..
With only one card installed, both cards work fine. If I install both cards, only one the newer card works! Older card is found by VDR and can tune channels, but there is no picture..
Any ideas?
It could be some hardware issue, if there is some conflict with two cards.. But I have tried both cards in all PCI slots, no difference there. :)
-- Teemu Suikki http://www.z-power.fi
Teemu Suikki wrote:
With only one card installed, both cards work fine. ...
This sounds like an interesting solution... Can you post a link to picture showing this particular setup? :-P scnr
It could be some hardware issue, if there is some conflict with two cards.. But I have tried both cards in all PCI slots, no difference there.
With both cards installed, load the budget and the budget-ci modules and then take a look at the dmesg output and see what it says. Look into /proc/interrupts and see if both cards may be using the same interrupt. What happens if you append "acpi=off" and/or "noapic" to the kernel?
Let us know what you found out.
André
PS: Please start a new message when posting to a list and do not reply to an older message by replacing the subject.
On Wed, 31 Jan 2007 Andre.Weidemann@web.de wrote:
Teemu Suikki wrote:
With only one card installed, both cards work fine. ...
This sounds like an interesting solution... Can you post a link to picture showing this particular setup? :-P scnr
Bah. :)
It could be some hardware issue, if there is some conflict with two cards.. But I have tried both cards in all PCI slots, no difference there.
With both cards installed, load the budget and the budget-ci modules and then take a look at the dmesg output and see what it says.
Actually both cards use budget-ci, the other card just doesn't have the physical connector although it has a place for it in the PCB. The cards look very similar, but newer card has tda10046 and older tda10045 frontend.. Both have saa7146 pci chip.
Here's dmesg output, looks ok to me:
saa7146: register extension 'budget_ci dvb'. PCI: Found IRQ 11 for device 0000:02:05.0 PCI: Sharing IRQ 11 with 0000:00:0d.0 saa7146: found saa7146 @ mem e0974c00 (revision 1, irq 11) (0x13c2,0x1012). saa7146 (0): dma buffer size 192512 DVB: registering new adapter (TT-Budget-T-CI PCI). adapter has MAC addr = 00:d0:5c:04:43:33 input: Budget-CI dvb ir receiver saa7146 (0) as /class/input/input1 budget_ci: CI interface initialised DVB: registering frontend 0 (Philips TDA10046H DVB-T)... dvb_ca adapter 0: DVB CAM detected and initialised successfully
PCI: Found IRQ 3 for device 0000:02:08.0 saa7146: found saa7146 @ mem e0976800 (revision 1, irq 3) (0x13c2,0x1011). saa7146 (1): dma buffer size 192512 DVB: registering new adapter (TT-Budget/WinTV-NOVA-T PCI). adapter has MAC addr = 00:d0:5c:22:27:8a input: Budget-CI dvb ir receiver saa7146 (1) as /class/input/input2 DVB: registering frontend 1 (Philips TDA10045H DVB-T)...
Look into /proc/interrupts and see if both cards may be using the same interrupt.
Nope..
3: 64681 XT-PIC saa7146 (1) 11: 3565 XT-PIC saa7146 (0), eth0
Adapter 0 is the one that is working, so it doesn't matter that it shares interrupt with eth0. Adapter 1 seems to generate a lot of interrupts for some reason..
What happens if you append "acpi=off" and/or "noapic" to the kernel? >
No difference..
One thing I noticed is that after a reboot, working card always has valid firmware, but non-working card's firmware must always be re-uploaded.. So the firmware gets corrupted somehow?
Also I tried to tune channels with "tzap". It "works" for both cards, but the other card never reports FE_HAS_LOCK and "ber" is very high. Looks pretty much the same as if the antenna was unplugged.. (it's not..) :)
Perhaps there is some problem having tda10045 and tda10046 in same system? After all, both are handled by the same tda1004x module..
-- Teemu Suikki http://www.z-power.fi
Teemu Suikki wrote:
Perhaps there is some problem having tda10045 and tda10046 in same system? After all, both are handled by the same tda1004x module..
The dmesg output does not look suspicious at all. It seems as if both cards have been registered successfully. The only thing you can do, (that I can think of right now) was to write to the linux-dvb list and ask the developers there if they have ever tested this particular setup and if it could cause problems.
André
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
I demand that Teemu Suikki may or may not have written...
Hi,
I have been using VDR for about two years now, without any big problems. :)
Now I built a new system with two cards. One is my old hauppaude nova-t, other is technotrend nova-t with CI..
[snip]
What has this to do with the shutdown rewrite?
(Hint: new thread, not followup or reply.)
On Wed, 31 Jan 2007, Marko Mäkelä wrote:
I didn't think of that. If the verb is already used in some translation string, it might be good to avoid using the verb in another context. What about "Laajennos herää" (Plugin wakes up)?
That sounds ok.
When VDR invokes the external shutdown script, I would say that it indeed does shut itself off, or at least attempts to. But it might be a little funny to write "VDR attempts to shut down in %ld minutes" or "VDR yrittää sammua %ld minuutin päästä". That would make sense if the vdr-shutdown script could deny the operation because some other application on the VDR box is being used.
Well, I wouldn't try to translate that one too literally (no need to tell about trying) - it's enough to inform user that VDR will shut down in a few minutes. If it fails due to any plugin activity that could be informed later on.
These (sometimes rather annoying!) OSD messages should be as short and simple as possible.
BR -- rofa
Marko Mäkelä wrote:
First, and more important: Can you please suspend the playback of recordings when Shutdown.IsUserInactive() holds? Here is the relevant hunk from my vdr-suspend patch:
This would break the other interesting feature, shut down VDR as soon as the playback ends. Also, this would require a long and visible warning that VDR will soon stop playback because of inactivity, so the user wont be confused by the sudden stop of the playback.
Alternatively, could you suggest how to fix this in softdevice?
Maybe not switching off display while doing playback? It doesn't make much sense anyway to run playback invisible.
Second request: Consider modifying cDevice::Action() so that non-recording tuners will not be read during user inactivity. The kernel would then be able to turn off unnecessary tuners.
We had this discussion before, and since the majority of VDRs continues to display live video, I don't think that this should be part of VDR itself, and I don't really want to extend this patch into the deeper parts of cDevice.
To de-tune live devices, a plugin could display a still, like streamdev-server does, to free up devices.
Actually, it'd be nice to turn off any unneeded tuners, also during interactive use (multi-tuner setups, or watching recordings).
Unneeded tuners get de-tuned. Provide there are unneeded tuners. (I know that my primary FF card tuner gets de-tuned if I play back a recording.)
Cheers,
Udo
On Wed, Jan 31, 2007 at 10:55:11PM +0100, Udo Richter wrote:
Marko Mäkelä wrote:
First, and more important: Can you please suspend the playback of recordings when Shutdown.IsUserInactive() holds? Here is the relevant hunk from my vdr-suspend patch:
This would break the other interesting feature, shut down VDR as soon as the playback ends. Also, this would require a long and visible warning that VDR will soon stop playback because of inactivity, so the user wont be confused by the sudden stop of the playback.
Alternatively, could you suggest how to fix this in softdevice?
Maybe not switching off display while doing playback? It doesn't make much sense anyway to run playback invisible.
It does. The typical use case is that you pause live video or start a recording with a timer, then start watching it while it is still recording, so that you can skip commercial breaks. Then you get interrupted while watching it. It would be very handy to push the power button.
If it was a short interruption, you'd push any button to resume playback. If the interruption was longer (such as your kid wakes up and you'll have to put him back to sleep for a few hours), vdr would do the right thing and shut down after finishing the recording.
Second request: Consider modifying cDevice::Action() so that non-recording tuners will not be read during user inactivity. The kernel would then be able to turn off unnecessary tuners.
We had this discussion before, and since the majority of VDRs continues to display live video, I don't think that this should be part of VDR itself, and I don't really want to extend this patch into the deeper parts of cDevice.
I wouldn't be so sure about the majority of VDRs using FF cards. I haven't seen any ad for an FF card, but I have seen many ads for cheap USB DVB-T tuners. The trend is likely to change, given that decoding MPEG-2 is no challenge to current PC hardware. But anyway, I agree with you that this doesn't belong to the shutdown rewrite.
To de-tune live devices, a plugin could display a still, like streamdev-server does, to free up devices.
Hmm, doesn't the cDevice::Action() loop keep polling the device, even though there are no registered consumers for the data? At least that was the case last time I looked, around 1.3.38.
Unneeded tuners get de-tuned. Provide there are unneeded tuners. (I know that my primary FF card tuner gets de-tuned if I play back a recording.)
How can I check this? Using dvbstream or tzap while vdr is running? Or from some file in /sys or /proc?
Marko
On Thu, Feb 01, 2007 at 08:27:14PM +0200, Marko Mäkelä wrote:
Maybe not switching off display while doing playback? It doesn't make much sense anyway to run playback invisible.
It does. The typical use case is that you pause live video or start a recording with a timer, then start watching it while it is still recording, so that you can skip commercial breaks. Then you get interrupted while watching it. It would be very handy to push the power button.
If it was a short interruption, you'd push any button to resume playback. If the interruption was longer (such as your kid wakes up and you'll have to put him back to sleep for a few hours), vdr would do the right thing and shut down after finishing the recording.
According to Reinhard Nissl's reply in another thread, this can be fixed in the cDevice plugin by not blocking input in cDevice::PlayVideo() or cDevice::PlayAudio() when cDevice::Transferring() holds. I'll update my shutdown patch for softdevice soon. No need to change anything in your patch.
Marko
In 20070201182714.GA8722@localhost.localdomain, you wrote:
I wouldn't be so sure about the majority of VDRs using FF cards. I haven't seen any ad for an FF card, but I have seen many ads for cheap USB DVB-T tuners. The trend is likely to change, given that decoding MPEG-2 is no challenge to current PC hardware.
Also generic video cards are increasingly coming with video decoding features, and HDTVs can be connected straight to a PC without the need for a horrible scaler or special screen mode. Although not all the decoding features are available to Linux, dedicated decoder/TV-out cards are looking quite obsolete, and DVB card manufacturers are bound to respond to that.
I wouldn't be so sure about the majority of VDRs using FF cards. I haven't seen any ad for an FF card, but I have seen many ads for cheap USB DVB-T tuners. The trend is likely to change, given that decoding MPEG-2 is no challenge to current PC hardware.
Also generic video cards are increasingly coming with video decoding features, and HDTVs can be connected straight to a PC without the need for a horrible scaler or special screen mode. Although not all the decoding features are available to Linux, dedicated decoder/TV-out cards are looking quite obsolete, and DVB card manufacturers are bound to respond to that.
Not to get too off-topic, but I disagree. In north america, from surveying posts on several bulletin boards, vdr usage seems to be 90%+ with FF cards (typically the Nexus-S). There's actually the perception with many in NA that vdr doesn't work with budget cards! And while more PCs are adding the built-in functions a FF card provides (Digital audio out, Coax or S-video out, adequate processing power for decoding) everything seems to be moving to mpeg-4. I know from working regularly with Xvid / mpeg4 files that they require a lot more processing power, and many pcs are older machines dedicated to running vdr, not top of the line full fledged 4 ghz systems. I've never regretted owning my FF card, and would look for a FF mpeg4 card if I was in the market. Plus, they always seem the simplest to configure and use with most software, not to mention not requiring a computer monitor to run vdr on FF :)
In 004b01c74640$882cd800$6b01010a@REDMOUNTAIN01, Patrick Mackin wrote:
Also generic video cards are increasingly coming with video decoding features, and HDTVs can be connected straight to a PC without the need for a horrible scaler or special screen mode. Although not all the decoding features are available to Linux, dedicated decoder/TV-out cards are looking quite obsolete, and DVB card manufacturers are bound to respond to that.
Not to get too off-topic, but I disagree. In north america, from surveying posts on several bulletin boards, vdr usage seems to be 90%+ with FF cards (typically the Nexus-S).
Is that HD-capable? HDTV seems quite common in NA, but currently in the UK there are very few HD channels, only available through overpriced subscriptions. It looks unlikely that there'll be any FTA/FTV HD until at least after the analogue terrestrial switch-off in 2012.
There's actually the perception with many in NA that vdr doesn't work with budget cards! And while more PCs are adding the built-in functions a FF card provides (Digital audio out, Coax or S-video out, adequate processing power for decoding) everything seems to be moving to mpeg-4.
If the Nexus-S requires replacement for HD/MPEG4 I wouldn't be surprised if its successor doesn't feature a decoder. The latest graphics cards support MPEG4 too, including H.264. Someone posted about a new DVB card which does have an MPEG4 decoder recently, but pointed out that it's only a reference design, not a production model. And it's PCI-E, so it doesn't look like the manufacturers are very keen to support old PCs.
I know from working regularly with Xvid / mpeg4 files that they require a lot more processing power, and many pcs are older machines dedicated to running vdr, not top of the line full fledged 4 ghz systems.
I haven't noticed a big difference, although I've only encountered MPEG4 part 2 (DivX etc), usually at lower resolutions than DVB/DVD, as opposed to HD H.264.
I've never regretted owning my FF card, and would look for a FF mpeg4 card if I was in the market. Plus, they always seem the simplest to configure and use with most software, not to mention not requiring a computer monitor to run vdr on FF :)
Well that was one of my points too. Connecting a typical HDTV to a PC is pretty much the same as connecting a monitor, not like all the headaches involved in getting a decent PAL or NTSC signal from a standard graphics card.
Is that HD-capable? HDTV seems quite common in NA, but currently in the UK there are very few HD channels, only available through overpriced subscriptions. It looks unlikely that there'll be any FTA/FTV HD until at least after the analogue terrestrial switch-off in 2012.
HDTV is not as common here as the advertising would make you believe. HDTV programming is very limited here also. The famous "shut off" of analog signals in NA is honestly much ado about nothing (interesting choice in year 2012 by the way). It concerns only OTA HDTV terrestrial reception, and in America, the vast majority of households (90%+) subscribe to cable or satellite. The remaining 10% are the homes that are too poor to afford an HDTV, and therefore won't care about OTA HDTV signals.
Unfortunately, there is no FTA satellite HDTV to speak of, and I doubt we will get any anytime soon. The business model in America for most services is proprietary, closed systems sold through monthly fees, whether we are talking about radio, television, software, health care, or what have you. I would venture a guess that over 99% of the population doesn't even know what dvb-s is, or that there is any "FTA" available other than the local terrestrial 4 or 5 networks (ABC/NBC/CBS/FOX) with their ever-shinking market share. And the vast majority of the FTA here is ethnic or religious programming. Nevertheless, MPEG4/H.263 is the future if only for bandwidth reasons, and HDTV is the future, if only for aspect ratio uniformity through the market. Again, sorry for straying off topic.
In 002d01c74652$e0c9c290$6b01010a@REDMOUNTAIN01, Patrick Mackin wrote:
Is that HD-capable? HDTV seems quite common in NA, but currently in the UK there are very few HD channels, only available through overpriced subscriptions. It looks unlikely that there'll be any FTA/FTV HD until at least after the analogue terrestrial switch-off in 2012.
HDTV is not as common here as the advertising would make you believe. HDTV programming is very limited here also. The famous "shut off" of analog signals in NA is honestly much ado about nothing (interesting choice in year 2012 by the way). It concerns only OTA HDTV terrestrial reception, and in America, the vast majority of households (90%+) subscribe to cable or satellite. The remaining 10% are the homes that are too poor to afford an HDTV, and therefore won't care about OTA HDTV signals.
Sorry to bring this up again, but the situation is worse than I thought. I've just heard that when UK analogue TV is discontinued, the government plans to sell off the bandwidth to the highest bidder (probably a mobile phone company) rather than use it for HDTV. So please could all UK readers visit http://www.hdforall.org.uk and sign both petitions.
At least in N America HDTV can be considered mainstream in that, even if you have to pay for them, a lot of the prime shows eg Lost, 24, Prison Break, are available in HD. In the UK you've got a choice between Sky and cable (if you happen to live in the right area for the one with HD).
AFAICT from browsing my Sky EPG Sky's own HD channels show non-HD material most of the time. BBC's HD channel has only demos, old non-HD shows, and the same costume drama that they've been showing every day since the servie was launched. You do get National Geographic HD. In terms of content I prefer Discovery, but they can't even manage widescreen yet!
Apparently on Telewest cable you don't get any of the above except BBC. You also get an ITV HD channel which has about as much fresh material as the BBC one, and you can get old movies on demand (so that would be pay-per-view presumably).
Marko Mäkelä wrote:
It does. The typical use case is that you pause live video or start a recording with a timer, then start watching it while it is still recording, so that you can skip commercial breaks. Then you get interrupted while watching it. It would be very handy to push the power button.
Actually I would press the pause button, as I usually don't want to miss anything. And then the playback should be halted anyway, no matter if display is on or off.
Unneeded tuners get de-tuned. Provide there are unneeded tuners. (I know that my primary FF card tuner gets de-tuned if I play back a recording.)
How can I check this? Using dvbstream or tzap while vdr is running? Or from some file in /sys or /proc?
I can, because my second card has the annoying 'feature' to loose its signal if the first FF card turns off the LNB power. Its quite common for me that I get a VDSB on recording start while watching a playback. The easiest fix is to start a recording that keeps the primary FF card 'busy'.
Cheers,
Udo
On Fri, Feb 02, 2007 at 12:22:12AM +0100, Udo Richter wrote:
Marko Mäkelä wrote:
It does. The typical use case is that you pause live video or start a recording with a timer, then start watching it while it is still recording, so that you can skip commercial breaks. Then you get interrupted while watching it. It would be very handy to push the power button.
Actually I would press the pause button, as I usually don't want to miss anything. And then the playback should be halted anyway, no matter if display is on or off.
But you surely would power the display off, to avoid burning the still image on the CRT or plasma screen or to save the precious hours on the lamp of your video beamer? Or maybe you have a TFT screen and do not care about wasting electricity?
For what it is worth, I updated my softdevice patch so that it pauses the playback of recordings when suspended, that is, addresses this problem. Interested parties can fetch the patch from http://www.iki.fi/~msmakela/software/vdr#shutdown, more precisely http://www.iki.fi/~msmakela/software/vdr/shutdown-softdevice.patch. I will also submit a simpler patch to the softdevice mailing list that fixes only this long-standing bug (when you play back a recording and suspend softdevice from the menu, the recording will fast-forward to the end).
How can I check this? Using dvbstream or tzap while vdr is running? Or from some file in /sys or /proc?
I can, because my second card has the annoying 'feature' to loose its signal if the first FF card turns off the LNB power. Its quite common for me that I get a VDSB on recording start while watching a playback. The easiest fix is to start a recording that keeps the primary FF card 'busy'.
OK, I take your word for it.
Marko
Marko Mäkelä wrote:
Actually I would press the pause button, as I usually don't want to miss anything. And then the playback should be halted anyway, no matter if display is on or off.
But you surely would power the display off, to avoid burning the still image on the CRT or plasma screen or to save the precious hours on the lamp of your video beamer? Or maybe you have a TFT screen and do not care about wasting electricity?
Actually, I have a plain old CRT that doesn't seriously suffer from burning in. (provide that I resume playback within a month or so. ;) )
And if I want to save power, I power off the CRT completely, and thats something my VDR cannot do on its own (yet). Just blanking the screen has no advantage for me.
Cheers,
Udo
On Sat, Feb 03, 2007 at 10:48:42AM +0100, Udo Richter wrote:
Marko Mäkelä wrote:
Actually I would press the pause button, as I usually don't want to miss anything. And then the playback should be halted anyway, no matter if display is on or off.
But you surely would power the display off, to avoid burning the still image on the CRT or plasma screen or to save the precious hours on the lamp of your video beamer? Or maybe you have a TFT screen and do not care about wasting electricity?
Actually, I have a plain old CRT that doesn't seriously suffer from burning in. (provide that I resume playback within a month or so. ;) )
And if I want to save power, I power off the CRT completely, and thats something my VDR cannot do on its own (yet). Just blanking the screen has no advantage for me.
I'll shortly make my updated vdr-relay plugin available, adapted for your shutdown rewrite patch. Then you can install a simple solid-state relay to a spare RS-232 port. I ended up installing mine inside the soon 20-year-old 14" CRT, to reduce clutter. I control everything from the bundled Hauppauge remote control unit.
http://www.iki.fi/~msmakela/electronics/relay/
For the cable, I used an old mouse cord that I soldered to a mono plug. I attached a mono jack to the monitor's back together with a manual override switch. The solid-state relay is connected in series with the power switch of the monitor.
Marko
Hi,
But you surely would power the display off, to avoid burning the still image on the CRT or plasma screen or to save the precious hours on the lamp of your video beamer? Or maybe you have a TFT screen and do not care about wasting electricity?
Surely this shouldn't be too difficult to implement via a Plugin.
One could either simply blank out the screen after a configurable time once the Pause button is pressed (and no other key). Another idea would be to show a small OSD containing a configurable picture of one's on choice that is randomly placed and shown on the main (large) OSD while blanking out the background. Maybe as an extension of the Picture in Picture plugin or the Showpicture plugin.
regards, Reinhard
On Wed, Jan 31, 2007 at 10:55:11PM +0100, Udo Richter wrote:
Marko Mäkelä wrote:
First, and more important: Can you please suspend the playback of recordings when Shutdown.IsUserInactive() holds?
This would break the other interesting feature, shut down VDR as soon as the playback ends.
The above can be addressed in plugins that are derived from cDevice. However, you're right about breaking that feature: if PlayVideo() and PlayAudio() start refusing data when Shutdown.IsUserInactive() holds, the playback will never end, and VDR would probably wait MinUserInactivity (3 hours by default) until shutdown.
So, I have a feature request that would greatly improve the WAF around here. Could you please introduce a configuration option that would allow the Power key to initiate shutdown even while playing a recording (provided that nothing else prevents a shutdown, of course)? After all, it does initiate shutdown when viewing live program without waiting until the end of the current program.
The problem in our family is that my wife often watches recorded children's programs with my kids, and they may try to shut down VDR while the credits texts are running. It'd be an extra step to press the Stop button before Power.
Marko
Marko Mäkelä wrote:
However, you're right about breaking that feature: if PlayVideo() and PlayAudio() start refusing data when Shutdown.IsUserInactive() holds, the playback will never end, and VDR would probably wait MinUserInactivity (3 hours by default) until shutdown.
While playback, the current patch waits beyond these 3 hours. (Without, too)
Could you please introduce a configuration option that would allow the Power key to initiate shutdown even while playing a recording (provided that nothing else prevents a shutdown, of course)?
You can shut down while playback, you just have to confirm it. And if you don't confirm it, VDR will shut down 5 minutes after the playback ends.
(the current behavior is to ignore the power key while playback, and then shut down unexpectedly at end of playback)
Cheers,
Udo
On Wed, Feb 07, 2007 at 12:06:20AM +0100, Udo Richter wrote:
Could you please introduce a configuration option that would allow the Power key to initiate shutdown even while playing a recording (provided that nothing else prevents a shutdown, of course)?
You can shut down while playback, you just have to confirm it. And if you don't confirm it, VDR will shut down 5 minutes after the playback ends.
Sure, if the playback ends. It won't end with my patched softdevice that stops the playback of recordings when Shutdown.IsUserInactive() returns true.
I had a look at the code, specifically vdr.c and shutdown.c. I believe that the right thing would be to add a second parameter to ConfirmShutdown(), to allow cReplayControl::NowReplaying() to be ignored. Then, VDR wouldn't shut down unexpectedly while playing back a recording even if the inactivity timeout kicks in. But VDR wouldn't ask for confirmation when pressing the Power key. Thus, no new configuration option would be necessary.
What do you think? Should I submit a patch?
Marko
It's a safe assumption that when a user presses a power button, they intend that the device be immediately turned off or shut down. I can't think of any device that performs any differently. If a user wants to shut down vdr after he's done watching a playback, he would obviously still be sitting there when it ends therefore he can press the power button when its over.
I see no reason to make this issue more complex than it should be. The power button has the final say, you don't press it if you don't want to force a shutdown. What logic is there that vdr should be any different?
Just my $.02 fellas.
Cheers!
Marko Mäkelä wrote:
You can shut down while playback, you just have to confirm it. And if you don't confirm it, VDR will shut down 5 minutes after the playback ends.
Sure, if the playback ends. It won't end with my patched softdevice that stops the playback of recordings when Shutdown.IsUserInactive() returns true.
I do understand this right: If your softdevice detects IsUserInactive, then it sends a 'stop playback' to VDR? Weired...
I guess the most natural behavior would be to pretend that you're playing back normally, eg. make softdevice eat the incoming data stream at normal speed without decoding it.
Then, VDR wouldn't shut down unexpectedly while playing back a recording even if the inactivity timeout kicks in. But VDR wouldn't ask for confirmation when pressing the Power key. Thus, no new configuration option would be necessary.
More easy, just drop the playback check completely. A running playback means that the !Interact check in vdr.c will prevent any housekeeping and thus automatic shutdown.
But again, that way you cannot get VDR into inactive mode manually while playback.
Cheers,
Udo
On Wed, Feb 07, 2007 at 10:40:44PM +0100, Udo Richter wrote:
Marko Mäkelä wrote:
You can shut down while playback, you just have to confirm it. And if you don't confirm it, VDR will shut down 5 minutes after the playback ends.
Sure, if the playback ends. It won't end with my patched softdevice that stops the playback of recordings when Shutdown.IsUserInactive() returns true.
I do understand this right: If your softdevice detects IsUserInactive, then it sends a 'stop playback' to VDR? Weired...
It doesn't actually send anything to VDR; it'll just return 0 from cDevice::PlayVideo() and cDevice::PlayAudio(). It will also have to sleep a little, because otherwise VDR would use 100% of CPU.
I guess the most natural behavior would be to pretend that you're playing back normally, eg. make softdevice eat the incoming data stream at normal speed without decoding it.
Well, that would still break this scenario: You're watching a recording while it is being recorded. Then you get interrupted and push the Power button. Before the timed recording finishes and VDR gets a chance to shut down, you get back and push a button to switch to interactive state. You will be surprised to see that the playback doesn't resume from the same position.
Then, VDR wouldn't shut down unexpectedly while playing back a recording even if the inactivity timeout kicks in. But VDR wouldn't ask for confirmation when pressing the Power key. Thus, no new configuration option would be necessary.
More easy, just drop the playback check completely. A running playback means that the !Interact check in vdr.c will prevent any housekeeping and thus automatic shutdown.
Before writing my previous message, I added #if 0 #endif around the NowReplaying() check in shutdown.c, and it seems to work. VDR will be powered off during playback if there is no timed recording going on.
But again, that way you cannot get VDR into inactive mode manually while playback.
Is that feature necessary? If you believe so, maybe you could introduce a configuration option for enabling it? The default behaviour would be to obey the Power button immediately. The option could be named something like "Shutdown during playback must be confirmed".
Marko
Marko Mäkelä wrote:
Well, that would still break this scenario: You're watching a recording while it is being recorded. Then you get interrupted and push the Power button. Before the timed recording finishes and VDR gets a chance to shut down, you get back and push a button to switch to interactive state. You will be surprised to see that the playback doesn't resume from the same position.
Actually I wouldn't. Its the POWER key, not the PAUSE key. If I do that with my old VCR (means, switch off the TV instead of pausing the VCR) the same thing would happen.
But again, that way you cannot get VDR into inactive mode manually while playback.
Is that feature necessary? If you believe so, maybe you could introduce a configuration option for enabling it? The default behaviour would be to obey the Power button immediately. The option could be named something like "Shutdown during playback must be confirmed".
Its mainly because the 'old' code did not shut down while playback, at least since 1.3.25. (No longer stopping Transfer Mode or replay immediately when the Power button is pressed (thanks to Rolf Ahrenberg)) Before, I think, the power button stopped playback and did shut down.
I don't want to add yet another config option, either we let the power button work directly while playback, or we ask for confirmation on playback. Whatever the majority wants.
Cheers,
Udo
On 2/7/07, Udo Richter udo_richter@gmx.de wrote:
I don't want to add yet another config option, either we let the power button work directly while playback, or we ask for confirmation on playback. Whatever the majority wants.
Recording is one thing but I've never seen a VCR, DVD player, DVR, etc. that asks you to confirm if you hit the power button during playback. People don't usually hit a power button on accident, they hit it expecting that the device shut off. If I hit the power button on my dvd player while I'm watching a movie, I don't have to confirm anything. I hit the button and go on my way without waiting around to see what happens. This is by far the most common behavior of any device with a power button. I'm honestly surprised forcing conditions on the power button is even a consideration! The idea was bad from the start (sorry Rolf Ahrenberg).
On Wed, 7 Feb 2007, VDR User wrote:
The idea was bad from the start (sorry Rolf Ahrenberg).
Well, without my modification the power key did blank the screen while asking about canceling the shutdown and after that the video came back (no matter if cancelled it or not). This was a really nasty feature and I don't want it back, but maybe the implementation wasn't as clean as it could have been and accidentally produced new undocumented "features".
BTW, I'm very used to VDR's current behaviour to shutdown itself after the recording is made and don't want to get rid of that one either.
BR, -- rofa
On Thu, Feb 08, 2007 at 01:08:33PM +0200, Rolf Ahrenberg wrote:
BTW, I'm very used to VDR's current behaviour to shutdown itself after the recording is made and don't want to get rid of that one either.
As far as I understand, nobody has suggested that we should get rid of that feature. You could compare this to an analog VCR. I would believe that they refuse to power off when there is a timed recording going on.
Marko
On 2/8/07, Marko Mäkelä marko.makela@hut.fi wrote:
On Thu, Feb 08, 2007 at 01:08:33PM +0200, Rolf Ahrenberg wrote:
BTW, I'm very used to VDR's current behaviour to shutdown itself after the recording is made and don't want to get rid of that one either.
As far as I understand, nobody has suggested that we should get rid of that feature. You could compare this to an analog VCR. I would believe that they refuse to power off when there is a timed recording going on.
Yes, exactly.
In my opinion, the behavior should be that the power button engages an immediate shutdown. Period. The ONLY exception to this would be if vdr is currently recording something, in which case a warning comes up and asks you to confirm the shutdown. Very simple, very straight forward, and is consistent with every other vdr, dvd, pvr, etc. that I've ever seen.
Also, the user "inactivity" stuff is again, a bad idea. Vdr should not assume anything or take action just because the user hasn't interacted with it in a while. This type of behavior is simply not consistent with other devices and not a behavior the user would expect. My tv will not turn itself off based on my 'inactivity'.
I stress again, this issue doesn't need to be unnecessarily complicated. These types of devices, in their basic function, have existed for years. There is no new ground being broken here and no good reason to move away from the commonly expected behavior.
Cheers!
user.vdr@gmail.com Also, the user "inactivity" stuff is again, a bad idea. Vdr should not assume anything or take action just because the user hasn't interacted with it in a while. This type of behavior is simply not consistent with other devices and not a behavior the user would expect. My tv will not turn itself off based on my 'inactivity'.
Maybe if you got a newer/better TV you would have this feature. My TV turns itself off after some inactivity time. So does my coffee-machine.
I have many times accidentily switched of the VDR when someone else has set a timer and thus missed the recording.
To me the logical way to do this would be:
- if no recording going on and no timers switch off - if recording warn and ask for confirmation - if timer set warn and ask if it should write to nvram and then switch off
Ideally how to behave could be chosen with settings.
Josce ________________________________________________________________________ Check Out the new free AIM(R) Mail -- 2 GB of storage and industry-leading spam and email virus protection.
On 2/8/07, joscej@netscape.net joscej@netscape.net wrote:
user.vdr@gmail.com Also, the user "inactivity" stuff is again, a bad idea. Vdr should not assume anything or take action just because the user hasn't interacted with it in a while. This type of behavior is simply not consistent with other devices and not a behavior the user would expect. My tv will not turn itself off based on my 'inactivity'.
Maybe if you got a newer/better TV you would have this feature. My TV turns itself off after some inactivity time. So does my coffee-machine.
I have a new/great TV, and it will not turn itself off if I don't interact with the tv itself while I'm watching an all-day marathon of Lost for example. We're talking about tv here. People tend to put on something they want to watch, and then watch it... Not play with their remote control or fiddle with tv settings. It's completely ridiculous to assume the user is done watching tv simply because he doesn't tell his tv otherwise every x minutes or x hours. If he wants the tv off, he can turn it off himself. There is no reason to behave otherwise unless it's done thru some kind of "auto-shutoff? [y/n]" setting. With a setting like that I suppose you could specify to shut off at a certain time of the day or user-defined timeout period. But force a shutdown because the user hasn't interacted with vdr? No way! He was probably too busy enjoying his favorite shows to think 'oh, I better check in with my tv before it turns itself off'. Come on now.
Also, a coffee-maker is not a device used for entertainment purposes. Nobody turns their coffee-maker on and then sits there watching it. I hope not anyways.
I have many times accidentily switched of the VDR when someone else has
set a timer and thus missed the recording.
To me the logical way to do this would be:
- if no recording going on and no timers switch off
- if recording warn and ask for confirmation
- if timer set warn and ask if it should write to nvram and then switch
off
Ideally how to behave could be chosen with settings.
How about if a timer is set to record within the next x minutes (defined by the user), warn and ask to confirm shutdown? This seems like a reasonable way to deal with the issue to me.
On Thu, 8 Feb 2007, VDR User wrote:
There is no reason to behave otherwise unless it's done thru some kind of "auto-shutoff? [y/n]" setting. With a setting like that I suppose you could specify to shut off at a certain time of the day or user-defined timeout period. But force a shutdown because the user hasn't interacted with vdr?
I still cannot follow your reasoning as the user can already disable the automatic shutdown feature. Do you want to remove this option completely, rename it or change its' behaviour? The shutdown could be changed to a standby/powersave mode: the stream decoding will be turned off instead of poweroff.
VDR's MANUAL: "Setting MinUserInactivity to 0 disables the automatic shutdown, while still retaining the possibility to manually shutdown the computer."
-- rofa
VDR User wrote:
There is no reason to behave otherwise unless it's done thru some kind of "auto-shutoff? [y/n]" setting.
As said above, its called "Min User Inactivity" and can be set to 0.
Also, a coffee-maker is not a device used for entertainment purposes. Nobody turns their coffee-maker on and then sits there watching it. I hope not anyways.
Hmmmm. Can a coffee maker run VDR? :)
How about if a timer is set to record within the next x minutes (defined by the user), warn and ask to confirm shutdown? This seems like a reasonable way to deal with the issue to me.
Called "Min Event Timeout", and will ask "Recording in xxx minutes, shut down anyway?".
Any other existing options you want to know of?
Cheers,
Udo
On 2/8/07, Udo Richter udo_richter@gmx.de wrote:
Hmmmm. Can a coffee maker run VDR? :)
If it's possible, somebody will find a way! ;)
Any other existing options you want to know of?
I hadn't pay much attention to this thread until recently and the way some things were worded made it seem like the behaviors being discussed were going to be forced. That coupled with the fact that this thread focuses on a re-write, which leads one to believe there will be changes to the existing methods.
If vdr has commonly expected behavior for this kind of device/software, and the user can modify that to be uncommon or to suit his needs via settings & options, then no problem. My only concern is that things would be forced that shouldn't be.
I'm going to go watch my coffee-maker now.
Cheers!
I demand that VDR User may or may not have written...
[snip]
Also, a coffee-maker is not a device used for entertainment purposes. Nobody turns their coffee-maker on and then sits there watching it. I hope not anyways.
They might point a camera (probably a webcam) at it, though...
[snip]
On Fri, Feb 09, 2007 at 05:55:54PM +0000, Darren Salt wrote:
I demand that VDR User may or may not have written...
[snip]
Also, a coffee-maker is not a device used for entertainment purposes. Nobody turns their coffee-maker on and then sits there watching it. I hope not anyways.
They might point a camera (probably a webcam) at it, though...
Such as the original webcam? http://www.theregister.co.uk/2001/03/07/worlds_first_webcam_coffee_pot/
Marko
On 2/9/07, Marko Mäkelä marko.makela@hut.fi wrote:
On Fri, Feb 09, 2007 at 05:55:54PM +0000, Darren Salt wrote:
I demand that VDR User may or may not have written...
[snip]
Also, a coffee-maker is not a device used for entertainment purposes. Nobody turns their coffee-maker on and then sits there watching it. I
hope
not anyways.
They might point a camera (probably a webcam) at it, though...
Such as the original webcam? http://www.theregister.co.uk/2001/03/07/worlds_first_webcam_coffee_pot/
Marko
Funny story!
VDR User wrote:
Also, the user "inactivity" stuff is again, a bad idea. Vdr should not assume anything or take action just because the user hasn't interacted with it in a while. This type of behavior is simply not consistent with other devices and not a behavior the user would expect. My tv will not turn itself off based on my 'inactivity'.
You can set the config option "Min User Inactivity" to 0, and VDR wont ever get 'inactive' by itself.
(with one exception, if a recording is going on and you press the power key, VDR will do the shutdown at end of recording. Technically this is user inactivity.)
The inactivity shutdown is nice as a fallback, for example if I just forgot to shut down, or if a power failure caused a reboot to make sure the wakeup is re-programmed.
Cheers,
Udo
I demand that VDR User may or may not have written...
On 2/8/07, Marko Mäkelä marko.makela@hut.fi wrote:
(August already?)
On Thu, Feb 08, 2007 at 01:08:33PM +0200, Rolf Ahrenberg wrote:
BTW, I'm very used to VDR's current behaviour to shutdown itself after the recording is made and don't want to get rid of that one either.
As far as I understand, nobody has suggested that we should get rid of that feature. You could compare this to an analog VCR. I would believe that they refuse to power off when there is a timed recording going on.
Yes, exactly.
In my opinion, the behavior should be that the power button engages an immediate shutdown. Period.
An appropriate signal, probably SIGTERM, should also do this.
The ONLY exception to this would be if vdr is currently recording something, in which case a warning comes up and asks you to confirm the shutdown.
Agreed. SIGHUP.
Then there's the upgrade restart, which should be available via a signal. The actual restart should be deferred if VDR is currently busy. (It is *possible* to implement this via runvdr, but it's a lot easier to handle if VDR can re-exec itself.)
[snip]
Darren Salt wrote:
Then there's the upgrade restart, which should be available via a signal. The actual restart should be deferred if VDR is currently busy. (It is *possible* to implement this via runvdr, but it's a lot easier to handle if VDR can re-exec itself.)
Hmmmm. Some kind of i-am-idle-lets-do-a-restart state? I'm not really sure what makes this different to the existing stuff.
Surely, an upgrade should not interrupt ongoing activity. If the VDR does automatic shutdown, then the answer is simple: Do your upgrade on next shutdown or restart. Thats the earliest time anyway.
I guess the only situation that may cause a problem is if the VDR never shuts down, eg. has no shutdown script at all. It must have some "Min User Inactivity" setting, or else live viewing could be interrupted by the automatic update.
Some kind of temporary shutdown script could do the trick. In normal situations, there's no shutdown because of no shutdown script, but in case of pending updates, a temporary shutdown script does the update.
For example, a plugin may be possible that reacts on a SVDRP command (request for update), and that sets a temporary shutdown script (calls Shutdown.SetShutdownCommand()). As soon as the script exists, the inactivity shutdown will be back, but instead of shutting down, the script stops VDR, installs the update and restarts.
Cheers,
Udo
I demand that Udo Richter may or may not have written...
Darren Salt wrote:
Then there's the upgrade restart, which should be available via a signal. The actual restart should be deferred if VDR is currently busy. (It is *possible* to implement this via runvdr, but it's a lot easier to handle if VDR can re-exec itself.)
Hmmmm. Some kind of i-am-idle-lets-do-a-restart state? I'm not really sure what makes this different to the existing stuff.
Maybe not much. I'm just making sure that what I see as useful here (from a packager's point of view) is heard...
Surely, an upgrade should not interrupt ongoing activity.
That's reasonable but ISTM that it's something which is best left to the local admin to decide. I'll agree that recording should *normally* never be interrupted (but a forcible shutdown needs to be possible).
If the VDR does automatic shutdown, then the answer is simple: Do your upgrade on next shutdown or restart. Thats the earliest time anyway.
That's possible, but not always appropriate or even wanted. (It doesn't match how I do things, for a start.)
I guess the only situation that may cause a problem is if the VDR never shuts down, eg. has no shutdown script at all. It must have some "Min User Inactivity" setting, or else live viewing could be interrupted by the automatic update.
The user inactivity setting isn't relevant to that, AFAICS.
Some kind of temporary shutdown script could do the trick. In normal situations, there's no shutdown because of no shutdown script, but in case of pending updates, a temporary shutdown script does the update.
For example, a plugin may be possible that reacts on a SVDRP command (request for update), and that sets a temporary shutdown script (calls Shutdown.SetShutdownCommand()). As soon as the script exists, the inactivity shutdown will be back, but instead of shutting down, the script stops VDR, installs the update and restarts.
(Did you mean "exits"?)
That has problems...
The update could already be installed. This is normally true when a package manager is used (it's definitely true here - I build .debs for local installation), but could also be true of an early "make install".
The local admin may have disabled SVDRP or the SVDRP port may be in use (perhaps a buggy plugin, or maybe just bad timing). Sending a signal to the running vdr process works regardless.
SVDRP has one advantage here, though - response codes. OTOH, I'm reasonably sure that that can be negated by kill() and getppid() or, possibly, a pipe, and I can easily adapt runvdr (well, my runvdr.c) to wait for a short time for vdr to respond...
Darren Salt wrote:
I guess the only situation that may cause a problem is if the VDR never shuts down, eg. has no shutdown script at all. It must have some "Min User Inactivity" setting, or else live viewing could be interrupted by the automatic update.
The user inactivity setting isn't relevant to that, AFAICS.
If you want to do the update while there's no ongoing activity, then you'll need some kind of user inactivity, otherwise a live viewer would be interrupted instantly.
For example, a plugin may be possible that reacts on a SVDRP command (request for update), and that sets a temporary shutdown script (calls Shutdown.SetShutdownCommand()). As soon as the script exists, the inactivity shutdown will be back, but instead of shutting down, the script stops VDR, installs the update and restarts.
(Did you mean "exits"?)
Actually, exists, in the sense that the name of a script has been set using the Shutdown.SetShutdownCommand() call.
The local admin may have disabled SVDRP or the SVDRP port may be in use (perhaps a buggy plugin, or maybe just bad timing). Sending a signal to the running vdr process works regardless.
Ok, a suggestion how this could be done in a simple and useful way:
We re-define SIGHUP, so that it doesn't terminate VDR instantly, but instead checks for activity. If user and vdr is inactive, act just like sigterm, if there's some activity, ignore the signal. An external script could then repeat sending the SIGHUP periodically until termination did succeed. Also, the SIGHUP effect is not delayed for an indefinite time and wont strike unexpected / needs thoughts on how to cancel the SIGHUP if you change your mind.
And on SVDRP: Since the SVDRP rewrite is on the todo list anyway, we could add support to do SVDRP on unix domain sockets, not just TCP. Domain sockets are represented by files (like for example /etc/vdr/svdrp.socket) and access rights are controlled by the file system. This would allow to open SVDRP only for the local root, or just for the local video user group.
Cheers,
Udo
I demand that Udo Richter may or may not have written...
Darren Salt wrote:
I guess the only situation that may cause a problem is if the VDR never shuts down, eg. has no shutdown script at all. It must have some "Min User Inactivity" setting, or else live viewing could be interrupted by the automatic update.
The user inactivity setting isn't relevant to that, AFAICS.
If you want to do the update while there's no ongoing activity, then you'll need some kind of user inactivity, otherwise a live viewer would be interrupted instantly.
Local policy would seem to be the best way to handle this.
For example, a plugin may be possible that reacts on a SVDRP command (request for update), and that sets a temporary shutdown script (calls Shutdown.SetShutdownCommand()). As soon as the script exists, the inactivity shutdown will be back, but instead of shutting down, the script stops VDR, installs the update and restarts.
(Did you mean "exits"?)
Actually, exists, in the sense that the name of a script has been set using the Shutdown.SetShutdownCommand() call.
Bad choice of word - the obvious meaning of the phrase is "when the script is created".
The local admin may have disabled SVDRP or the SVDRP port may be in use (perhaps a buggy plugin, or maybe just bad timing). Sending a signal to the running vdr process works regardless.
Ok, a suggestion how this could be done in a simple and useful way:
We re-define SIGHUP, so that it doesn't terminate VDR instantly, but instead checks for activity. If user and vdr is inactive, act just like sigterm, if there's some activity, ignore the signal.
An external script could then repeat sending the SIGHUP periodically until termination did succeed.
That'd be start-stop-daemon, most likely, which means that the task would have to be backgrounded. Its -R option is useful for this - something like "-R forever/-HUP/5", I think - but it's just possible that VDR may become inactive then active without receiving a signal in between.
However, that doesn't fit in well with runvdr, or at least with my version - which you can find in this diff (which can be cleanly applied against an empty directory) as vdr-1.4.5/debian/runvdr.c: URL:http://zap.tartarus.org/~ds/debian/dists/unstable/main/source/vdr_1.4.5-1.ds.diff.gz (Link: URL:http://www.youmustbejoking.demon.co.uk/progs.sid.html#vdr)
Also, the SIGHUP effect is not delayed for an indefinite time and won't strike unexpectedly / needs thoughts on how to cancel the SIGHUP if you change your mind.
Sending a SIGTERM would obviously cancel it. :-)
That aside, I'd probably use SIGUSR1 as a cancellation (which should be as simple as clearing a flag).
And on SVDRP: Since the SVDRP rewrite is on the todo list anyway, we could add support to do SVDRP on unix domain sockets, not just TCP. Domain sockets are represented by files (like for example /etc/vdr/svdrp.socket) and access rights are controlled by the file system. This would allow to open SVDRP only for the local root, or just for the local video user group.
That could be useful. For my purposes, though, I still prefer signals :-)
Darren Salt wrote:
We re-define SIGHUP, so that it doesn't terminate VDR instantly, but instead checks for activity. If user and vdr is inactive, act just like sigterm, if there's some activity, ignore the signal.
An external script could then repeat sending the SIGHUP periodically until termination did succeed.
That'd be start-stop-daemon, most likely, which means that the task would have to be backgrounded. Its -R option is useful for this - something like "-R forever/-HUP/5", I think - but it's just possible that VDR may become inactive then active without receiving a signal in between.
However, that doesn't fit in well with runvdr, or at least with my version
In this case I guess your runvdr is the one that should send the signals to VDR, as it also will know if VDR did terminate. And at least your runvdr probably knows your update strategies.
I'm currently coding it in a way that SIGHUP issues a VDR restart (exit code 1), if no serious activity (cutting, recording, plugins) is going on - just like the setup menu restart command. Otherwise, the signal is ignored.
Cheers,
Udo
On Sun, Feb 11, 2007 at 08:11:03PM +0000, Darren Salt wrote:
I demand that VDR User may or may not have written...
On 2/8/07, Marko Mäkelä marko.makela@hut.fi wrote:
(August already?)
Hey, I wrote that on 2007-02-08 (ISO date) or 8.2.2007 (German or Finnish style date). I think there are at least 3 permutations of /-separated dates in different locales.
In my opinion, the behavior should be that the power button engages an immediate shutdown. Period.
An appropriate signal, probably SIGTERM, should also do this.
The ONLY exception to this would be if vdr is currently recording something, in which case a warning comes up and asks you to confirm the shutdown.
Agreed. SIGHUP.
Brilliant idea. This would also simplify the ACPI powerbutton event script, whose name escapes me right now. I modified the script on my system to send "HITK Power" via SVDRP, but it would be much cleaner and probably somewhat faster to send a signal.
Darren, if your packages end up in the official Debian, I hope you will also provide a nice hook for the ACPI powerbutton event. (If vdr is running, signal it. Otherwise, shut down the system normally.)
Marko
Udo Richter wrote:
Marko Mäkelä wrote:
Well, that would still break this scenario: You're watching a recording while it is being recorded. Then you get interrupted and push the Power button. Before the timed recording finishes and VDR gets a chance to shut down, you get back and push a button to switch to interactive state. You will be surprised to see that the playback doesn't resume from the same position.
Actually I wouldn't. Its the POWER key, not the PAUSE key. If I do that with my old VCR (means, switch off the TV instead of pausing the VCR) the same thing would happen.
But again, that way you cannot get VDR into inactive mode manually while playback.
Is that feature necessary? If you believe so, maybe you could introduce a configuration option for enabling it? The default behaviour would be to obey the Power button immediately. The option could be named something like "Shutdown during playback must be confirmed".
Its mainly because the 'old' code did not shut down while playback, at least since 1.3.25. (No longer stopping Transfer Mode or replay immediately when the Power button is pressed (thanks to Rolf Ahrenberg)) Before, I think, the power button stopped playback and did shut down.
I don't want to add yet another config option, either we let the power button work directly while playback, or we ask for confirmation on playback. Whatever the majority wants.
I'd also say that the Power button should shutdown without confirmation unless there is a recording going on or a plugin is Active().
To avoid accidental shutdowns it might still prompt the user with "Shutdown - press any key to stay up" or something like that for a few seconds, but it shouldn't be necessary to confirm anything, even if a replay is currently going on.
Klaus
On 2/7/07, Klaus Schmidinger Klaus.Schmidinger@cadsoft.de wrote:
I'd also say that the Power button should shutdown without confirmation unless there is a recording going on or a plugin is Active().
To avoid accidental shutdowns it might still prompt the user with "Shutdown - press any key to stay up" or something like that for a few seconds, but it shouldn't be necessary to confirm anything, even if a replay is currently going on.
I appreciate your input on the issue, it seems that we're pretty much on the same page. I think your method of dealing with an accidental shutdown best suits the situation.
One question though... Say I have the sysinfo or femon plugin screen up, would this mean the plugin is Active() and would prevent a power button shutdown? This should not override a power button shutdown.
VDR User wrote:
On 2/7/07, *Klaus Schmidinger* <Klaus.Schmidinger@cadsoft.de mailto:Klaus.Schmidinger@cadsoft.de> wrote:
I'd also say that the Power button should shutdown without confirmation unless there is a recording going on or a plugin is Active(). To avoid accidental shutdowns it might still prompt the user with "Shutdown - press any key to stay up" or something like that for a few seconds, but it shouldn't be necessary to confirm anything, even if a replay is currently going on.I appreciate your input on the issue, it seems that we're pretty much on the same page. I think your method of dealing with an accidental shutdown best suits the situation.
One question though... Say I have the sysinfo or femon plugin screen up, would this mean the plugin is Active() and would prevent a power button shutdown? This should not override a power button shutdown.
A plugin is considered "active" if its Active() function returns a string. So it's entirely up to the plugin whether or not it wants to prevent a shutdown. However, just having a plugin's menu screen open shouldn't mean the plugin is active. Plugin activity is something like burning a DVD or doing some other stuff that shouldn't be interrupted.
Klaus
On 2/8/07, Klaus Schmidinger Klaus.Schmidinger@cadsoft.de wrote:
A plugin is considered "active" if its Active() function returns a string. So it's entirely up to the plugin whether or not it wants to prevent a shutdown. However, just having a plugin's menu screen open shouldn't mean the plugin is active. Plugin activity is something like burning a DVD or doing some other stuff that shouldn't be interrupted.
Gotcha, thanks for clearing that up!
I believe that we have reached consensus on the Finnish translation.
On Sun, Jan 28, 2007 at 05:50:46PM +0100, Udo Richter wrote:
- i18n strings: "VDR will shut down later. Press power to force."
"VDR sammuu myöhemmin - pakota virtakytkimellä"
"VDR will shut down in %s minutes"
"VDR sammuu %s minuutin kuluttua" (consider replacing the %s with %ld)
"Replaying - shut down anyway?"
"Toisto kesken - sammutetaanko?"
"Cutting - shut down anyway?"
"Leikkaus kesken - sammutetaanko?"
"Plugin activity in %ld minutes, shut down anyway?"
"Laajennos herää %ld minuutin kuluttua - sammutetaanko?"
better:
"Plugin %s wakes up in %ld minutes, shut down anyway?"
"Laajennos %s herää %ld minuutin kuluttua - sammutetaanko?"
Marko
On Sun, Jan 28, 2007 at 05:50:46PM +0100, Udo Richter wrote:
Hi list,
I've finished a third version of the shutdown rewrite. Again there are two patches available, one for VDR 1.5.0, and one with slight changes for 1.4.x.
http://www.udo-richter.de/vdr/patches.html#shutdown http://www.udo-richter.de/vdr/patches.en.html#shutdown
I have adapted my "relay" plugin for this patch. This plugin controls a solid-state relay via the TxD line of a serial port, so that the audio/video output equipment is powered off when the user is inactive.
http://www.iki.fi/~msmakela/software/vdr/vdr-relay-0.1.0.tgz http://www.iki.fi/~msmakela/electronics/relay/index.en.html
Example of usage: vdr -P'relay --relay=/dev/ttyS0'
Note to Finnish users: the prototype relay box featured on the instructions page is for sale, because at a later point, I installed the relay inside the monitor to reduce the clutter of cables.
Marko
On Sun, Jan 28, 2007 at 05:50:46PM +0100, Udo Richter wrote:
- Added #define PATCH_SHUTDOWN_REWRITE to detect the patch Use #if VDRVERSNUM >= 105xx || defined(PATCH_SHUTDOWN_REWRITE) after final integration into VDR.
Now that VDR 1.5.1 includes the patch, I wonder if you are going to maintain the patch for vdr 1.4, or at least continue to host the latest version on your home page. I strongly hope so, because I am reluctant to switch my production system to the development branch until that branch stabilizes or introduces significant new features, such as support for UTF-8 locales or DVB subtitles.
Marko
On Sun, Feb 25, 2007 at 09:11:36PM +0200, Marko Mäkelä wrote:
On Sun, Jan 28, 2007 at 05:50:46PM +0100, Udo Richter wrote:
- Added #define PATCH_SHUTDOWN_REWRITE to detect the patch Use #if VDRVERSNUM >= 105xx || defined(PATCH_SHUTDOWN_REWRITE) after final integration into VDR.
Now that VDR 1.5.1 includes the patch, I wonder if you are going to maintain the patch for vdr 1.4, or at least continue to host the latest version on your home page.
I hope that you can release a 0.5 version of your patch that corresponds to what is included in VDR 1.5.1. Most notably, please rename the global variable Shutdown to ShutdownHandler.
Marko
Hi list,
I've finished a fourth version of the shutdown rewrite. Again there are two patches available, one for VDR 1.5.0, and one with slight changes for 1.4.x.
http://www.udo-richter.de/vdr/patches.html#shutdown http://www.udo-richter.de/vdr/patches.en.html#shutdown
Changes: - Renamed some identifiers: cSetup::NextWakeupEvent -> cSetup::NextWakeupTime cPlugin::NextWakeupEvent() -> cPlugin::WakeupTime() cPluginManager::GetNextWakeupEventPlugin() -> cPluginManager::GetNextWakeupPlugin()
- Dropped running playback from the list of things that need confirmation on shutdown. Pressing power key while playback now shuts down just like in live mode. Automatic inactivity shutdown still wont happen while playback, since playback blocks housekeeping.
- Handle setup menu restart questions in cShutdown::ConfirmRestart() - Do not handle setup menu restart as 'emergency exit' any more - Act differently on SIGHUP: Restart VDR like on setup menu restart, but dont ask questions. Do nothing if anything blocks restart.
- The functionality of cThread::EmergencyExit(), vdr.c:ExitCode and vdr.c:Interrupted is now handled by cShutdown. - Shutdown.Exit(int) now stops the main loop and lets VDR return int as error level - cThread::EmergencyExit() remains as a wrapper - vdr.c:LastSignal partially replaces vdr.c:Interrupted
- Dropped debug output from main loop
- i18n strings added for German and Finnish: "VDR will shut down later - Press power to force" "VDR schaltet später aus - Nochmal zum erzwingen" "VDR sammuu myöhemmin - pakota virtakytkimellä"
"VDR will shut down in %s minutes" ( note that %s will be something like 4:30 ) "VDR wird in %s Minuten ausschalten" "VDR sammuu %s minuutin kuluttua"
"Editing - shut down anyway?" ( no longer cutting ;) ) "Schneide - trotzdem ausschalten?" "Leikkaus kesken - sammutetaanko?"
"Plugin %s wakes up in %ld min, continue?" "Plugin %s wacht in %ld Min auf, weiter?" "Laajennos %s herää %ld minuutin kuluttua - sammutetaanko?" ( is this too long? )
"Editing - restart anyway?" "Schneide - trotzdem neu starten?"
"Press any key to cancel restart" "Taste drücken, um Neustart abzubrechen"
Cheers,
Udo
On Sun, Feb 18, 2007 at 10:09:54PM +0100, Udo Richter wrote:
"Editing - shut down anyway?" ( no longer cutting ;) ) "Schneide - trotzdem ausschalten?" "Leikkaus kesken - sammutetaanko?"
Hmm, this is inconsistent with most Finnish translations of "editing" ("muokkaus") in i18n.c. I'd replace "Leikkaus" with "Muokkaus".
"Editing - restart anyway?" "Schneide - trotzdem neu starten?"
"Muokkaus kesken - käynnistetäänkö uudelleen?"
"Press any key to cancel restart" "Taste drücken, um Neustart abzubrechen"
"Peru uudelleenkäynnistäminen painamalla mitä tahansa nappia"
Shouldn't it be "button" (Knopf) instead of "key" (Taste)? I would guess that most people control vdr with a remote control unit instead of a keyboard. Besides, "nappia" is shorter than "näppäintä" (as in the Finnish translation of "Press any key to cancel shutdown").
Marko
On Sun, 18 Feb 2007, Marko Mäkelä wrote:
On Sun, Feb 18, 2007 at 10:09:54PM +0100, Udo Richter wrote:
"Editing - shut down anyway?" ( no longer cutting ;) ) "Schneide - trotzdem ausschalten?" "Leikkaus kesken - sammutetaanko?"
Hmm, this is inconsistent with most Finnish translations of "editing" ("muokkaus") in i18n.c. I'd replace "Leikkaus" with "Muokkaus".
As Udo wrote it's no longer cutting ("leikkaus"), but editing ("muokkaus"), so the correct translation should be: "Muokkaus kesken - sammutetaanko?"
"Editing - restart anyway?" "Schneide - trotzdem neu starten?"
"Muokkaus kesken - käynnistetäänkö uudelleen?"
"Press any key to cancel restart" "Taste drücken, um Neustart abzubrechen"
"Peru uudelleenkäynnistäminen painamalla mitä tahansa nappia"
Shouldn't it be "button" (Knopf) instead of "key" (Taste)? I would guess that most people control vdr with a remote control unit instead of a keyboard. Besides, "nappia" is shorter than "näppäintä" (as in the Finnish translation of "Press any key to cancel shutdown").
Well, I disagree in finnish terms: "Paidassani on nappeja, mutta näppäimistössäni ja kaukosäätimessäni on näppäimiä". Otherwise these sounds quite ok, but I'd use "uudelleenkäynnistys" instead of "uudelleenkäynnistäminen" as this should be consistent with existing VDR translation:
"Press any key to cancel restart" "Peru uudelleenkäynnistys painamalla mitä tahansa näppäintä"
"Press any key to cancel shutdown" Peru sammutus painamalla mitä tahansa näppäintä"
I's also change this: "VDR sammuu myöhemmin - pakota virtakytkimellä" to "VDR sammuu myöhemmin - pakota virtanäppäimellä"
Notice, that this should be corrected also in current VDR's i18n.c.
I've one question about this sentence: "Plugin %s wakes up in %ld min, continue?"
If I'm pressing 'OK' here, does it continue the shutdown or running the VDR?
BR, -- rofa
On Mon, Feb 19, 2007 at 08:07:05PM +0200, Rolf Ahrenberg wrote:
Shouldn't it be "button" (Knopf) instead of "key" (Taste)? I would guess that most people control vdr with a remote control unit instead of a keyboard. Besides, "nappia" is shorter than "näppäintä" (as in the Finnish translation of "Press any key to cancel shutdown").
Well, I disagree in finnish terms: "Paidassani on nappeja, mutta näppäimistössäni ja kaukosäätimessäni on näppäimiä".
I believe that this is a matter of taste (no pun intended). Coincidentally, also the English and German words (button, Knopf) can be used in connection with pieces of clothing.
In the i18n.c of vdr 1.4.5, I can only find one label containing "button": "Menu button closes" ("Menu-Taste schließt"). So, I guess that you can ignore my remark.
Suggestion: replace "Setup.OSD$Menu button closes" with "Setup.OSD$Menu key closes".
Hmm, what is the logic between "Key$" and "Button$" names? Is there a reason to have both "Key$Stop" and "Button$Stop"? Perhaps one of them should be removed.
Marko
Marko Mäkelä wrote:
... In the i18n.c of vdr 1.4.5, I can only find one label containing "button": "Menu button closes" ("Menu-Taste schließt"). So, I guess that you can ignore my remark.
Suggestion: replace "Setup.OSD$Menu button closes" with "Setup.OSD$Menu key closes".
Basically I agree, but that would result in a setup file incompatibility. But in an effort to clarify the key vs. button issue I guess it would make sense.
Hmm, what is the logic between "Key$" and "Button$" names? Is there a reason to have both "Key$Stop" and "Button$Stop"? Perhaps one of them should be removed.
"Key$" is used in the context of the physical remote control thing that you actually press with your finger, while "Button" is used for the text that is displayed on the OSD in the red, green, yellow and blue field. Some of them are the same in both cases, but that might be different in the various languages.
Klaus
Rolf Ahrenberg wrote:
I've one question about this sentence: "Plugin %s wakes up in %ld min, continue?"
If I'm pressing 'OK' here, does it continue the shutdown or running the VDR?
I don't like it either, but didn't come up with a good other idea for this. For consistency it should be "Plugin %s wakes up in %ld minutes, restart anyway?", but thats way too long to fit into the status bar. The alternative would be to drop the plugin name again.
Cheers,
Udo
On Mon, 19 Feb 2007, Udo Richter wrote:
Rolf Ahrenberg wrote:
I've one question about this sentence: "Plugin %s wakes up in %ld min, continue?"
If I'm pressing 'OK' here, does it continue the shutdown or running the VDR?
I don't like it either, but didn't come up with a good other idea for this. For consistency it should be "Plugin %s wakes up in %ld minutes, restart anyway?", but thats way too long to fit into the status bar. The alternative would be to drop the plugin name again.
My vote goes to dropping the plugin name as it doesn't provide (imho) any valuable information for the user. Do we really need to know that a femon or relay plugin is about to wakeup in ten minutes, when we are restarting the VDR? I'd say: no.
BR, -- rofa
On Tue, Feb 20, 2007 at 08:52:20AM +0200, Rolf Ahrenberg wrote:
On Mon, 19 Feb 2007, Udo Richter wrote:
Rolf Ahrenberg wrote:
I've one question about this sentence: "Plugin %s wakes up in %ld min, continue?"
If I'm pressing 'OK' here, does it continue the shutdown or running the VDR?
I don't like it either, but didn't come up with a good other idea for this. For consistency it should be "Plugin %s wakes up in %ld minutes, restart anyway?", but thats way too long to fit into the status bar. The alternative would be to drop the plugin name again.
My vote goes to dropping the plugin name as it doesn't provide (imho) any valuable information for the user. Do we really need to know that a femon or relay plugin is about to wakeup in ten minutes, when we are restarting the VDR? I'd say: no.
Well, then the name of the plugin should be written to the log, for troubleshooting. Or is it necessary to say "Plugin %s wakes up"? Would it be enough to say "%s wakes up"? I'd guess that many plugin names are shorter than the translation of "Plugin" in many languages. Hmm, many languages don't seem to translate the word "Plugin", but the Estonian and Finnish translations are among the longest ones.
Marko
Marko Mäkelä wrote:
On Tue, Feb 20, 2007 at 08:52:20AM +0200, Rolf Ahrenberg wrote:
On Mon, 19 Feb 2007, Udo Richter wrote:
Rolf Ahrenberg wrote:
I've one question about this sentence: "Plugin %s wakes up in %ld min, continue?"
If I'm pressing 'OK' here, does it continue the shutdown or running the VDR?
I don't like it either, but didn't come up with a good other idea for this. For consistency it should be "Plugin %s wakes up in %ld minutes, restart anyway?", but thats way too long to fit into the status bar. The alternative would be to drop the plugin name again.
My vote goes to dropping the plugin name as it doesn't provide (imho) any valuable information for the user. Do we really need to know that a femon or relay plugin is about to wakeup in ten minutes, when we are restarting the VDR? I'd say: no.
Well, then the name of the plugin should be written to the log, for troubleshooting. Or is it necessary to say "Plugin %s wakes up"? Would it be enough to say "%s wakes up"? I'd guess that many plugin names are shorter than the translation of "Plugin" in many languages. Hmm, many languages don't seem to translate the word "Plugin", but the Estonian and Finnish translations are among the longest ones.
It's better to see which plugin is wanting to prevent the operation than simply something is preventing. The word 'Plugin' on the other hand is unnecessary, IMO.
Br, Pasi
On 2/20/07, Marko Mäkelä marko.makela@hut.fi wrote:
Would it be enough to say "%s wakes up"?
That's fine if you don't mind using poor grammar. For example, "femon wakes up?" makes absolutely no sense.
On Tue, Feb 20, 2007 at 08:36:49AM -0800, VDR User wrote:
On 2/20/07, Marko Mäkelä marko.makela@hut.fi wrote:
Would it be enough to say "%s wakes up"?
That's fine if you don't mind using poor grammar. For example, "femon wakes up?" makes absolutely no sense.
All languages I know allow a proper name as a subject. For example, "vdr wakes up" makes as much sense as "femon wakes up". Okay, proper names are usually spelled with a capital letter, and acronyms are often all-caps. (To my understanding, femon stands for "front-end monitor".)
Marko
Udo Richter wrote:
I've finished a fourth version of the shutdown rewrite. Again there are two patches available, one for VDR 1.5.0, and one with slight changes for 1.4.x.
Changes:
- Handle setup menu restart questions in cShutdown::ConfirmRestart()
- Act differently on SIGHUP: Restart VDR like on setup menu restart, but dont ask questions.
Well, that was the intention. Next time I'll do it, promise! ;)
The attached patch fixes this and actually calls ConfirmRestart, not ConfirmShutdown.
Beside that, things are getting close to land in VDR 1.5.x, so any last minute bug hunting is welcome.
Cheers,
Udo
--- vdr.c.old 2007-02-24 22:36:26.707746080 +0100 +++ vdr.c 2007-02-24 22:38:21.012241392 +0100 @@ -1169,7 +1169,7 @@ if (LastSignal == SIGHUP) { LastSignal = 0; // Confirm for any activity that blocks a restart - if (!Shutdown.ConfirmShutdown(true)) + if (!Shutdown.ConfirmRestart(true)) // Not confirmed, cancel. break;
--- menu.c.old 2007-02-24 22:36:23.037304072 +0100 +++ menu.c 2007-02-24 22:38:15.016152936 +0100 @@ -2726,7 +2726,7 @@ return osContinue;
// Confirm for any activity that blocks a restart - if (!Shutdown.ConfirmShutdown(true)) + if (!Shutdown.ConfirmRestart(true)) // Not confirmed, cancel. return osContinue;
Hi list,
Now that VDR 1.5.1 was published, I've also published the final 1.0 version of the shutdown rewrite. The changes since 0.4 are mainly by Klaus.
http://www.udo-richter.de/vdr/patches.html#shutdown http://www.udo-richter.de/vdr/patches.en.html#shutdown
The patch is identical to the changes of VDR 1.5.1, except that no functions were dropped, for compatibility. Also, the detection define is present, and should be used like this:
#if VDRVERSNUM >= 10501 || (defined(PATCH_SHUTDOWN_REWRITE) && PATCH_SHUTDOWN_REWRITE >= 100) ... #else ... #endif
Changes: - Identifiers changed: cShutdown -> cShutdownHandler Shutdown -> ShutdownHandler
- cRemote::LastActivity() now returns an absolute time, not a relative!
- Dropped cThread::EmergencyExit (still present in this patch for compatibility)
- Rearranged signal handling, report all signals instantly to syslog
- ISREALKEY macro to check whether a key is user-generated
- Some new timeout constants in vdr.c
- Updated man page regarding SIGHUP
- Coding style rewrite by Klaus, slight changes in documentation, comments and i18n strings
Cheers,
Udo
On Mon, Feb 26, 2007 at 09:29:58PM +0100, Udo Richter wrote:
Hi list,
Now that VDR 1.5.1 was published, I've also published the final 1.0 version of the shutdown rewrite. The changes since 0.4 are mainly by Klaus.
http://www.udo-richter.de/vdr/patches.html#shutdown http://www.udo-richter.de/vdr/patches.en.html#shutdown
The patch is identical to the changes of VDR 1.5.1, except that no functions were dropped, for compatibility.
Sorry, I forgot one feature request. In a private discussion with Klaus a long time ago (around vdr 1.3.30), Klaus mentioned the idea of VDR remembering the name of the last replayed recording across shutdowns. That is, you could press Play to resume whatever you were watching before powering off VDR. This would be similar to analog VCRs, which obviously remember the position even after being unplugged.
Marko
Marko Mäkelä wrote:
On Mon, Feb 26, 2007 at 09:29:58PM +0100, Udo Richter wrote:
Hi list,
Now that VDR 1.5.1 was published, I've also published the final 1.0 version of the shutdown rewrite. The changes since 0.4 are mainly by Klaus.
http://www.udo-richter.de/vdr/patches.html#shutdown http://www.udo-richter.de/vdr/patches.en.html#shutdown
The patch is identical to the changes of VDR 1.5.1, except that no functions were dropped, for compatibility.
Sorry, I forgot one feature request. In a private discussion with Klaus a long time ago (around vdr 1.3.30), Klaus mentioned the idea of VDR remembering the name of the last replayed recording across shutdowns. That is, you could press Play to resume whatever you were watching before powering off VDR. This would be similar to analog VCRs, which obviously remember the position even after being unplugged.
This has nothing to do with the actual shutdown stuff. VDR just needs to store this information in its setup.conf.
Klaus
On Sat, Mar 03, 2007 at 04:36:03PM +0100, Klaus Schmidinger wrote:
Sorry, I forgot one feature request. In a private discussion with Klaus a long time ago (around vdr 1.3.30), Klaus mentioned the idea of VDR remembering the name of the last replayed recording across shutdowns. That is, you could press Play to resume whatever you were watching before powering off VDR. This would be similar to analog VCRs, which obviously remember the position even after being unplugged.
This has nothing to do with the actual shutdown stuff. VDR just needs to store this information in its setup.conf.
Well, in a sense it has something to do with shutdown, because if VDR were never restarted, storing the information in setup.conf would be useless. I hope that you wrote this down on your secret TODO list. :-)
Marko
On 2/27/07, Marko Mäkelä marko.makela@hut.fi wrote:
This would be similar to analog VCRs, which obviously remember the position even after being unplugged.
VCR's don't remember anything related to position, it's the tape itself that moves (from one reel to the other), not the head in the VCR. ;)
Hi list,
In the 'final' 1.0 version of the shutdown patch, and in VDR 1.5.1, a small bug slipped through that prevented automatic shutdown after VDR started for a recording only.
I've uploaded a new 1.1 version of the patches for VDR 1.4.5, VDR 1.5.0 and VDR 1.5.1 to my web page:
http://www.udo-richter.de/vdr/patches.html#shutdown http://www.udo-richter.de/vdr/patches.en.html#shutdown
The minimal patch for 1.5.1 should also work on the shutdown-1.0-patched VDR 1.4.5/1.5.0 versions, and doesn't require plugins to be recompiled.
Cheers,
Udo
-
Andre.Weidemann＠web.de -
Christian Wieninger -
Darren Salt -
Helmut Auer -
Joachim Wilke -
joscej＠netscape.net -
Klaus Schmidinger -
Marko Mäkelä -
Matthias Schwarzott -
Pasi Juppo -
Patrick Mackin -
Peter Dittmann -
Reinhard Nissl -
Reinhard Walter Buchner -
Rolf Ahrenberg -
Teemu Suikki -
Tony Houghton -
Udo Richter -
VDR User -
Ville Skyttä