On Mon, Oct 27, 2008 at 1:35 AM, Oliver Joa <ojoa@xxxxxxxxxxx> 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@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
