don't let mms do a shutdown if vdr is recording

Moderator: Moderator

gda
Posts: 10
Joined: Fri Nov 02, 2007 11:35 am

don't let mms do a shutdown if vdr is recording

Postby gda » Thu Jan 31, 2008 11:41 pm

Hi,

I want to use mms as frontend with vdr in the background and vdr-sxfe as
tv app. I want that quitting mms will shutdown the computer. No problem
so far, but if the vdr is currently recording, this would be a bad thing.
At the end of this post you can find a patch for mms that let mms start
a script that could check what the vdr or other tasks are currently doing.
It is expected that this script would return "OK" if the shutdown could
proceed, or a text that gets displayed in a new dialog, and the user
gets another chance to think whether he really wants a shutdown.
If this patch will go into mms, then I will post a shell script that would
do the check with vdr. Tell me your opinion.

Gerald


Code: Select all

diff -Nur mms_1.1.0~rc1+bzr1369.orig/cfg/Config-dvb mms-1.1.0~rc1+bzr1369/cfg/Config-dvb
--- mms_1.1.0~rc1+bzr1369.orig/cfg/Config-dvb   2008-01-19 17:08:37.000000000 +0100
+++ mms-1.1.0~rc1+bzr1369/cfg/Config-dvb   2008-01-31 20:40:59.000000000 +0100
@@ -35,6 +35,16 @@
 #
 show_quit = true
 
+# Shutdown_hook_script
+#
+# Command that checks whether a shutdown is safe now.
+# It has to send OK to standard output if there will be no problem,
+# or the reason why it shouldn't be done currently.
+# The user will be prompted with this reason, and is able to force
+# the shutdown, or can cancel it.
+#
+shutdown_hook_script =
+
 # Shutdown_script
 #
 # Command to run when mms is shutting down.
diff -Nur mms_1.1.0~rc1+bzr1369.orig/cfg/Config-dxr3 mms-1.1.0~rc1+bzr1369/cfg/Config-dxr3
--- mms_1.1.0~rc1+bzr1369.orig/cfg/Config-dxr3   2008-01-19 17:08:37.000000000 +0100
+++ mms-1.1.0~rc1+bzr1369/cfg/Config-dxr3   2008-01-31 20:40:59.000000000 +0100
@@ -35,6 +35,16 @@
 #
 show_quit = true
 
+# Shutdown_hook_script
+#
+# Command that checks whether a shutdown is safe now.
+# It has to send OK to standard output if there will be no problem,
+# or the reason why it shouldn't be done currently.
+# The user will be prompted with this reason, and is able to force
+# the shutdown, or can cancel it.
+#
+shutdown_hook_script =
+
 # Shutdown_script
 #
 # Command to run when mms is shutting down.
diff -Nur mms_1.1.0~rc1+bzr1369.orig/cfg/Config-opengl mms-1.1.0~rc1+bzr1369/cfg/Config-opengl
--- mms_1.1.0~rc1+bzr1369.orig/cfg/Config-opengl   2008-01-19 17:08:37.000000000 +0100
+++ mms-1.1.0~rc1+bzr1369/cfg/Config-opengl   2008-01-31 20:40:59.000000000 +0100
@@ -35,6 +35,16 @@
 #
 show_quit = true
 
+# Shutdown_hook_script
+#
+# Command that checks whether a shutdown is safe now.
+# It has to send OK to standard output if there will be no problem,
+# or the reason why it shouldn't be done currently.
+# The user will be prompted with this reason, and is able to force
+# the shutdown, or can cancel it.
+#
+shutdown_hook_script =
+
 # Shutdown_script
 #
 # Command to run when mms is shutting down.
diff -Nur mms_1.1.0~rc1+bzr1369.orig/cfg/Config-sdl mms-1.1.0~rc1+bzr1369/cfg/Config-sdl
--- mms_1.1.0~rc1+bzr1369.orig/cfg/Config-sdl   2008-01-19 17:08:37.000000000 +0100
+++ mms-1.1.0~rc1+bzr1369/cfg/Config-sdl   2008-01-31 20:40:59.000000000 +0100
@@ -35,6 +35,16 @@
 #
 show_quit = true
 
+# Shutdown_hook_script
+#
+# Command that checks whether a shutdown is safe now.
+# It has to send OK to standard output if there will be no problem,
+# or the reason why it shouldn't be done currently.
+# The user will be prompted with this reason, and is able to force
+# the shutdown, or can cancel it.
+#
+shutdown_hook_script =
+
 # Shutdown_script
 #
 # Command to run when mms is shutting down.
diff -Nur mms_1.1.0~rc1+bzr1369.orig/my_config_parameters mms-1.1.0~rc1+bzr1369/my_config_parameters
--- mms_1.1.0~rc1+bzr1369.orig/my_config_parameters   2008-01-19 17:08:37.000000000 +0100
+++ mms-1.1.0~rc1+bzr1369/my_config_parameters   2008-01-31 20:41:23.000000000 +0100
@@ -51,6 +51,7 @@
 PARAMETER_NUM("jump",          jump,               10)
 PARAMETER_NUM("idle_time",          idle_time,            1)
 PARAMETER_BOOL("show_quit",      show_quit,          true)
+PARAMETER_STR("shutdown_hook_script",   shutdown_hook_script,    "")
 PARAMETER_STR("shutdown_script",   shutdown_script,    "")
 PARAMETER_NUM("debug_level",      debug_level,          2)
 PARAMETER_BOOL("media",         media,          true)
diff -Nur mms_1.1.0~rc1+bzr1369.orig/startmenu.cpp mms-1.1.0~rc1+bzr1369/startmenu.cpp
--- mms_1.1.0~rc1+bzr1369.orig/startmenu.cpp   2008-01-19 17:08:37.000000000 +0100
+++ mms-1.1.0~rc1+bzr1369/startmenu.cpp   2008-01-31 23:46:50.000000000 +0100
@@ -33,6 +33,10 @@
 
 #include <iostream>
 
+// shutdown hook
+#include <stdio.h>
+#include <unistd.h>
+
 using std::list;
 using std::string;
 using std::vector;
@@ -384,8 +388,47 @@
   if (ret == 0 && conf->p_show_quit()) {
     conf->s_shutdown_script("");
     exit_loop = true;
-  } else if (!conf->p_shutdown_script().empty() && (ret == 1 && conf->p_show_quit() || ret == 0 && !conf->p_show_quit()))
+  }
+  else if (!conf->p_shutdown_script().empty() && (ret == 1 && conf->p_show_quit() || ret == 0 && !conf->p_show_quit()))
+  {
     exit_loop = true;
+
+    // if there is a shutdown hook script and we could start it
+    FILE *pipe = NULL;
+    if (!conf->p_shutdown_hook_script().empty() &&
+        file_exists(conf->p_shutdown_hook_script().c_str()) &&
+        ((pipe = popen(conf->p_shutdown_hook_script().c_str(), "r")) != NULL))
+    {
+      // not elegant, but simple, should be enough for everything
+      char buffer[1024] = "OK";
+      int readlen = 0;
+
+      while (!feof(pipe))
+      {
+        // lets see what the shutdown hook has to tell us
+        readlen += fread(&buffer[readlen], 1, sizeof(buffer) - readlen - 1, pipe);
+        buffer[readlen] = '\0';
+        if (readlen = sizeof(buffer) - 1)
+          break;
+      }
+      pclose(pipe);
+
+      // do we have a response different to okay?
+      if (strncmp(buffer, "OK", 2))
+      {
+   // we open a new menu with the response from the shutdown hook
+        ExtraMenu em(buffer);
+
+        // we ask whether the user still wants to shutdown
+        em.add_item(ExtraMenuItem(gettext("Halt System"), "", NULL));
+        em.add_item(ExtraMenuItem(gettext("Cancel"), "", NULL));
+
+        // he got cold feet, so we stop the shutdown process
+        if (em.mainloop() == 1)
+          exit_loop = false;
+      }
+    }
+  }
 }
 
 void Startmenu::generate_startmenu()

User avatar
Uatschitchun
Overlord
Posts: 3189
Joined: Tue Dec 06, 2005 6:55 pm
Location: Germany
Contact:

Postby Uatschitchun » Fri Feb 01, 2008 7:39 am

Hi ;)

Sorry, but I removed the voting.
I think we should see and collect opinions first.

In my opinion this is not a bad idea! The bad is, we would have 3 shutdown options with that patch (Quit, Shutdown, shutdown hook). That is surely 1 too much ...

As we have the shutdown script, this one here could replace that, right?

Does your patch could even fullfill that one:
http://mymediasystem.org/flyspray/?do=d ... ask_id=496
?

If we do a new/enhanced shutdown, we should think of the most complete solution.
Lg
Roman

gda
Posts: 10
Joined: Fri Nov 02, 2007 11:35 am

Postby gda » Fri Feb 01, 2008 8:41 am

Uatschitchun wrote:Hi ;)
In my opinion this is not a bad idea! The bad is, we would have 3 shutdown options with that patch (Quit, Shutdown, shutdown hook). That is surely 1 too much ...

Then set the show quit option in the config file to false and you will have
only shutdown and cancel.

Uatschitchun wrote:As we have the shutdown script, this one here could replace that, right?

No, the shutdown script gets called after the main loop has ended.
The shutdown hook script is called before the main loop has ended
to eventually prevent that the main loop will end and does not do the shutdown itself.

Uatschitchun wrote:Does your patch could even fullfill that one:
http://mymediasystem.org/flyspray/?do=d ... ask_id=496
?

The shutdown hook script doesn't do the shutdown, so it wouldn't be the right place for this.
Uatschitchun wrote:If we do a new/enhanced shutdown, we should think of the most complete solution.

My script is not the complete solution but it doesn't disturb developing it,
because it is completely independent.
I don't think that an at job is the right thing, it should be done by
a thread that get started by mms. This thread would start an inactivity
timer, and would ask the user whether he wants to stop an automatic
shutdown after the timer has elapsed. This timer gets reseted on every
user activity or even automatically if it is not the right time of day.

Gerald

gda
Posts: 10
Joined: Fri Nov 02, 2007 11:35 am

Postby gda » Fri Feb 01, 2008 8:48 am

gda wrote:
Uatschitchun wrote:Hi ;)
In my opinion this is not a bad idea! The bad is, we would have 3 shutdown options with that patch (Quit, Shutdown, shutdown hook). That is surely 1 too much ...

Then set the show quit option in the config file to false and you will have
only shutdown and cancel.

Sorry, I misunderstood you there, but no, we would have still only Quit and
Shutdown. Shutdown hook is not another way to end mms. It gives only an
additional information to the user that it might be a not so good idea to
insist on shuting down now.
Give it a try and you will see, or look at the source.

Gerald

gda
Posts: 10
Joined: Fri Nov 02, 2007 11:35 am

Postby gda » Fri Feb 01, 2008 10:55 am

gda wrote:I don't think that an at job is the right thing, it should be done by
a thread that get started by mms. This thread would start an inactivity
timer, and would ask the user whether he wants to stop an automatic
shutdown after the timer has elapsed. This timer gets reseted on every
user activity or even automatically if it is not the right time of day.


The code for the SSaverobj could be a good starting point for this.
I only don't understand the coding of the ThreadLoop. The code for case 1
is nearly identically to the code for the cases 2 to 20. Why not use an
if statement and share the code? The cases 2 to 20 point to the same
code, why not use a counter and just one case? I guess it is just
a personal coding style.

Gerald

lorenzodes
master
Posts: 772
Joined: Sun Mar 11, 2007 4:50 pm
Location: move.l 4.w,a6

Postby lorenzodes » Fri Feb 01, 2008 12:52 pm

gda wrote:The code for the SSaverobj could be a good starting point for this.I only don't understand the coding of the ThreadLoop. The code for case 1is nearly identically to the code for the cases 2 to 20. Why not use an
if statement and share the code? The cases 2 to 20 point to the same
code, why not use a counter and just one case? I guess it is just
a personal coding style.

Gerald



Nope, for case 1: and for case 2-20: code is pretty different. The case 2 to 20 might be simplified to have only 1 case, at the price of adding a counter, but that chosen approach doesn't affect the final code (see with objdump)... plus switch...case is faster than the if approach.
"I’m not frightened of dying, anytime will do, I don’t mind. Why should I be frightened of dying? There’s no reason for it, you gotta go sometime"

gda
Posts: 10
Joined: Fri Nov 02, 2007 11:35 am

Postby gda » Fri Feb 01, 2008 1:10 pm

lorenzodes wrote:
gda wrote:The code for the SSaverobj could be a good starting point for this.I only don't understand the coding of the ThreadLoop. The code for case 1is nearly identically to the code for the cases 2 to 20. Why not use an
if statement and share the code? The cases 2 to 20 point to the same
code, why not use a counter and just one case? I guess it is just
a personal coding style.

Gerald



Nope, for case 1: and for case 2-20: code is pretty different. The case 2 to 20 might be simplified to have only 1 case, at the price of adding a counter, but that chosen approach doesn't affect the final code (see with objdump).


It is anyway just a matter of personal style, it wasn't meant as critics.
But what do think about my addition to mms, and about to use something
like the screensaver code for automatic shutdown?

I know the code of mms only a little bit longer than 24 hours, I think
for you it would be much more easy to check whether this could be done.

Gerald

Lake-end
Posts: 42
Joined: Fri Nov 30, 2007 3:06 pm
Location: Tampere, Finland
Contact:

Postby Lake-end » Fri Feb 01, 2008 1:56 pm

Hi gda.
You can get past this by calling VDR shutdown script in MMS shutdown script. That way it really shutdowns if VDR is not recording.

VDR´s sources include script called svdrpsend.pl just use it to shutdown the computer.

Following command tells VDR that shutdown request was received, now if VDR is recording it asks if you "really wanna shutdown" and if it goes unanswered it will not actually shutdown. If it is not recording, VDRs own shutdown script gets executed and what it does is up to you.

Code: Select all

svdrpsend.pl HITK power


So basically remove shutting down from mms shutdown script, instead add "svdrpsend.pl HITK power" and let VDR decide wether to shut down or not.

lorenzodes
master
Posts: 772
Joined: Sun Mar 11, 2007 4:50 pm
Location: move.l 4.w,a6

Postby lorenzodes » Fri Feb 01, 2008 2:57 pm

gda wrote:But what do think about my addition to mms, and about to use something
like the screensaver code for automatic shutdown?

I know the code of mms only a little bit longer than 24 hours, I think
for you it would be much more easy to check whether this could be done.

Gerald


See if you can reuse code in ./plugins/feature/common-feature.cpp (the run::exclusive_external_program_pipe() API, for example).

You can also use one of the updaters for the "shutdown at" stuff.

Arj has the last word, especially now that 1.1.0 is "feature frozen".
"I’m not frightened of dying, anytime will do, I don’t mind. Why should I be frightened of dying? There’s no reason for it, you gotta go sometime"

gda
Posts: 10
Joined: Fri Nov 02, 2007 11:35 am

Postby gda » Fri Feb 01, 2008 3:39 pm

lorenzodes wrote:
gda wrote:But what do think about my addition to mms, and about to use something
like the screensaver code for automatic shutdown?

I know the code of mms only a little bit longer than 24 hours, I think
for you it would be much more easy to check whether this could be done.

Gerald


See if you can reuse code in ./plugins/feature/common-feature.cpp (the run::exclusive_external_program_pipe() API, for example).


I will do if I know that this extension will have a chance to go into mms.
I wouldn't like to do more work, if there is no interest in it.

Gerald

gda
Posts: 10
Joined: Fri Nov 02, 2007 11:35 am

Postby gda » Fri Feb 01, 2008 3:53 pm

lorenzodes wrote:See if you can reuse code in ./plugins/feature/common-feature.cpp (the run::exclusive_external_program_pipe() API, for example).

This API is inside a plugin, so I expect, I would have to put my code also into
a plugin, right?

Gerald

User avatar
Uatschitchun
Overlord
Posts: 3189
Joined: Tue Dec 06, 2005 6:55 pm
Location: Germany
Contact:

Postby Uatschitchun » Fri Feb 01, 2008 4:14 pm

gda wrote:I wouldn't like to do more work, if there is no interest in it.

I guess the interest in something like that is not the question, as a whole lotta VDR-users also use MMS ;)

I even don't want to ask for more work than what is needed ...

Main question is:
Wouldn't it be good to prepare MMS for such extensions in general?

We have quit and shutdown ... requested are delayed shutdown, inactivity shutdown and shutdown-hooks for to shutdown only if ...

So my aim was to see, instead of doing changes for one purpose only, if we could combine these related issues into one change that provides all this and fullfill future needs ;)
Lg

Roman

lorenzodes
master
Posts: 772
Joined: Sun Mar 11, 2007 4:50 pm
Location: move.l 4.w,a6

Postby lorenzodes » Fri Feb 01, 2008 4:19 pm

gda wrote:I will do if I know that this extension will have a chance to go into mms.
I wouldn't like to do more work, if there is no interest in it.

Gerald


There's interest in it :)

RC2 is about to be released and now the priority is fixing bugs. Mms is feature frozen now, but since it doesn't require much changes, IMHO such feature could be added. I haven't looked into your patch properly because I am not at home atm, but I will do later.

This being said, Anders has the last word.

p.s.: okie, after a second look. Why do you need the pipe stuff? Just run the program/script and check its exit code. The input pipe may come in handy if you want, for example, the script to pass a message to mms in order to display it.
Last edited by lorenzodes on Fri Feb 01, 2008 6:20 pm, edited 1 time in total.
"I’m not frightened of dying, anytime will do, I don’t mind. Why should I be frightened of dying? There’s no reason for it, you gotta go sometime"

User avatar
acmelabs
Overlord
Posts: 2365
Joined: Mon Feb 20, 2006 9:18 pm
Location: Germany
Contact:

Postby acmelabs » Fri Feb 01, 2008 6:16 pm

Hi, here are my 2¢...

I wish a better integration of VDR into MMS in general. These points come spontaneously into my mind:
  • your patch (shutdown impact)
  • set timers within MMS for VDR (with timer collision check)
  • jump from EPG onto selected VDR-channel
  • own plugin for timer management
    • show
    • edit
    • delete
So the problem I see is not only the feature freeze we have right now for RC2, but also how we gonna handle this as a whole.

How do you see your work yourself? Do you see yourself finish and happy with it, or do you think: OK, that's the first step, but we have quite a few steps in front of us.

But nevertheless no doubt about it, excellent work. A big up from me and keep going.

Regards,
Andreas

gda
Posts: 10
Joined: Fri Nov 02, 2007 11:35 am

Postby gda » Fri Feb 01, 2008 8:26 pm

acmelabs wrote:Hi, here are my 2¢...

I wish a better integration of VDR into MMS in general.
How do you see your work yourself? Do you see yourself finish and happy with it, or do you think: OK, that's the first step, but we have quite a few steps in front of us.


Of course it can be only a first step of an integration of VDR into MMS.
I see my work like it is: a quick (I did it last evening) and dirty hack.
It couldn't be better, because of my lack of knowledge of the mms
sources. I did only learn enough to find the right place to add it.
Nevertheless, it is the most important step for the VDR integration.
Letting MMS shutdown a recording VDR is an absolute show stopper!
The problem is that I can't promise to do the 2. step, that should be
to write a base class that wraps the communication versus the SVDRP
interface of the VDR, because I don't have enough time.

I am an old man with two small children, and so many open projects.
There is a vdr plugin to finish, the atmega microcontroller that will
drive the lcd display and the ir remote receiver of my VDR waits
for a program ...

Gerald


Return to “feature requests”

Who is online

Users browsing this forum: No registered users and 3 guests