On Mon, Oct 27, 2008 at 1:35 AM, Oliver Joa <[EMAIL PROTECTED]> wrote:
>>> Would this approach allow easier implementation of a real client-server
>>> solution for VDR or would VDR still need severe changes in order to
>>> allow this?
>>
>> Has not much to do with this. The limitation for a client-server
>> solution is that VDR has exact ONE display front end, ONE open menu at a
>> time, ONE recording playback, ONE user that edits a timer, ONE display
>> size, ONE number of lines that fits on the screen, and so on.
>>
>> Its just a lot easier to do it with multiple VDR instances that share
>> the few unique resources like DVB hardware, timers and recordings. And
>> all that is already possible with a streamdev like setup.
>
> I wonder how? I try to do this now for some years, but I can not find a
> really good solution. Can you tell me some details?

I tried streamdev a couple years ago just to see how it worked because
if it was good, I was interested in setting up a couple clients.  BUT
it didn't work good at the time.  Not even close.  I'd hope it's made
some improvements since then but that still doesn't change the fact
that VDR was designed to be stb-like.  A single box with usage
primarily revolving around FF dvb cards.  Unfortunately that seems to
be one of it's biggest weaknesses these days, where people are more
interested in HTPC's and the server-client setup MythTV offers.
There's still a place for VDR but unless some good solutions for
problems like this start showing up, it will continue to become more
outdated over time.  It would've been great if VDR's design took these
things into consideration (if not at the time, at least looking ahead
at future needs) but hey, I'm just happy MPEG-TS is -finally- being
supported!  ;)

TV serving is another topic however and should be discussed in it's
own dedicated thread.

Cheers

_______________________________________________
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Reply via email to