User: Password:
|
|
Subscribe / Log in / New account

Vtunerc and software acceptance politics

Vtunerc and software acceptance politics

Posted Dec 15, 2011 7:44 UTC (Thu) by Anssi (subscriber, #52242)
Parent article: Vtunerc and software acceptance politics

This would also be easily solvable in userspace if we had a DVB library that all DVB programs used (like ALSA has). That would also have other benefits, like DVB apps not necessarily having to do all the complex parsing of event/service/etc information tables themselves, which is a lot of code.
This could maybe be part of libv4l...

BTW, regarding the VDR part of the article: A network client for VDR already exists as a plugin (e.g. streamdev), so that is not the problem.

From what I've seen, people (including me) only have an issue with the fact that VDR is designed to run on a standalone HTPC with a single display output, and setting up multiple clients running VDR relying on one "server" instance of VDR is somewhat tricky (e.g. timers/recordings/channel lists of which every VDR instance has its own idea, unless using more hacks). Changing that would be a lot of work, but I don't think the VDR maintainer would refuse integrating good patches (like the article seems to suggest).

However, the above problem is not solvable by this vtunerc driver. One still needs to have some server application serving the vtunerc DVB device. If one uses VDR, one could just develop such a server application to serve some VDR client plugins directly, which would work just as well, and without kernel involvement.


(Log in to post comments)

Vtunerc and software acceptance politics

Posted Dec 19, 2011 14:26 UTC (Mon) by incase (guest, #37115) [Link]

With regards to the VDR issue: As far as I know Klaus (the primary VDR developer) only said that he won't implement a server-client architecture for VDR. (And that he probably won't be able to do support for the implementation someone else might have done).
And to be honest: As much as I like the VDR way (the GUI, the way recordings can be programmed with vdradmin and the like,...), I really grew to like mythtv at home. Apart from two "HTPCs" (actually both ION2 based diskless clients booting of our router/firewall/homeserver), we can also watch TV on our desktops,...

Anyhow, the vtunerc approach has its drawbacks, there is no point denying that, but the technical points brought up in the discussion were at least in part ridiculous (like wanting to use a DVB device on the other side of the planet, via network), or also connected with other setups (USB DVB devices for example - in the case of sudden disconnection and also in the case of possible bandwidth problems).
Ob the political side, I think the argument of "bad" companies implementing drivers via vtunerc is taken far to serious. With the same argument, we should remove tun/tap from the kernel, because that could be used by network equipment manufacturers to implement drivers for their hardware in userspace instead of kernel modules. And, if what vtunerc does can also be achieved with CUSE, why is CUSE in the kernel, it could be used to implement.....
There are also arguments against vtunerc which are valid: It would introduce a new ABI (or at least extend an existing ABI) which would probably need to be kept basically forever.
And I personally think that distributing vtunerc as a bundle of the userspace component and the kernel module source makes more sense: If the userspace interface of the vtunerc kernel module needs to be changed, it can be changed in both parts simultaneously. On the other hand, if the kernel side interface of the module needs changes, it is "a bit" more complex (you probably need to keep all used kernel side interfaces in the source, unless you only want to support a very specific range of kernel versions).

A nice library that takes most of the DVB stuff into its hands and introduces network capabilities on the go would be good anyhow. What I would love to have was some way to provide a pool of DVB devices on various hosts as the source, with the library automatically picking the most suitable one (i.e. take an in-use tuner if it already listens to the requested multiplexer and if it doesn't have more than X channels tuned to already, most PCI-DVB cards can easily be used to stream three channels at the same time).


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds