[vdr] Re: @Reinhard Nissl: How do you want to connect Xine toVDR?

[Rene Bartsch <ml@bartschnet.de>]

Am Mit, 2003-08-13 um 01.18 schrieb Reinhard Nissl:

> > But this means the MPEG-decoder/GUI is running all the time and you
> > can't stop it without stopping VDR - so there's no use for VDR as
> > video-recorder anymore as running with MPEG-decoder will mean high
> > CPU-load -> waste of current -> heat -> noise by fans.
> 
> I'll keep this in mind. I also like a quiet (and cool) system.

Maybe a function stopping decoding if a user-timeout has been reached?

> 
> > I'd suggest to implement one plugin for VDR and one for Xine, both
> > connected by tcp or udp.
> > 
> > e.g. starting
> > 
> > vdr -P"\xine -p[port]"\ as a daemon
> > 
> > and then connect xine by need with
> > 
> > xine vdr://[vdrserverip]:[vdrport]
> 
> Maybe for version 1.x. For now, I don't want to spend extra time on 
> communication stuff. In about two weeks, when I get my new dish, I'd like to 
> use VDR via my plugin.

Just keep your code/functions modular. That way you can implement
interfaces easily in the future.


> > That way you could also prepare the plugin for multiuser-mode when
> > VDR-1.3 is coming up (e.g. connecting multiple xine-clients at the same
> > time).
> 
> I think, this needs a deeper discussion: what is the multiuser-mode for 
> vdr-1.3? Does it make sense to supply a single OSD to multiple clients?

No, each clients needs his own ressources by deriving the complete 
OSD/receiver/input-classes.

> What happens if multiple clients operate on the OSD at the same time?

That's what Klaus is going to implement for 1.3, multiple
access-management to ressources/files.

> 
> As I mentioned above: I don't say NO to implement such a solution, but not in 
> the near future.
> 

Ok, but please, keep your code modular.


Rene



-- 
Info:
To unsubscribe send a mail to ecartis@linuxtv.org with "unsubscribe vdr" as subject.