On Wed, Sep 14, 2005 at 12:11:44AM +0300, Marko Mäkelä wrote:

Based on some helpful feedback from Klaus, I simplified my suspend patch.

Today, the patch grew by the added virtual method cStatus::SetSuspend(bool) for notifying plugins.

The interface to the solid-state relay will be moved to a separate plugin. There are so many ways to control relays from a PC that it is best to write plugins for relay interfaces as the need arises.

I am planning to write a plugin for controlling my solid-state relay in a few days, now that plugins can be efficiently notified of changes in the playback suspension status.

The patch introduces three config.h variables, which are 0 by default, and exposed in the Setup/Miscellanous panel:

PowerSuspend: 1=enable the Power button control the Suspend flag, 0=normal Suspend: 1=suspend audio and video playback, 0=normal SuspendShutdownWait: After playback was suspended by pressing the Power button, wait this many seconds until shutting down vdr. This feature is disabled if SuspendShutdownWait=0 or PowerSuspend=0 or no -s option is given to vdr.

When compiling, be sure to pass SUSPEND_PATCH=1 to make.

The current version of the patch is available at: http://www.funet.fi/~msmakela/software/vdr/vdr-1.3.32-suspend-0.4.patch.gz

I do not expect this patch to change any more, except to fix any merge conflicts with subsequent releases of vdr.

Translation strings for i18n.c and success reports from users of full-featured cards are appreciated.

Marko

Marko Mäkelä wrote:

I had to remove the #ifdef SUSPEND_PATCH tests in order to avoid breaking binary compatibility with plugins. (Plugins will not inherit $(CFLAGS) or $(DEFINES) from the main vdr Makefile.)

They will inherit them, if you put the DEFINES += lines directly into Make.config. Its not enough to do the DEFINES part conditionally in the VDR makefile, as there is no 'global makefile' part in there that would be executed for plugins. Its also not recommended to give DEFINES+= on command line, because this will override all other default defines in the makefile. (though it will be passed to sub-makes)

Cheers,

Udo

On Sat, Sep 17, 2005 at 09:37:48PM +0200, Jan Wagner wrote:

...

Translation strings for i18n.c and success reports from users of full-featured cards are appreciated.

Hi there,

just tried the 0.4.1 patch on my full featured card and well besides toggling the setup.suspended nothing happens at all.

Thank you for testing the patch! Could you elaborate a little, please? Did you toggle the flag by pressing the Power key (after setting PowerSuspend=yes in Setup/Miscellanous), or did you toggle the flag directly in the Setup/Miscellanous screen?

Note that in the Setup/Miscellanous screen, the change does not take effect immediately, but only after you have confirmed the settings by pressing the OK button.

I would expect the suspend flag to work when viewing recordings. Did you test it? The picture should freeze, like in pause mode, and maybe go black after a while, in case the firmware on your card features some "end of stream timeout", like the vdr-softdevice plugin does.

I am not sure how full-featured cards handle live playback (transfer mode). If the live MPEG stream is not routed via cDevice::Action() and cTransfer, I'm afraid that suspending live playback on full-featured cards is beyond my skills.

BTW: Wouldn't your relay plugin be even better if it could call an external script

Yes. Good idea.

Marko

On Sun, Sep 18, 2005 at 08:54:15AM +0200, Jan Wagner wrote:

Sure. I tested i live mode. Whenever I pressed Power the syslog said "power button pressed". But the picture did not freeze or anything. When I looked in Setup.Misc.Suspended it was toggled, means set to yes. When I repeated pressing the power button it toggled back to no.

It looks like your card decodes live video completely independent of VDR. Thus, my patch might only be beneficial to softdevice or perhaps dxr3 users. (I don't know if the power consumption and heat dissipation of the dxr3 depends on whether it is decoding anything.)

...

I would expect the suspend flag to work when viewing recordings. Did you test it? The picture should freeze, like in pause mode, and maybe go black after a while, in case the firmware on your card features some "end of stream timeout", like the vdr-softdevice plugin does.

Just tested that. After a few seconds the picture freezes when replaying a recording. You can still use the OSD though. So you can press OK and the status window just pops up. When I press power again, the Recording starts playing again.

This is how it was designed to work. It might not be the most intuitive way, but with my limited knowledge of vdr internals I couldn't come up with anything better. At the very least, the picture should really be blanked, because it will just freeze on full-featured cards and dxr3. Softdevice will freeze the picture practically immediately and blank the screen in a few seconds, but OSD will still work.

I understand very well why my patch cannot be incorporated in the stable 1.4 series. I hope that a better solution can be developed for vdr 1.5.

Marko

On Sat, Oct 08, 2005 at 12:44:26PM +0300, Seppo Ingalsuo wrote:

I have earlier used pausing a recording for suspension and the pause sign in OSD gives good indication about vdr state. Would it be possible to optionally display a "Suspended" message in OSD when in suspended mode? It would help my family members using vdr to notice that home AV routings are setup correctly and vdr video & audio just needs to be activated by pressing power key from remote.

I will think about that. It is not straightforward, because the suspension works at a very low level, completely independently of the high-level player functions. (Can you say 'hack'?)

The "Suspended" message would have to change location every few seconds, in order to avoid burning the message on the screen. I'm afraid I have no idea how to do this in vdr.

With softdevice & x11 it could be also feasible to allow xscreensaver to handle the screen when entering suspended mode and vice versa when leaving suspension but that would probably need to go to softdevice x11 plugin internals.

Yes, that definitely is in the domain of softdevice.

What could be done relatively easily is a patch to softdevice that would listen to cStatus::SetSuspended() and activate or deactivate the screensaver accordingly.

Marko