[vdr] Re: Some questions about plugin-features of vdr-developer...

[Klaus Schmidinger <Klaus.Schmidinger@cadsoft.de>]

Reiner Rosin wrote:
> 
> Hi list, hi Klaus,
> 
> reading the doumentation and sourcecode of the 1.1.8 version of vdr,
> I have some questions:
> 
> 1) I want to develop a plugin to improve the diseqc-support of vdr ...
> so I need to extend the functionality of the cDvbDevice-class. My idea
> was to use the -D commandline argument to exclude some or all
> dvbs-devices being instantiated via the cDvbDevice::Initialize method.
> So the plugin can instantiate the free devices as special (from
> cDvbDevice-derived) devices.
> And now my question: Is this the way it should be done? Or did you
> intend another way to implement such a feature?

I don't think that DiSEqC is something that should be handled by a plugin.
My plans are to replace the 'diseqc' parameter in the channels.conf file
with a more general 'source' parameter. In case of a satellite channel,
this would be the satellite position. Then a yet to be written function
cDvbDevice::SetDiSEqC() shall take the satellite position, frequency and
polarization and generate the necessary DiSEqC commands to set the equipment
to receive this channel. In doing so, it shall read a yet to be specified
file 'diseqc.conf', which maps the satellite position, frequency and
polarization to the installation specific DiSEqC setup.

Of course this needs to go into the core cDvbDevice implementation.
If you can come up with a useful implementation of a cDvbDevice::SetDiSEqC(),
please let me know.

> 2) Since there's an entry for diseqc in the sat-channellist, which is
> represented as an integer within vdr, is it possible to claim some
> ranges of values for such a diseqc-plugin?
> I thought about a bigger range (size about 1000 - 10000) and
> two little ranges (size about 10-100) for specified diseqc-commands
> (bigger range), user defined command-macros (little range) and
> satellite-positions (little range, too).

See above.

> 3) If one want to implement a cStatus-derived plugin, which should
> display a replay-progress-bar and the replay-state, should the current
> replay-progress and replay-mode be retrieved via a continouos calling
> of the GetIndex- and GetReplayMode-method of the cControl-
> interface? Or will there be additional event-driven methods for the
> cStatus-Interface?

You player should already know its status, so why do you need cStatus
functions for this? The prograss bar is something the individual _player_
should drive.

Klaus
-- 
_______________________________________________________________

Klaus Schmidinger                       Phone: +49-8635-6989-10
CadSoft Computer GmbH                   Fax:   +49-8635-6989-40
Hofmark 2                               Email:   kls@cadsoft.de
D-84568 Pleiskirchen, Germany           URL:     www.cadsoft.de
_______________________________________________________________