Lucian Muresan wrote:

Hi,

I'd like to provide a patch for VDR but would like to expose the rough implementation idea and of course, the purpose, and therefore get an opinion if it makes sense and last but not least, if it will be accepted.

The need: Let's assume the following usage scenario: I'm using VDR mostly as a recording daemon on a FF-less system, therefore when I'm watching live TV or recordings in VDR I have to use softdevice or vdr-xine. I'm always loading the vdr-xine plugin when VDR is running as a service, to be able to connect to it with df_xine. Until now I'm doing this step manually (either starting vdr with the softdevice plugin, or starting df_xine to let it display the VDR OSD and decode it's streams when VDR is already running in deamon mode). Now I'd like to be able to start df_xine from within Freevo ( http://freevo.sourceforge.net/screenshots_blurr.html#freevo_ss1 ) which already has a plugin for this, which is talking to VDR via SVDRP.

The problem: Because I sometimes shut down Freevo and let VDR just run in deamon mode, and eventually start df_xine again manually this time, the VDR deamon has to run with remotes enabled (I'm using LIRC and sometimes keyboard). When Freevo is up, it's controlled by LIRC and/or keyboard, too, and that's a conflict(*), I wouldn't even see what the keystrokes I do for Freevo instruct VDR to do when not having it displayed in df_xine, for example when doing other things than VDR in Freevo, like watching movies or pictures, or listening to music(**), and even while displaying VDR in df_xine invoked by Freevo, they would both react at the same time directly to keystrokes.

My proposal: I thought I'd introduce a new SVDRP command which would enable/disable all or just a specific remote, and therefore reset/set a disable-flag in cRemote, which would cause the cRemote::Put(..) and cRemote::PutMacro(..) methods return whithout executing their normal code. Then I would disable my remotes in VDR via SVDRP when starting df_xine from Freevo and let Freevo control VDR via SVDRP, and when leaving df_xine I would re-enable them again. What do you think of this?

Further implementation questions, if what way I described makes sense:

• What should the cRemote::Put(...) methods return when disabled, true

or false?

• at a first look, the disable flag could be checked only in bool

cRemote::Put(eKeys Key, bool AtFront) which actually does the work in the other 2 methods, too, would it have side-effects if implemented that way (I think not really)?

So, should I go this way?

cRemote::Put(eKeys Key, bool AtFront) is a _static_ function, so in there you have no way of knowing which remote control has received the key. So this will only work if you intend to _completely_ turn off _any_ remote control functionality.

I would return 'true' in that case, because it simply disregards the key press and doesn't mean to cause any error handling.

As for the SVDRP command: I suggest you write a plugin that implements the command(s) you think you need. This is way too specific to justify a native SVDRP command.

Klaus

Hi,

Klaus Schmidinger wrote: [...]

cRemote::Put(eKeys Key, bool AtFront) is a _static_ function, so in there you have no way of knowing which remote control has received the key. So this will only work if you intend to _completely_ turn off _any_ remote control functionality.

Ouch, I missed this when quickly having a look over the source. But anyway, for my purpose it would be ok. The flag would certainly not disable the remotes by default, if no one touches it.

I would return 'true' in that case, because it simply disregards the key press and doesn't mean to cause any error handling.

Cool, just wanted to make sure.

As for the SVDRP command: I suggest you write a plugin that implements the command(s) you think you need. This is way too specific to justify a native SVDRP command.

Ok, that sounds very reasonable. Then the patch for VDR would be minimal. Thanks a lot for your suggestions!

Lucian