suggestion for shutdown-handling

  Hello,

I hope it's OK to post this kind of things (it's my first post here).

First I thought about a plugin, which handles all the shutdown-questions, 
which are spread around in various shutdown-scripts and extensions.
... but a (normal) plugin is not able to prevent vdr from shutdown.

Patching vdr is one point, but on the other side I read a statement from 
LinVDR, that they won't use patched VDR (which is quite ok from my point of 
view).

As I'm a fan of LinVDR, I looked for a way of doing it right.
AFAIK there are 2 possibilities:
1. change the interface of plugin- and pluginmanager-class
2. add a new mode of operation to vdr.

I think the first point was already discussed in the past, so I looked on how 
to solve the second.
The vdr could distinguish between LiveTV (usage as settop-box) and 
recording-mode (usage as a video-recorder).
In settop-box-mode the user has to care about power-on and power-off - in 
video-recorder-mode it's up to the vdr to care about power-state. 

The state could be implemented this way (diff -Naur vdr.org.c vdr.c):
* * * * * * * start of diff * * * * * *
anyway?")))
                              ForceShutdown = true;
@@ -1047,7 +1052,7 @@
                  Skins.Message(mtInfo, tr("Editing process finished"));
               }
            }
-        if (!Interact && ((!cRecordControls::Active() && !cCutter::Active() 
&& (!Interface->HasSVDRPConnection() || UserShutdown)) || ForceShutdown)) {
+        if (!LiveTvMode && !Interact && ((!cRecordControls::Active() 
&& !cCutter::Active() && (!Interface->HasSVDRPConnection() || UserShutdown)) 
|| ForceShutdown)) {
            time_t Now = time(NULL);
            if (Now - LastActivity > ACTIVITYTIMEOUT) {
               // Shutdown:
@@ -1060,6 +1065,7 @@
                        // Apparently the user started VDR manually
                        dsyslog("assuming manual start of VDR");
                        LastActivity = Now;
+                       LiveTvMode = true;
                        continue; // don't run into the actual shutdown 
procedure below
                        }
                     else
* * * * * * * end of diff * * * * * *

To suport plugins changing the operating mode, the var LiveTvMode could be 
made static with provided setter and getter.
So the plugins could change the mode and the user is stil able to overwrite 
the mode and shutdown the vdr immediatelly.

Having a toggle entry in the OSD-menu, the user could also switch to 
LiveTvMode in case that the vdr has been started for a recording event.

Please let me know, what you (especially Klaus) are think about this 
suggestion.

Kind regards

geronimo
  

Hello,

> 
> I hope it's OK to post this kind of things (it's my first post here).
> ...
> To suport plugins changing the operating mode, the var LiveTvMode could be 
> made static with provided setter and getter.
> So the plugins could change the mode and the user is stil able to overwrite 
> the mode and shutdown the vdr immediatelly.
> 
> Having a toggle entry in the OSD-menu, the user could also switch to 
> LiveTvMode in case that the vdr has been started for a recording event.
> 
> Please let me know, what you (especially Klaus) are think about this 
> suggestion.
> 
Generally I like your idea :)
But I would prefer to give the cPlugin Class a Busy member ( which returns false by default and could be changed by the 
plugin ) and vdr asks all plugins if they are busy and if any of these is busy the user must confirm the shutdown.
  

Am Donnerstag, 2. März 2006 09:11 schrieb Helmut Auer:
> Hello,
>
> > I hope it's OK to post this kind of things (it's my first post here).
> > ...
> > To suport plugins changing the operating mode, the var LiveTvMode could
> > be made static with provided setter and getter.
> > So the plugins could change the mode and the user is stil able to
> > overwrite the mode and shutdown the vdr immediatelly.
> >
> > Having a toggle entry in the OSD-menu, the user could also switch to
> > LiveTvMode in case that the vdr has been started for a recording event.
> >
> > Please let me know, what you (especially Klaus) are think about this
> > suggestion.
>
> Generally I like your idea :)
> But I would prefer to give the cPlugin Class a Busy member ( which returns
> false by default and could be changed by the plugin ) and vdr asks all
> plugins if they are busy and if any of these is busy the user must confirm
> the shutdown.

Well, that was my first thought - and there already exists patches to do 
exactly this. Then I heard, that that kind of extension was undesired in the 
vdr.

May be, because a buggy plugin could prevent the vdr from shutdown?
Using the mode of operation, a plugin could query and change the state, but 
the vdr stays beeing the master and could overwrite the mode of operation at 
any time.

Hope I understood the things right.
  

Hi

>> Generally I like your idea :)
>> But I would prefer to give the cPlugin Class a Busy member ( which returns
>> false by default and could be changed by the plugin ) and vdr asks all
>> plugins if they are busy and if any of these is busy the user must confirm
>> the shutdown.
> 
> Well, that was my first thought - and there already exists patches to do 
> exactly this. Then I heard, that that kind of extension was undesired in the 
> vdr.
> 
> May be, because a buggy plugin could prevent the vdr from shutdown?
> Using the mode of operation, a plugin could query and change the state, but 
> the vdr stays beeing the master and could overwrite the mode of operation at 
> any time.
> 
> Hope I understood the things right.
> 
VDR is always the master :-) There is no big difference between both "solutions".
In both cases vdr will shutdown if the user confirms it.
  

On Thu, Mar 02, 2006 at 08:49:52AM +0100, geronimo wrote:
> Patching vdr is one point, but on the other side I read a statement from 
> LinVDR, that they won't use patched VDR (which is quite ok from my point of 
> view).
> 
> As I'm a fan of LinVDR, I looked for a way of doing it right.
> AFAIK there are 2 possibilities:
> 1. change the interface of plugin- and pluginmanager-class
> 2. add a new mode of operation to vdr.
> 
> I think the first point was already discussed in the past, so I looked on how 
> to solve the second.
> The vdr could distinguish between LiveTV (usage as settop-box) and 
> recording-mode (usage as a video-recorder).
> In settop-box-mode the user has to care about power-on and power-off - in 
> video-recorder-mode it's up to the vdr to care about power-state. 

My vdr-suspend patch does exactly this.  The mode variable is Setup.Suspend,
and it can be read from the configuration file.  The mode is switched by
pressing the Power button.  After a short timeout, the system will shut down,
unless it is busy with something else (such as recording or cutting).  I've
used the system since last September, and it works well in our family.

My vdr-relay plugin (for powering the screen on or off) has an option for
setting the initial suspend status.  Thus, when the system is started by
remote control (my own design for the Hauppauge Nova-T PCI 90002), the
screen will power on.  Otherwise (start by wake-on-LAN or nvram-wakeup)
the screen will remain off and playback will be suspended.

References:

http://www.iki.fi/~msmakela/software/vdr/#suspend
http://www.iki.fi/~msmakela/software/vdr/#relay
http://www.iki.fi/~msmakela/electronics/worc5/
http://www.iki.fi/~msmakela/electronics/relay/

	Marko
  

geronimo wrote:
> Hello,
> 
> I hope it's OK to post this kind of things (it's my first post here).

Typical beginners mistake: you have replied to an exiting post
instead of starting a new thread.

Regarding shutdown: no more changes before version 1.4.

Klaus
  

Klaus Schmidinger wrote:
> geronimo wrote:
> > Hello,
> >
> > I hope it's OK to post this kind of things (it's my first post here).
>
> Typical beginners mistake: you have replied to an exiting post
> instead of starting a new thread.

Could you please extend your corrections?
- what was (respect to the technical format) wrong with my first mail?

- my question did not focus the technical format but the ideally format / 
permission.

> Regarding shutdown: no more changes before version 1.4.

I did not mention any version or roadmap.
I just asked for (especially) your opinion.

kind regards

geronimo
  

> >
> > Hope I understood the things right.
>
> VDR is always the master :-) There is no big difference between both
> "solutions". In both cases vdr will shutdown if the user confirms it.

well, if you look at the existing patches (ok, the one's I know about) 
focussing this item the vdr has no chance of staying the master.
  

geronimo wrote:
> Klaus Schmidinger wrote:
> 
>>geronimo wrote:
>>
>>>Hello,
>>>
>>>I hope it's OK to post this kind of things (it's my first post here).
>>
>>Typical beginners mistake: you have replied to an exiting post
>>instead of starting a new thread.
> 
> 
> Could you please extend your corrections?
> - what was (respect to the technical format) wrong with my first mail?

You should have started a new message, instead of replying
to an existing one. Now I ahve one thread with two mingled
subjects in my inbox.

> - my question did not focus the technical format but the ideally format / 
> permission.
> 
> 
>>Regarding shutdown: no more changes before version 1.4.
> 
> 
> I did not mention any version or roadmap.
> I just asked for (especially) your opinion.

I am currently in the process of making a stable version 1.4,
so I just don't have the time to get involved in such discussions.
I just thought I'd let you know that I won't make any changes in that
area before version 1.4. After that, we can talk about this.

Klaus
  

On Thu, 2006-03-02 at 10:26 +0100, geronimo wrote:
> - what was (respect to the technical format) wrong with my first mail?

When you click reply-to in your mailer, it inserts a reference to the
email you're replying to (even when you write a new subject), like:

In-Reply-To: <4405A414.5050802@gmx.de>

So the mail will be part of the existing thread. This is bad mailing
list etiquette.
  

> You should have started a new message, instead of replying
> to an existing one. Now I ahve one thread with two mingled
> subjects in my inbox.

Sorry for that - but where is the thread identifier?
I changed the subject.
... or is "[vdr]" your thread-id?
If so, I beg your pardon, as I thought it was a ML-Id.

>
> > - my question did not focus the technical format but the ideally format /
> > permission.
> >
> >>Regarding shutdown: no more changes before version 1.4.
> >
> > I did not mention any version or roadmap.
> > I just asked for (especially) your opinion.
>
> I am currently in the process of making a stable version 1.4,
> so I just don't have the time to get involved in such discussions.
> I just thought I'd let you know that I won't make any changes in that
> area before version 1.4. After that, we can talk about this.

Sorry for disturbing!



kind regards

geronimo
  

Torgeir Veimo wrote:
> On Thu, 2006-03-02 at 10:26 +0100, geronimo wrote:
> > - what was (respect to the technical format) wrong with my first mail?
>
> When you click reply-to in your mailer, it inserts a reference to the
> email you're replying to (even when you write a new subject), like:
>
> In-Reply-To: <4405A414.5050802@gmx.de>
>
> So the mail will be part of the existing thread. This is bad mailing
> list etiquette.

Thank you very much for the background information.
and Sorry too all.
  

> > 
> >>Regarding shutdown: no more changes before version 1.4.
> 
> I am currently in the process of making a stable version 1.4,
> so I just don't have the time to get involved in such discussions.
> I just thought I'd let you know that I won't make any changes in that
> area before version 1.4. After that, we can talk about this.
> 
> Klaus

For 1.4 I would suggest to include the vdr-inactivity patch that comes 
with the burn plugin.
It implements a method into cPlugin class to allow a plugin to block 
shutdown.
It's working similar like a pending cutting thread.
However vdr is still master and can overrule it by acknoledging the 
shutdown.

I wonder why this has not being adopted because it's a sensible and 
neccessary addition for all plugins doing a little longer jobs (like burn, 
vdrconvert-plugin, epg-plugins).
Currently the cPlugin interface is missing such a generic interface and 
VDR is not aware of pending activities of a plugin.

kind regards  Peter
  

Peter Dittmann schrieb:
> 
> 
>  > >
>  > >>Regarding shutdown: no more changes before version 1.4.
>  >
>  > I am currently in the process of making a stable version 1.4,
>  > so I just don't have the time to get involved in such discussions.
>  > I just thought I'd let you know that I won't make any changes in that
>  > area before version 1.4. After that, we can talk about this.
>  >
>  > Klaus
> 
> For 1.4 I would suggest to include the vdr-inactivity patch that comes 
> with the burn plugin.
> It implements a method into cPlugin class to allow a plugin to block 
> shutdown.
> It's working similar like a pending cutting thread.
> However vdr is still master and can overrule it by acknoledging the 
> shutdown.
> 
> I wonder why this has not being adopted because it's a sensible and 
> neccessary addition for all plugins doing a little longer jobs (like 
> burn, vdrconvert-plugin, epg-plugins).
> Currently the cPlugin interface is missing such a generic interface and 
> VDR is not aware of pending activities of a plugin.
> 
> kind regards  Peter
> 
Nice Patch - it does exactly what I meant :)
  

geronimo wrote:
>>You should have started a new message, instead of replying
>>to an existing one. Now I ahve one thread with two mingled
>>subjects in my inbox.
> 
> 
> Sorry for that - but where is the thread identifier?
> I changed the subject.
> ... or is "[vdr]" your thread-id?
> If so, I beg your pardon, as I thought it was a ML-Id.
> 

Thread is identified by the "References:" header which is automatically
added by your email client when you hit "reply".
  

Anssi Hannula wrote:
> geronimo wrote:
> 
>>>You should have started a new message, instead of replying
>>>to an existing one. Now I ahve one thread with two mingled
>>>subjects in my inbox.
>>
>>
>>Sorry for that - but where is the thread identifier?
>>I changed the subject.
>>... or is "[vdr]" your thread-id?
>>If so, I beg your pardon, as I thought it was a ML-Id.
>>
> 
> Thread is identified by the "References:" header which is automatically
> added by your email client when you hit "reply".
> 

Ah, never mind, I was wrong. As Torgeir said, it is identified by
"In-Reply-To:".
  

> The vdr could distinguish between LiveTV (usage as settop-box) and 
> recording-mode (usage as a video-recorder).
> In settop-box-mode the user has to care about power-on and power-off - in 
> video-recorder-mode it's up to the vdr to care about power-state. 

I'm not sure how this actually solves the background activity issue. 
There already is a distinction between interactive mode and automatic 
mode, based on LastActivity. And giving plugins full access to it would 
result in conflicts if several plugins start messing with it.


Some general thoughts on shutdown management:

There are three different groups involved in shutdown management: First, 
the interactive user. Second, plugins that do background tasks. And 
third, external scripts that do other work.

Interactive use is handled quite well by the LastActivity concept. 
Plugin activity is currently hard to realize, though not impossible. 
(variant 1: send fake key presses, variant 2: rely on external scripts 
that cancel shutdown.) External script activity is possible, but could 
be improved.

For external scripts, I would suggest a method similar to LastActivity: 
Allow scripts to set an inactivity timer via SVDRP, "I'm busy right now, 
ask again in x minutes", with the possibility to announce "I'm done now, 
go ahead if there's no user activity". The important point is that this 
shouldn't mess with LastActivity, but with some other timeout variable, 
so LastActivity really represents user activity.
This could also be accompanied by a variant of the -s shutdown script, 
that actually queries for activity before asking the user.
As typical for external scripts, if there's more than one script out 
there, they have to somehow work together as one.

For internal use, a callback method is probably the best way to handle 
it. A LastActivity-like timeout would require a separate timeout for 
each background activity, and a callback method isn't that much overhead.
But instead of extending the plugin interface, I would suggest some 
cShutdownControl class independent of the plugin interface, with 
cShutdownControl::Active() callback. This could be as simple as 
inheriting this class into a cThread, and the default callback would 
cancel all shutdowns. (unless forced by user.)
This could even be used by recordings, cutter and SVDRP connection for 
further cleanup.

Of course thats just thoughts how this could be handled, and I don't 
expect anything before 1.5.

Cheers,

Udo