Update Digital Devices drivers for DD Max 8

[alexhass]

Per http://wiki.openelec.tv/index.php/Supported_TV_Tuners#PCIe_Tuners it looks like the DD drivers are quite old. They released new drivers. The newer drivers will also support the new killer card DD Max S8 (http://www.digital-devices.eu/shop/de/max-serie/max-serie/218/8-tuner-tv-karte-full-spectrum-dd-max-s8-4/8-tv-card?c=121).

Can you update the DD drivers, please? Latest version can be found at https://github.com/DigitalDevices/dddvb/releases and https://www.digital-devices.eu/shop/de/custom/index/sCustom/80

[stefansaraev]

it was me who basicaly rebased the old driver for years, on top of mainline kernel. but I dont have interest doing that anymore.

indeed, the old driver needs more and more rebasing work (I was using endris' media_build_experimental), but! few months ago I tested 0.9.21 or 22 (I dont remember) on debian jessie, and it was epic fail with octopus v3 + duoflex ct2 - crashes at runtime once a few hours. it was completely unusable fyi.

maybe, if someone can send few octopus / duoflex / max samples to @trsqr or @vpeter4, they can take over ?

EDIT: or ask dd to send their driver to linux mainline ?

[CvH]

@stefansaraev fyi https://github.com/DigitalDevices/dddvb

but well no hardware no test ;D

[stefansaraev]

@CvH I know where it is, it jist did not work for me (I need my cards runing 24x7).

I have lot of hardware in production (still using 0.9.14 + few minor patches from media_build_experimental) , but none on openelec

[alexhass]

Isn't DD not very committed to fix issues? Would be good to give DD support feedback if something is not working well.

[sraue]

@yamlfd can you test http://snapshots.openelec.tv/OpenELEC-Generic.x86_64-7.0-devel-20160417163717-r22587-g64f9e40.tar and report back with all logfiles like dmesg, lspci, lsmod etc....? (not sure if this will work and i dont have hardware to test

[Akruidenberg]

I have a problem with my Digital Devices Cine CT V7. With Openelec 6.0.3 it works very well. But with Openelec 7, TVheadend 4.0.9 wont find the card anymore. I've got an empty list. I've tested the snapshot version of @sraue but it don't work. Sorry for my bad english

[alexhass]

How can I install this snapshot? I only used images until today.

[mhueske]

Just put it in the "Update" share via network/CIFS and reboot

[alexhass]

Thanks for the help. I installed this tar and can also confirm that the update causes the Cine S2 to fail / disapear in tvheadend. See attached log, please.

debug.txt

[alexhass]

Sounds related https://bugzilla.kernel.org/show_bug.cgi?id=55211

[stefansaraev]

Sounds related https://bugzilla.kernel.org/show_bug.cgi?id=55211

not at all.

in OE7 beta dd cards are not supported at all (driver is not compiled), I dont know what sraue added to his build, but your device: 18c3:0720 is NOT recognized (it should be handled by ngene but is not)

EDIT: and https://github.com/DigitalDevices/dddvb does NOT have a driver for ngene. it is just ddbridge + few frontends.. nothing to do with cine series.

[stefansaraev]

@sraue if you cant find someone to rebase media_build_experimental on top of 4.4+, my advice is to enable in-kernel ddbridge / ngene pci-e bridges, + following frontends: stv0367, stv090x, drxk, and whatever stv* is avaliable. (cxd2099 and cxd2843 are not mainline, I feel sad for people who own newer duoflex modules)

then, at least some old cine series, and odcopus v2 + some old duoflex modules may work, and say sorry to people who have newer cards ;)

[stefansaraev]

hey, and once media_build_experimental is rebased, one may need to update dddvb on top of it. good hardware, what a driver mess.

[stefansaraev]

https://github.com/herrnst/dddvb-linux-kernel/commits/mediatree/master-ddbridge-testing

look here, this may help.

[alexhass]

I'm currently running cine s2 5.4 with OE7 beta2. It is working.

I think we should write DD if the drivers are not working. They need to fix their bugs asap.

I tried to unstand what you have written, but do not get it. Why can newer cards not supported? Saying sorry is not really solving the root cause... I'm willingly to help getting this fixed as I plan to buy a max s8 and do not like to stand in the rain.

[stefansaraev]

yea. cine s2 5.4 is so old that it may work with mainline kernel. now try 6.5, or try octopus v3 + some new duoflex ct2 modules.

before fixing their bugs, dd have to mainline their driver (including their custom tuners and demods)

[alexhass]

Sorry for asking as i'm not a kernel guy. What does it mean "mainline their drivers"? I would write them and point them to join here to get things forward.

[stefansaraev]

sending patches to linux kernel. not throwing some source code on github and saying "hey, we support linux", and shifting support burden to distributions.

[alexhass]

I read so often how difficult it is to get a driver into the linux kernel. Why is it so difficult to integrate? Does it fail compliling? It is currently not compatible with current kernels? Is this what you are saying?

Send an email to DD head of tech support. Hopefully we get some feedback and the developer involved here soon.

[fritsch]

I think you don't understand. It's not about a short term solution, but a maintained longterm solution - maintained by those that write the drivers. Whenever OE/LE bump the kernel ... these drivers need manual adjustment. Most of the time: new kernel with additional hw support equals: no ddd drivers anymore and that sucks.

So it does not help if the ddd guys help compile that stuff one time as the problem will come back, next time a kernel is bumped.

2016-04-19 22:46 GMT+02:00 yamlfd notifications@github.com:

I read so often how difficult it is to get a driver into the linux kernel. Why is it so difficult to integrate? Does it fail compliling? It is currently not compatible with current kernels? Is this what you are saying?

Send an email to DD head of tech support. Hopefully we get some feedback and the developer involved here soon.

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/OpenELEC/OpenELEC.tv/issues/4921#issuecomment-212120514

               Key-ID:     0x1A995A9B
               keyserver: pgp.mit.edu

Fingerprint: 4606 DA19 EC2E 9A0B 0157 C81B DA07 CF63 1A99 5A9B

[stefansaraev]

I could make that stuff compile and work for existing users in just few hours but that's not the point.

let me tell you a story:

few years back, a chinese vendor appeared (dvbsky), we got a driver, included it in OE. for maybe an year, we got a promise that they will mainline the driver,. I maintained the driver for OE, once, I've done stupid things to make it compile (look at our git log) and also there was some drama with another vendor (I wont say the name, look at the damn git log if you want).

now, there is a mainline driver for (almost all of) their products, OE does not care anymore. users are happy, their cards work out of the box. everyone is happy ;)

if chineses can mainline something, it should be absolutely no problem for germans

[alexhass]

Got it. Just asking me how long it will take to get it into the kernel. I'm for the long term solution, but DD need to manage this. I only hope it will not take until OE 10 as it makes the DD hardware useless.

[trsqr]

@yamlfd, getting stuff into Linux kernel is not difficult. I'm a pure driver-writing hobbyist and my submissions (as well as everyone else's) go 90% of the time into the next kernel release. Typically that means something like 4 months from submission to a released kernel.

It's true that you need to follow certain guidelines and conventions, but those are just there to guarantee at least some form of uniformity and style of coding in a project with thousands of contributors. Of course there are guys that will just dump whatever code they have with attitude of "those goddamn open-source hippies should be happy for what they get from us for free" and they might have hard time when the code is reviewed and changes are requested.

All in all, I believe the DD guys have worked with the mainline kernels previously, they know what they are doing and if they would want to do so, it would be absolutely possible for them to add their drivers into the mainline kernels. They could even "hire" someone eager to do this for them.

[alexhass]

I have read that the driver has been integratet in linux kernel 4.14. https://github.com/herrnst/dddvb-linux-kernel/wiki#mxl5xxbased_MaxS48_support. Hopefully it can be integrated now. Digital Devices Cine cards v7 are also integrated... hurray.

[CvH]

@yamlfd it works well with the kernel drivers, but some cards are still not supported (or not working) - but most of them are working without an problem. Some users say v6.1 are not working some ppl have it working so no idea if there still is a problem or not ;)

[alexhass]

OE kernel is not 4.14 as I know. How should it work than?

[CvH]

@yamlfd there is a active maintained fork with up-to-date stuff

[alexhass]

Do you mean libreELEC?

I just tried to ping the maintainers here as they suggested to get it into kernel and this is now done.

[CvH]

@yamlfd as I am the last one that "made it work" at OE (OE6) and I am basically the only one who really cares for that stuff since years at the *ELEC eco system I just told you this ;) Pinging the maintainer is a bit useless if you follow the other gh issues here and commit history. If there is a bump at kernel 4.14+ these cards should be automatically included if the kernel config was done okay - besides that problems described above ^^^^ .

[alexhass]

Moved to https://libreelec.tv/