[vdr] @Klaus, before I start working on this patch...
Klaus.Schmidinger at cadsoft.de
Fri Nov 4 14:13:22 CET 2005
Lucian Muresan wrote:
> 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.
More information about the vdr