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.
Search Criteria
Package Details: ffdecsawrapper-git-v4l 3-2
Package Actions
| Package Base: | ffdecsawrapper-git-v4l |
|---|---|
| Description: | FFdecsa empowered softcam - compiled with V4L development lib's |
| Upstream URL: | https://github.com/bas-t/ffdecsawrapper.git |
| Category: | multimedia |
| Licenses: | |
| Conflicts: | |
| Provides: | |
| Submitter: | p-we |
| Maintainer: | None |
| Last Packager: | p-we |
| Votes: | 1 |
| First Submitted: | 2013-09-01 15:53 |
| Last Updated: | 2015-01-02 02:28 |
Dependencies (7)
- v4l-utils
- git (make)
- linux-headers (make)
- patchutils (make)
- perl-proc-processtable (make)
- linuxtv-dvb-apps (optional) – handy DVB tools
- oscam-svn (optional) – smartcard reader support
Required by (0)
Sources
- cardclient.conf
- cardslot.conf
- ffdecsawrapper.conf
- ffdecsawrapper.install
- ffdecsawrapper.lr
- ffdecsawrapper.rc
- ffdecsawrapper.service
- git://github.com/bas-t/ffdecsawrapper.git#branch=master
- git://linuxtv.org/media_build.git
- v4l-mutex-new2.patch
Latest Comments
Comment by p-we
Comment by p-we
Issue below fixed
Comment by p-we
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
Comment by p-we
Changes:
1) Improved dvbdev.c patch
2) Can be configured to work with more than 4 DVB tuners
Comment by p-we
@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.
Comment by bas-t
@ p-we:
What's alot of tuners?
I've got 12 in my backend atm, still don't need a non-standard --tsbuffer setting.
Comment by p-we
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
Comment by p-we
--tsbuffer=32 added after all. This does make a difference with more than 4 tuners
Comment by p-we
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.
Comment by p-we
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.