Jörg Knitter a écrit :
> Klaus Schmidinger wrote:
>> Well, tell that to people writing plugins for such output devices.
>> I don't see where *I* would be involved there?!
> Are there enough interfaces to be able to read the and control the OSD 
> for including them seamlessly it into a different front-end? I don´t 
> think that SVDRP and interpreting the returned data is the best way to 
> go. And what about the limitation on one OSD per VDR?
> I think, these are the real limitations - currently users of media 
> center UIs are exiting them and start xinelib for using VDR and visa verse.
> A better separation of "back-end" and "front-end" could IMHO solve the 
> problem and end the discussion about hardware related support. Because 
> with a clean and some kind of more standardized interface (which also 
> transmits OSD related information), you could write every "output device 
> connector/plug-in" that you can think and be compatible to more 
> front-ends or devices then before. Even an "evil" Windows front-end with 
> VDR running on Windows (with the help of something like colinux or a VM) 
> would be possible.
> Currently, xinelib (with original OSD) uses a different protocol than 
> the VOMP plug-in does (own UI). Then, there is the ffnetdev plug-in 
> (with OSD tranfered with some kind of VNC IIRC) which also works 
> different from the streamdev approach (without OSD) that is used for 
> hardware streaming clients that use oxyl etc.
> Unfortunately, I am just a user, not a developer though I am at least 
> able to read and modify simple C and script code ;) - it has been a long 
> time since I was student and was able/had the time to code little 
> projects...

I second that completely.
IMHO, the core VDR should move toward a multiple OSD capability. Maybe 
the network separation between the back-end and the front-end could just 
be a compilation setting (add a RPC layer at the correct place, as a 
compilation option : no layer = current standalone setup; network layer 
= VDR server + VDR clients).
This should provide a clean way to separate the responsibilities between 
the back-end and the front-ends. The rest is a matter of plug-ins and 
not over Klaus shoulders.

I agree that the hardware side of this is just the visible part (and a 
good flame-war starter). The plugin architecture allows many things, 
which is good. The limits of the core makes it hard to create a 
network-happy VDR system (not a VDR machine, but a system of multiple 
machines), which is the root of many incompatible and incomplete 
plugins, solving all part of the problem (xineliboutput, remoteosd, 
dummydevice, epgsync, remotetimers, etc.)

I just recently started using streamdev, for a bare EPIA ML6000 client 
(diskless, no DVB device, just mobo + RAM + network). I think it's a 
good (and cheap, silent, power-efficient) starting point for a 
network-based STB. It's not perfect, but most of the imperfections come 
from the plugins that must be added and configured, each separately, to 
achieve a good VDR network STB.

It is already possible to have disks array, DVB devices, and all the 
cables down in the closet, and as many clients we want behind each TV 
set, with only a CAT5 cable and an IR sensor. That's just difficult.
Moving existing plugin code into the VDR core, and getting some out of 
the core, into plugin, would do a lot in the "right" direction.

I trust Klaus to eventually get to it, and the community to provide good 
plugins, providing a tremendous network STB system. I'm not impatient at 
all, I know this will happen. The more time it take, the better will be 
the solution, the longer it will stay.

I look at how my neighbours watch TV : DVB-S converted to an analog 
signal recorded on a crappy VCR, sending wireless scratchy analog to an 
LCD TV (which was really the top 5 years ago), one tape at a time, no 
timeshifting, etc.
...and I'm really happy with VDR.


vdr mailing list

Reply via email to