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...?
Thanks.
"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.
so long ... clemens
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
Klaus Schmidinger wrote:
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 ;-)
This is not really a good point any more, since at least latest development 1.7.x builds wont work without a custom kernel and custom DVB drivers and headers.
And if you really want to avoid the -P dvb, you could still add some auto-magical plugin load mechanism for it, or a way to optionally statically link certain plugins into the VDR binary. (hmm, sounds interesting.)
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?
For me, only one of the three VDR systems I frequently use has real DVB devices. One is a streamdev/nfs client, and the third is a local disk playback VDR only. (that annoys me with "channel not available" messages. :) )
With unpatched 1.7.1, I would have to build custom kernels and unused drivers for each of them, while with a DVB plugin, VDR would not depend on special DVB devices at all.
Of course this would also allow to keep an old DVB API plugin for those with no HD plans in the near future.
Also, it would reduce the linux dependency of VDR. Or did someone ever do a BSD or Solaris port of VDR?
Cheers,
Udo
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
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?
Br, Pasi
VDR User wrote:
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
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
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
Hi,
Udo Richter wrote:
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.
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?
Thanks
Olli
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
On Sun, 26 Oct 2008, Klaus Schmidinger wrote:
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?
Howabout implementing a command line switch to disable the integrated DVB device support. The basic DVB support would be compiled in, but an option to disable it would give possibility for external DVB input plugins.
Anyway, the support for pseudo DVB plugins (like IPTV, analogtv, ..) would be a nice addition at the same time. The IPTV patch already contains an example implementation without messing up the existing channels.conf format ...
BR, -- rofa
-
Clemens Kirchgatterer -
Klaus Schmidinger -
Oliver Joa -
Pasi Juppo -
Rolf Ahrenberg -
Udo Richter -
VDR User