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
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.
vdr mailing list