[vdr] @Klaus, before I start working on this patch...

Lucian Muresan lucianm at users.sourceforge.net
Fri Nov 4 11:52:38 CET 2005


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?

Best regards & thanx for this great software,
Lucian



*) I know about the --no-kbd and the --lirc=PATH_TO_DEVICE command line
switches of VDR, but on my system --no-kbd does not prevent VDR getting
keyboard events, only specifying --lirc=/dev/null or something like that
prevents VDR getting LIRC commands, but it always logs errors (which is
understandable). But even then, this would be inflexible for me as a
change in the behaviour of reacting or not to cRemote events would
require restasrting VDR.

**) Please don't tell me VDR can do all theese too, I know it can, but
on a budget-only system with just 1GHz Freevo is more efficient at
those, because it's using xine for DVDs, or diplays pictures natively on
DirectFB without transcoding them to MPEG frames first, and Freevo's UI
also doesn't need this transcoding stuff like text2skin would need, as
it all was designed for FF-cards.



More information about the vdr mailing list