Mailing List archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Klaus wrote:
> 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.

Ok, my ideas were just dealing too much with the plugin-functionality of
vdr :) ... but you are right. But I would suggest to implement a mechanism
like it is implemented in "normal" sat-receivers:
The user sets up a number of satellite/lnb-entries with the following
information:
LNB-Frequency (optional low/high -> then 22kHz is used for switching) and
(optional too) any diseqc-command that is needed to switch or drive to
the satellite-position. And the diseqc-number used today is substituted by
this
satellite-lnb-id.

> 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.

I hope so. The implementation of such a functionality will be very short...
just
grabbing the diseqc-test-program from the NEWSTRUCT ... :)

[...]
> > 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.

I thought about using the cStatus-Interface for displaying vdr-infos on
add. devices, like an LCD, ... So there's no player-device. Or will there
be another interface for such a functionality?

Best regards,
Reiner Rosin






Home | Main Index | Thread Index