Arch Linux

Hi Everyone,
Since I moved a year ago to New Zealand I have much less time to keep my AUR packages maintained and keep my system tweaked. Arch Linux is just too bleeding edge to make a comfortable low maintenance multimedia server platform and I now need a server which will continue to run for years in a very boring reliable way without much input from me. Also the frequent surprises that happen when Arch updates to something new are not as fun as they should be. I recently made the switch to CentOS7 on my main server which is running FFdecsawrapper and will stay on a 3.10 kernel probably for the next 8 years.

This is the time for me to bow out as I can not longer test this package. So this package needs a new owner. I will miss the learning fun that ArchLinux has given me. But I'll keep a little fun as my remote frontends will still run Arch.

Issue below fixed

There is an issue with the newest pacman 4.2 and configure syntax in all V4L related branches including V4l, media_build, linux_media, and bas-t's media_tree. I will be working on patching up a solution shortly. See discussion here:

https://bbs.archlinux.org/viewtopic.php?pid=1489378#p1489378

Changes:
1) Improved dvbdev.c patch
2) Can be configured to work with more than 4 DVB tuners

@bas-t:
Thanks to your work FFdecsawrapper is as good as ever regardless of the settings. Yeah you don't "need" a tsbuffer higher than 4 as it always works. I base my decisions for the default settings in the packages to what is giving me the best results in my setup fully knowing that PC and DVB hardware and type of encryption system make it not the same accross the board.

So currently I have a TBS 6984 and 6985 with 8 DVB-S tuners total using official TBS drivers with older V4L lib's and an Intel 1155 i5 based PC. A higher --tsbuffer setting allows smoother channel changing when using 6 to 8 tuners simultaneously. It gives no discernable disadvantage. For this reason I put it in there as a default on the premise that there are users out there who want the most ideal setup without the tweaking about. Obviously users are free to change to what they want.

@ p-we:
What's alot of tuners?
I've got 12 in my backend atm, still don't need a non-standard --tsbuffer setting.

Some changes:
1) Added tweak to speed up module compression. Thanks to Sunday.
2) Will use the master branch for FFdecsawrapper for now as it is even better than stable. Master is based on sasc-ng ver 620 codebase plus other good improvements by bas-t
3) --tsbuffer set to 64 as this seems better for systems with alot of tuners

--tsbuffer=32 added after all. This does make a difference with more than 4 tuners

Developments:

1) FFdecsawrapper has recently made a quantum leap starting from ver 209. Encoded foldbackadaptors tune as fast as real DVB tuners now. Therefore no tsbuffer config settings needed anymore. The following is from bas-t who is doing alot behind the scenes for ffdecsawrapper. See below:

"I fixed those speed tests. You'll notice that your max speed will be rated somewhat lower then you are used to get, that is expected. There are no more 'peak' levels, instead you'll get reasonable averages. Furthermore, I pushed some commits that improve the stability as well as the speed of tuning and locking greatly. As a result, I don't need "--tsbuffer=some-ludicrous-high-setting" anymore, even with my TBS adapters. I'm using the default setting (4) now."

2) As systemd has become better in recent versions and I made some changes to module permissions, optional parameters in ffdecsawrapper.service are no longer necessary and thus removed.

3) FFdecsawrapper GIT branching has changed. For standard ARCH kernel there is no difference. Kernels below 3.13, such as linux-lts, now use a different branch. See PKGBUILD for details if this affects you.

I have revisited the "tsbuffer" ffdecsawrapper compile argument and with reliable positive result this time around:

I have just changed from a smooth running DVB-C system to DVB-S & S2 where FTA channels were all fine but all encrypted channels had stability issues running through the same foldback adaptors. I noticed the ffdecsawrapper log displays the tsbuffer in MB with the default set at 2048 MB. Setting --tsbuffer=8192 solved this straight up. I have my server running at 16384 now but I haven't noticed a difference between 8192 and 16384. Also the "zapping" time is a bit quicker and more consistant. This seems to be worth it. I will put --tsbuffer=8192 in the PKGBUILD so it will run with 8192 MB as default.

Let me know if this presents a problem for anyone.

When I tried to get ffdecsawrapper to run as a daemon again it now it does work. It seems better this way. The ffdecsawrapper.service has been changed accordingly so remember to:
# systemctl reenable ffdecsawrapper.service

Yes, because it has your patch!!
I found out that the LIRC/RC bundle is more than a bunch of driver modules so it was easiest to just not build with it

Thank you.

Lirc's working nicely again.

Based on Ttz_ztT's findings, this package has been updated to exclude LIRC in its totality from the installed V4L-git lib's.

Hey Ttz_ztT
Thanks for testing this. I'm convinced. Lirc has got to go as it's not relevant and you proved it's just getting in the way. Your makefile patch might come in handy but I'm going to try to fix this at the install level without the need for a patch against en ever changing V4L tree.

Deleting the modules in the updates/v4l dir didn't work as expected.

Commenting out

# There are both core and drivers at RC subtree - merge before drivers
#obj-y += rc/

in media_build/linux/drivers/media/Makefile
did the trick for me. No lirc_modules or rc_* built at all..
Now everything's fine :)

@Ttz_ztT
Thanks for the feedback. I'm not familiar with a module named lirc_serial. You can try this for any module in question:
Go to /usr/lib/modules/`uname -r`/updates/v4l and delete the culprit module which doesn't load or misbehaves. Re-run depmod (as root) and reboot. Since the updates directory takes presidence over the kernel v4l tree, it should grab the lirc module you need from the mainline v4l tree in kernel after that.

I don't know what is going on with V4L but this package is intended primarily for DVB. If lirc is messed up in general in V4l git, then I can have this package ignore IR drivers in the future.

Thanks for updating this nice package!

This works now on amd64 with linux-ck-3.12 from repo-ck.
I have problems loading lirc_serial though. This was working with ck-3.11...
Don't know if there has been a change in media_build's default lirc modules??

Recently dvbdev.c has been altered in experimental V4L lib's. The mutex patch has been changed accordingly. The code looks to be more robust i.m.h.o. so this could be leading to improvements. No noticeable increases in MythTV tuning speeds however it does seem to be more consistant from channel to channel.

If you give this a try, please report your experiences here. Thanks.

Edit: I've been informed that the package with new patch doesn't work in a debian based 32 bit environment. Possibly also a problem with i686 ARCH?

I have discovered an improved method to install the modules to give presidence over stock modules in the kernel tree. If you have tried this before and it didn't work, it should work now.

This is an alternate approach to installing ffdecsawrapper on Arch. It is probably a good idea to first have the standard ffdecsawrapper working properly before trying this. If you haven't tried ffdecsawrapper yet, try that first:

https://aur.archlinux.org/packages/ffdecsawrapper-git/

Advantage: In theory should give better performance with cutting edge V4L driver lib's. ArchLinux is well suited to use V4l GIT because Arch uses cutting edge kernels.
Possible disadvantage: With respect to cutting edge V4L lib's, YMMV. This might be less stable or not even work depending on your hardware.
Disadvantage: Has an added AUR build dependancy
Disadvantage: Compiling the V4l lib's and compressing the modules takes awhile. Please be patient.

Note: If your current kernel still has the mutex patch (dvb-core.ko.gz) placed from the other ffdecsawrapper or open-sasc-ng package, restore the backup file or reinstall the kernel.
Remember to change your conf and cardclient.conf files if you are still running with open-sasc-ng version. Also don't forget to:
# systemctl disable sasc-ng.service
# systemctl enable ffdecsawrapper.service

I would love to hear about other experiences compared to the standard ffdecsawrapper package. There may be issues for some. Yet, in my case, I use 3x TT C-1501 PCI cards and this package is MUCH better qua performance and stability than the standard build on kernels 3.10 and upcoming 3.11.

I'm going to make an appreciative plug here. Bas-t has been really burning the midnight oil on sasc-ng and now with the new name FFdecsawrapper. This alternative package build with the newest V4l lib's is also a direct result from his dedication to this. This is my public message of thanks to him for making FFdecsawrapper, and open-sasc-ng before, already much better.