[Feature Request] DVB drivers

[evilmon]

Hi,

 

it would be nice if all linux DVB-drivers would be integrated in the UnRAID Package by default.

piotrasd did it for  unraid 6 - beta 12 and it works great with tvheadend. The bzroot is only 13MB larger than before.

http://lime-technology.com/forum/index.php?topic=32640.msg342314#msg342314

 

How do others think about it? Please post your opinion.

[EdgarWallace]

+1

 

I just guess that many unRAID server are running as media server. TVheadend is a great way to support that approach and would fuel XBMC/KODI/openElec with TV streams.

[NAS]

My opinion is that considering the entire userbase "percentage wise" no one will want these.

 

However those that do REALLY do.

 

I am not sure that supporting DVB is something uNRAID should do and thats what including them by default means so what we ideally need is some sort of LKM solution to push this into the community.

 

I storngly suspect this wont happen in any reaosnable timeframe though.

[EdgarWallace]

We are not asking to support DVB, we are asking for drivers that are being part of any other Linux distro, so what's the issue? A couple of megabytes? We have entered 20th century a while ago.

[evilmon]

Like EdgarWallace said: Please only include the drivers. All other support and pieces of software are a community-thing. The community is able to write plugins and/or docker-containers for DVB-software but the comunity can not include drivers with these techniques.

The main thread Tvheadend plugin for unRAID V5.0 is 65 pages long. I think many users will be afraid about the option using their unRAID as a TV-server.

[NAS]

We are not asking to support DVB, we are asking for drivers that are being part of any other Linux distro, so what's the issue? A couple of megabytes? We have entered 20th century a while ago.

 

And if they are updated who is responsible for keeping up to date, the inevitable out of tree patching required for DVB (see OpenELEC efforts over last couple years to put some scale context on this) and if a device doesnt work who fixes it?

 

In theory we could say "added but unsupported" and your few MB argument becomes spot on but lets be realistic that wouldn't be the case.

 

Dont get me wrong I think this is potentially a VERY good idea but lets see it for what it is, a major investment in the feature by LT and try and get sign of on that.

[WeeboTech]

Are these drivers already in the mainline kernel? 

Does the kernel have to be patched in any manner or are the drivers enabled via the .config / menuconfig option?

[NAS]

On the face of it the answer is yes but checkout this simple query

 

https://github.com/OpenELEC/OpenELEC.tv/search?q=dvb&type=Issues&utf8=%E2%9C%93

 

to get an idea of how far from "just works" this is and these guys are experts often having direct access to kernel developers and manufacturers.

 

Sure some devices will be fine but it is a pandoras box.

[jonp]

I can't say for certain we would or wouldn't include driver support for this in our kernel, but VMs with PCI device pass through can actually supply device drivers for host-based devices without driver support embedded in our kernel.  This is a "workaround" and wouldn't apply to Docker Containers that require drivers to be supplied by the host.

 

I will discuss this with Tom at some point in the future to get his take on it.

[evilmon]

Thank you, jonp

[olympia]

My opinion is that considering the entire userbase "percentage wise" no one will want these.

 

However those that do REALLY do.

 

I am not sure that supporting DVB is something uNRAID should do and thats what including them by default means so what we ideally need is some sort of LKM solution to push this into the community.

 

I storngly suspect this wont happen in any reaosnable timeframe though.

 

I am almost sure percentage wise much more users want DVB support than e.g. having the possibility for Xen virtualization. I don't understand your standpoint saying "this wont happen in any reaosnable timeframe though".

 

As other pointed out by others, the community is only asking to enable drivers via the .config / menuconfig option. No development needed at all from LT side.

 

I see where you are coming from in your other post referencing OpenELEC. However, I really do think that most users would just be fine with and accomodate the "unsupported" approach.

 

Moreover, Tom is some earlier discussions was positive about this - I think he just hasn't had the chance to look at this.

[jonp]

My opinion is that considering the entire userbase "percentage wise" no one will want these.

 

However those that do REALLY do.

 

I am not sure that supporting DVB is something uNRAID should do and thats what including them by default means so what we ideally need is some sort of LKM solution to push this into the community.

 

I storngly suspect this wont happen in any reaosnable timeframe though.

 

I am almost sure percentage wise much more users want DVB support than e.g. having the possibility for Xen virtualization. I don't understand your standpoint saying "this wont happen in any reaosnable timeframe though".

 

As other pointed out by others, the community is only asking to enable drivers via the .config / menuconfig option. No development needed at all from LT side.

 

I see where you are coming from in your other post referencing OpenELEC. However, I really do think that most users would just be fine with and accomodate the "unsupported" approach.

 

Moreover, Tom is some earlier discussions was positive about this - I think he just hasn't had the chance to look at this.

Users would only be fine with it if it works. If it doesn't work and we include the driver, the inevitable will happen where users will ask for updates and further patches.

 

This is why I like host device pass through with a virtual machine. Drivers for unsupported devices like these can be supplied via a guest VM which is updated and maintained on a regular basis.  Furthermore, any complications from those drivers are isolated from impacting the host thanks to isolation.  For USB devices, this doesn't even require IOMMU (Intel VT-d).

 

I tend to lean more towards NAS on this, but it really isn't my call, but Tom M's as it involves the driver stack. I will ask him to weigh in with his opinion.

[olympia]

My opinion is that considering the entire userbase "percentage wise" no one will want these.

 

However those that do REALLY do.

 

I am not sure that supporting DVB is something uNRAID should do and thats what including them by default means so what we ideally need is some sort of LKM solution to push this into the community.

 

I storngly suspect this wont happen in any reaosnable timeframe though.

 

I am almost sure percentage wise much more users want DVB support than e.g. having the possibility for Xen virtualization. I don't understand your standpoint saying "this wont happen in any reaosnable timeframe though".

 

As other pointed out by others, the community is only asking to enable drivers via the .config / menuconfig option. No development needed at all from LT side.

 

I see where you are coming from in your other post referencing OpenELEC. However, I really do think that most users would just be fine with and accomodate the "unsupported" approach.

 

Moreover, Tom is some earlier discussions was positive about this - I think he just hasn't had the chance to look at this.

Users would only be fine with it if it works. If it doesn't work and we include the driver, the inevitable will happen where users will ask for updates and further patches.

 

This is why I like host device pass through with a virtual machine. Drivers for unsupported devices like these can be supplied via a guest VM which is updated and maintained on a regular basis.  Furthermore, any complications from those drivers are isolated from impacting the host thanks to isolation.  For USB devices, this doesn't even require IOMMU (Intel VT-d).

 

I tend to lean more towards NAS on this, but it really isn't my call, but Tom M's as it involves the driver stack. I will ask him to weigh in with his opinion.

 

First of all, thank you Jon for picking this up!

 

I couldn't agree more that host device pass through with a VM is best solution. However, I think you appreciate that it is hard to justify the cost of VT-x capable HW being couple of hundreds, if the current setup can perfectly handle the use case.

 

I think you misunderstood something. This is working and you don't need to include anything else, just the drivers. Plenty of people are using it either by recompiling each and every release themselves (like myself) or using a community build shared accross here in the forum. I think what NAS was saying above is that _some_ drivers might not work and need patching. Heck, that's were I think you can say if it doesn't work upstream, then you can't do anything about it. That's where I said people will be fine and accomodate. They will buy what is proven to work.

 

As for Tom's latest known opinion, you can read about here:

http://lime-technology.com/forum/index.php?topic=19819.msg176976#msg176976

 

[jonp]

 

 

My opinion is that considering the entire userbase "percentage wise" no one will want these.

 

However those that do REALLY do.

 

I am not sure that supporting DVB is something uNRAID should do and thats what including them by default means so what we ideally need is some sort of LKM solution to push this into the community.

 

I storngly suspect this wont happen in any reaosnable timeframe though.

 

I am almost sure percentage wise much more users want DVB support than e.g. having the possibility for Xen virtualization. I don't understand your standpoint saying "this wont happen in any reaosnable timeframe though".

 

As other pointed out by others, the community is only asking to enable drivers via the .config / menuconfig option. No development needed at all from LT side.

 

I see where you are coming from in your other post referencing OpenELEC. However, I really do think that most users would just be fine with and accomodate the "unsupported" approach.

 

Moreover, Tom is some earlier discussions was positive about this - I think he just hasn't had the chance to look at this.

Users would only be fine with it if it works. If it doesn't work and we include the driver, the inevitable will happen where users will ask for updates and further patches.

 

This is why I like host device pass through with a virtual machine. Drivers for unsupported devices like these can be supplied via a guest VM which is updated and maintained on a regular basis.  Furthermore, any complications from those drivers are isolated from impacting the host thanks to isolation.  For USB devices, this doesn't even require IOMMU (Intel VT-d).

 

I tend to lean more towards NAS on this, but it really isn't my call, but Tom M's as it involves the driver stack. I will ask him to weigh in with his opinion.

 

First of all, thank you Jon for picking this up!

 

I couldn't agree more that host device pass through with a VM is best solution. However, I think you appreciate that it is hard to justify the cost of VT-x capable HW being couple of hundreds, if the current setup can perfectly handle the use case.

 

I think you misunderstood something. This is working and you don't need to include anything else, just the drivers. Plenty of people are using it either by recompiling each and every release themselves (like myself) or using a community build shared accross here in the forum. I think what NAS was saying above is that _some_ drivers might not work and need patching. Heck, that's were I think you can say if it doesn't work upstream, then you can't do anything about it. That's where I said people will be fine and accomodate. They will buy what is proven to work.

 

As for Tom's latest known opinion, you can read about here:

http://lime-technology.com/forum/index.php?topic=19819.msg176976#msg176976

 

I think what you've outlined here is reasonable.  I have asked tom to chime in here one way or the other.

 

As for the vtx requirement, its not quite that expensive compared to non-vtx hardware, but if you don't have already capable hardware, it is a new system build which IS a tall request, so I totally get that.

[CHBMB]

I had a look at the OpenElec board, I can see both arguments here, I'm not sure my DVB card is supported in OpenElec, so it may not impact me, however it would make it a lot easier for a fair few people.

 

I think it would have to be very clearly documented that it was unsupported and not be a "selling point" on the blog.

 

Would having the media tree enabled even if the drivers weren't present make it any easier for people to add their own drivers in?

 

I may be completely off the mark, but I can't get my head around drivers in Linux at all and spent a long time a couple of years ago trying to recompile and the such.  Tried it again with a Myth VM and still failed miserably!

 

Incidentally, over on the OpenElec board is this a relative of grumpybutfun? 

 

[sparklyballs]

I had a look at the OpenElec board, I can see both arguments here, I'm not sure my DVB card is supported in OpenElec, so it may not impact me, however it would make it a lot easier for a fair few people.

 

I think it would have to be very clearly documented that it was unsupported and not be a "selling point" on the blog.

 

Would having the media tree enabled even if the drivers weren't present make it any easier for people to add their own drivers in?

 

I may be completely off the mark, but I can't get my head around drivers in Linux at all and spent a long time a couple of years ago trying to recompile and the such.  Tried it again with a Myth VM and still failed miserably!

 

 

 

Incidentally, over on the OpenElec board is this a relative of grumpybutfun? 

 

 

 

I have to compile drivers for my tbs 6982 card , the last time i looked at it that was in practically all the major distros of linux that it needs compiling.

Not sure with later kernels whether tbs drivers are included now, but as of the latest in debian wheezy (which i settled on for the best distro for tvheadend) they aren't.