Whats going on ?

[reidjr]

Sorry this isn't a real issue, but I have been using your scripts and packages for a long time, and recently updated from ubuntu 14.04 3.13 kernel to the HWE 3.19 kernel on 14.04. I ran your great configure script as I do on minor kernel updates.

It all seemed to work, dvbloopback was built and loaded as a module, but mythbackend locked. I then checked back at this repository and looks like your in the middle of splitting out the package and deprecating the all in one approach.

Having run ./configure through and actually paying attention :-) I found the kernel wasnt being patched By running the ./kernelpatch_Ubuntu script manually to force the kernel patching, all seems to be working on 3.19, although the site says its not supported. So what is the status of the project ?

Thanks for all your good work, and is there a better way to ask questions than this :-)

[bas-t]

Op 19-08-15 om 20:53 schreef reidjr:

Sorry this isn't a real issue, but I have been using your scripts and packages for a long time, and recently updated from ubuntu 14.04 3.13 kernel to the HWE 3.19 kernel on 14.04. I ran your great configure script as I do on minor kernel updates.

What's a HWE kernel?

It all seemed to work, dvbloopback was built and loaded as a module, but mythbackend locked. I then checked back at this repository and looks like your in the middle of splitting out the package and deprecating the all in one approach.

Having run ./configure through and actually paying attention :-) I found the kernel wasnt being patched By running the ./kernelpatch_Ubuntu script manually to force the kernel patching, all seems to be working on 3.19, although the site says its not supported. So what is the status of the project ?

The project is alive, but I moved to the new approach 6 months ago. So I don't use the old ffdecsawrapper repo anymore. However, for your convenience, I just removed the 3.19.x kernel version limit. It may or may not work properly for all kernel versions to come.

Thanks for all your good work, and is there a better way to ask questions than this :-)

You're welcome and I can't think of one...

[reidjr]

Thanks;

HWE is the Hard-Ware Enablement kernel updates, so its the ubuntu VIVID kernel running under the Ubuntu 14.04 install. Allows normal users to stick with LTS but upgrade kernel to 3.19 (in this case) I wanted to upgrade the kernel because the openelec developers have been doing some really good work with improving intel Vaapi playback, and getting the best out of low end hardware for hardware deinterlacing and scaling. On <3.19 it freezes the whole box ....

Interested in why you split dvbloopback from ffdecsa ? In general don't you need both pieces to end up with a working installation, the patched dvb drivers, the dvbloopback, and then the ffdecsawrapper to do all the clever stuff ? Who would want to run just apart of that ?

[bas-t]

Op 20-08-15 om 20:33 schreef reidjr:

Thanks;

HWE is the Hard-Ware Enablement kernel updates, so its the ubuntu VIVID kernel running under the Ubuntu 14.04 install. Allows normal users to stick with LTS but upgrade kernel to 3.19 (in this case) I wanted to upgrade the kernel because the openelec developers have been doing some really good work with improving intel Vaapi playback, and getting the best out of low end hardware for hardware deinterlacing and scaling. On <3.19 it freezes the whole box ....

Interested in why you split dvbloopback from ffdecsa ? In general don't you need both pieces to end up with a working installation, the patched dvb drivers, the dvbloopback, and then the ffdecsawrapper to do all the clever stuff ? Who would want to run just apart of that ?

I've got some good reasons to split. First of all: whenever possible, compiling a kernel module in-tree is always the best choise. It guarantees maximal compatabillity.

In the old FFdecsawrapper repo, the dvbloopback module allways gets compiled 'against' a kernel tree, or even worse, against a v4l-tree that was previously compiled against the original kernel-tree.

Second:

[bas-t]

Ok, I hit the 'send' button accidentally too soon. I'll complete my answer within 48 hours

[bas-t]

Resuming Second: (this is probably a Debian thing) Debian kernels are compiled with a gcc version from the previous release. Meaning, in Debian stable (Jessie) the stock kernel is compiled with gcc-4.8, while the default gcc version of Jessie is 4.9. You always should compile a kernel module using the exact same gcc version that the kernel was compiled with. However, compiling FFdecsawraper with gcc-4.8 is (give or take some) about 20% slower than compiling it with gcc-4.9. The importance of a matching gcc version for the kernel module superseeds the loss of speed in FFdecsawrapper.

I know, I could change the part of the script that sets the gcc version to use different ones depending of what we are compiling. But given my opinion about compiling in-tree, why bother? I'm going for in-tree compilation anyway.

Third: I've never had a setup with 4 (or less) DVB adapters. That means I've to (re)compile each and every kernel I use anyway.

Fourth: I'm using DVB adapters (TBS 6281/6285) that are not supported by any official kernel, since Abraham Manu refuses to upstream his saa716x driver. Well, he says he will do it, but he has been saying that for numerous years and still has not done it. So I compile the (heavily modified) saa716x module myself, and of course: in-tree.

So, in-tree it is...

However, when you compile it like that, using my script, you'll still get the FFdecsawrapper part at the same time. It detects if it is installed. If it's not installed, it will offer you the choise to do so.

Does this answer your questions/concerns?

Cheers, Tycho.

[reidjr]

Does this answer your questions/concerns?

Cheers, Tycho.

Yes thank you for th clear reply. I tried running the full recompile, but it takes a shockingly long time compared with the (luckily still working) old school approach :-). I'll stick with that ( I'm using a TBS 6981, now with good opensource drivers, so its all I need.

Thanks again for the good work.