On 26.10.2008 10:00, Clemens Kirchgatterer wrote:

"VDR User" user.vdr@gmail.com wrote:

...

The idea of adding the DVB support in form of plugins instead of including it in the core code? Before I left on vacation there was some talk about how this is a better solution these days but not sure if anything ever came out of that...?

i brought up this topic several times, but klaus never made any commitment to the whole idea. i think he does not like it.

Well, I like the idea of taking the plain VDR and a FF DVB card and have it run "out of the box", without having to fiddle around with any plugins ;-) And even if FF cards are no longer "modern", wouldn't there always be a at least some DVB device that delivers the broadcasts?

It's not like I'm generally against making dvbdevice.c a plugin, but if it's needed in most cases, anyway, where's the point?

Or do most implementations *not* use DVB devices?

Klaus

It sounds like there are some really strong points in favor of using a plugin instead. It would be great to hear more input on this! I don't see any real immediate drawbacks to switching over, are there any?

Cheers

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

Cheers,

Udo

On Mon, Oct 27, 2008 at 1:35 AM, Oliver Joa ojoa@gatrixx.com 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