Arch Linux

Just a last package related note:
TBS is currently mucking around quite a bit with their driver package format and this has caused some trouble. However, as of 3 days they have brought it back to how it has been so it is good for now but it could change. If you run into trouble, take a look at the tbs-dvb-drivers package which is now owned by Sunday which shares the same drivers as this package.

https://aur.archlinux.org/packages/tbs-dvb-drivers/

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.

There is a new v150429. Yes an update with the same name. Fundamental changes in driver pacakge structure with an installer script we can't use here because the patch needs to be applied. Drivers can still be built manually. Working on it.

v150429 brings support for linux 3.9 and 4.0 kernels... finally

v150313 will not build with new linux 3.19 as TBS official drivers are not yet compatible with 3.19. At this time unofficial TBS drivers maintained by L. Alves do compile but don't work with 3.19 either. Kernel 3.19 and also 4.0 now at RC2 both come with big changes for the media stack including DVB devices. The guys at TBS will probably have alot of work to do so the fix might not come quickly. It might not even be a big priority for them to get it done quickly.

So the choices are to stay with 3.18-6 or use linux-lts which is based on 3.14 until DVB developers accross the board catch up with kernel development.

So the new v150313 driver is back to zip format AND includes firmware.
Go figure. What will it be next?

kernel 3.19 is coming soon but the current driver package (150130) does not compile with 3.19. You can wait for new driver or use with linux-lts.

Updated 150130 driver package brings some changes for TBS:
1) tar.bz2 format instead of zip
2) No more firmware, so I'm assuming firmware is now integrated into drivers.

There is no new documentation posted at TBS yet

Issue below fixed

There is an issue with the newest pacman 4.2 and configure syntax in TBS driver package. This also includes similar syntax in related V4L 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

2 changes:
1) New improved dvbdev.c patch based on Oliver Endress' patch for newer >3.13 V4L lib's.
2) FFdecsawrapper back to stable branch which now has all the recent improvements

v140819 is out. Problem solved.

Bad news: Driver package v140707 is incompatible with 3.16 kernel
tuner-types have been merged into V4l tree so TBS will have to update their V4L lib's.

If you want to use linux 3.16 either wait for a new TBS driver package or try:
https://aur.archlinux.org/packages/ffdecsawrapper-git-tbs-unofficial/

Added tweak to speed up module compression
Thanks to Sunday.

2 changes:
1) New TBS driver package v140707
2) Will use the master branch for FFdecsawrapper for now as it is even better than stable. Master is now based on old sasc-ng ver 620 codebase plus other good improvements by bas-t

added --tsbuffer=32 to configure as this seems better for my 8 TBS tuners

2 new developments:

1) 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.

2) The v140425 package has changed despite keeping the same name. Checksums have been changed accordingly.

The newest v140425 driver package works as is, but for my 6984 has some intermittent issues when used with FFdecsawrapper which indicates that there may be V4L irregularities within the whole v140425 package. The point is that this newest driver package might be less "perfect" than TBS driver versions in the past. Keep your older v140323 around just in case.

EDIT 2014-04-29:
Changing permissions of modules to 755 (644 before) seems to fix the irregularity mentioned above for me and might explain why earlier versions of systemd were also more consistant when Group=video was added to service file.

The following is from bas-t who is doing alot behind the scenes for ffdecsawrapper and TBS drivers. See below:

"I fixed those speed tests. You'll notice that your max speed will be rated somwhat lower then you are used to get, that is expected. There are no more 'peak' levels, instead you'll get reasonable averages.vFurthermore, 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. In a joint effort, TurboSight and I are slowly rolling out new drivers for their adapters. 6680 is done, I can compile it "in tree" directly into the 3.14.1 kernel, so it is much more reliable. Well actually I can say it is rockstable this way. Next will be the 6285."

Changes to this package:
1) Removed tsbuffer parameter to use default 4GB buffer
2) Removed optional parameters from ffdecsawrapper.service as systemd has become better in recent versions.

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.

updated to v140323

Ok, after 2 kernel upgrades, various package upgrades including libc, and about 20 mythtv GIT versions later, this package does work with current ARCH based on kernel 3.13. Seems a little snappier than linux-lts too.

I'm in the process of moving and migration to DVB-S2 and a TBS 6984. Even though I won't be able to truly troubleshoot functionality of this package for about a week, it's obvious that there is something wrong with the loopback adaptors created within linux 3.13. This doesn't come as a surprise as core V4L lib's have changed from 3.12 to 3.13 and dvbdev.c is affected. The current v140210 still uses pre 3.13 V4L. Multiple TBS users have confirmed that the drivers themselves do work with ARCH 3.13. So, as I see it we have the following options:

1) Someone informs me that I'm wrong and that their TBS card works marvelously with this package and I eat my words ... and they share knowledge.
2) Install linux-lts which is based on 3.10 and works fine with this package.
3) A final solution comes from someone. I have an idea about how to fix this for 3.13 which I will report in a few weeks time.
4) Try this to help out:
a) Install https://aur.archlinux.org/packages/tbs-dvb-drivers/
b) Comment out the conflicts= line in PKGBUILD
c) Install ffdecsawrapper-tbs-git over the tbs-dvb-drivers package

Comments very welcome!

Updated to v140210

Note:
As of kernel 3.13, the mutex patch for dvbdev.c for drivers in the kernel tree is obsolete. TBS however provides it's own V4L lib's which has a dvbdev.c file which resembles older kernels. I will not be able to test this package on a TBS 6984 for a few weeks. I don't what the behavior will be like for TBS cards on linux 3.13. So if the package doesn't work as is for 3.13 ARCH, try to comment out the patch line in PKGBUILD.

A few changes:
1) I recently tried to get ffdecsawrapper to run as a daemon again with systemd and now it does work. It seems better this way. The ffdecsawrapper.service has been changed accordingly so remember to:
# systemctl reenable ffdecsawrapper.service
2) At the present time it is my experience that the --sid-nocache parameter is once again essential for reliable tuning with MythTV 0.27. Info in ffdecsawrapper.conf changed accordingly.
3) Updated to TBS v140113
4) RC modules enabled again. Hopefully fixed with this new version.

Hi Erik-NA
I can confirm that FFdecsawrapper configures and builds for ARCH x86_64 and i686. Furthermore I also know it configures and builds for Debian x86_64. You should look at bas-t's ffdecsawrapper GIT repo directly. He has a specific Ubuntu branch. He also provides very good tutorials on his site. If it still doesn't config under the Ubuntu branch, then you should create a ticket at his GIT repo about this.
There is about something weird about your linux system why it is not identifying your CPU properly. It definitely works for vanilla like linux kernels.

This is not working for me with 64 bit Mythbuntu 12.04

make[1]: Entering directory `/usr/src/ffdecsawrapper/FFdecsa'
g++ -Wall -fPIC -O3 -march=pentium -mmmx -fomit-frame-pointer -fexpensive-optimizations -funroll-loops -DPARALLEL_MODE= -c FFdecsa.c
FFdecsa.c:1:0: error: CPU you selected does not support x86-64 instruction set
FFdecsa.c:1:0: error: CPU you selected does not support x86-64 instruction set

Made the following change to /FFdecsa/Makefile
#FLAGS ?= -Wall -fPIC -O3 -march=pentium -mmmx -fomit-frame-pointer -fexpensive-optimizations -funroll-loops
FLAGS ?= -Wall -fPIC -O3 -march=x86-64 -mmmx -fomit-frame-pointer -fexpensive-optimizations -funroll-loops

and got:
g++ -Wall -fPIC -O3 -march=x86-64 -mmmx -fomit-frame-pointer -fexpensive-optimizations -funroll-loops -DPARALLEL_MODE= -c FFdecsa.c
FFdecsa.c:65:18: error: operator '==' has no left operand

2 changes:
1) Make distclean added to solve problem with kernel upgrades
2) RC and Lirc files from V4l are no longer built into the package. There appears to be some issues with kernel 3.12 and older lirc/rc modules.

Changes:
Updated to TBS ver 130927
Now installs all modules in the TBS driver package including V4L. The V4L drivers packaged with the TBS driver package are now known to be necessary for at least 2 TBS cards.

This is a FFdecsawrapper version which should work out of the box with the TBS family of DVB cards. I don't have a TBS card to test this with, so I would appreciate if someone would comment as to whether it works well or not.

Note: This installs the TBS drivers for you. They should not be pre-installed