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.

For linux-lts users, ffdecsawrapper-git-lts is being brought back because there are subtle differences in the script with 4.xx kernels and 3.xx which linux-lts uses for now.

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

Thanks for the warning. Updated
I use the TBS version of FFdecsawrapper so although I do try to anticipate, I don't detect package problems.

Didn't catch the last comments until now.
Package updated

I've got several complaints about the use of exported usercopy.
This may or may not be related to Ubuntu, all of the complaining people are running Ubuntu/Mythbuntu.
Bottomline: they could not get it to work properly.

So yesterday I decided that the importance of using the exported usercopy does not superseed the importance of quite a large group of FFdecsawrapper users getting a working setup.

Bottomline: I reverted changes related to exported usercopy, you don't have to copy the Module.symvers file manualy, FFdecsawrapper will automagically pick the right one. As it always did. In your case: just use the right './configure --dvb_dir=/path' parameter.

thanks, I've downloaded the drivers from the manufacturers website, only need that one. Modified their dvbdev.c (/usr/src/dddvb-0.9.16/dvb_core/dvbdev.c) in a manner similar to the normal patch, the dvb_usercopy is already exported in the driver's dvbdev.c version.

I compile (as an external module) and install. (It loads the drivers and gives me 4 adapters) A Module.symvers is created in /usr/src/dddvb-0.9.16/. It contains the exported dvb_usercopy. I tried to modify and use your configure script to use the new directories, ffdecsawrapper and dvbloopback compile fine, but a modprobe dvbloopback gives me the famous "Unknown symbol dvb_usercopy"

I had to upgrade to kernel >3.17 (3.19) to make the driver compile properly.
However I don't think thats the problem, I have the feeling I'm not completely understanding your configure script. From where to where should this new Module.symvers be copied, and how do I make sure the patched dvbdev.c is used. I am using an Ubuntu "out-of-the-box kernel, without linux media drivers...

@John-K
it's not just media_experimental, upstream v4l media_tree has massive changes to the dvb-core, resulting in kernel crashes (soft lockups) when loading dvbloopback module. These changes are not yet in linux-4.0-RC series, nor in linux-next.
So you can still compile a kernel that works with current dvbloopback module.
You'll have to patch such a kernel to include the drivers you need if they are not in there yet. And that is, imo, not so hard to do.

So the dvbloopback module needs some (or a lot of) work.
Obviously I'm not the one that's going to do that, but I guess that eventually somone else will take over.

Please don't call Ziggo:-)

Thanks for your efforts Bas! It's been a pleasure to work with ffdecsawrapper since you took over sasc-ng. I'm about to call Ziggo and ask them to reconsider their decision to transmit plain channels :-) since I'm stuck with CanalD.
Was just building a new system using kernel 3.16.0-23, but using the latest media-experimental (for Dig. Devices) drivers in combination with the latest ffdecsa my loopback device throws dvblb_fake_ioctl errors (when I try to use it) and can't be used. I'm not patching anymore, it seems the dvbdev.c already has the patch.

Thanks anyway for your work, and I hope someone has a good heart and will give this orphan a home.

PKGBUILD is changed as per bas-t's comments below. Also tsbuffer is 32 standard nowadays so no need to declare it in configure. The package builds and should be OK. However since I use TBS DVB tuners, I cannot test this to be sure.

@p-we:
Since the new dvb-core patch exports the dvb-usercopy symbol, it makes no sense to keep the duped usercopy code in FFdecsawrapper. In 'master' branch I removed it (conditionaly, depending on linux version beeing < 3.13). I've been testing this change enough to merge it into 'stable' branch.

However, there is a minor complication involved. You'll have to see to it that the Module.symvers file that is generated by patching dvb-core.ko is copied to the dvbloopback/module directory in FFdecsawrapper before the dvbloopback module gets compiled. So not the Module.symvers file that the configure script would normaly copy into the dvbloopback/module dir. I've done that for Debian/Ubuntu, but I'm not comfortable enough with arch to do it for you guys as well.

Mind you, you don't have to change anything in you packages that are building out-of-kernel drivers, those would import a changed Module.symvers file anyway.

This is just a heads up, I know you are quite busy. So I'll wait a couple of weeks before merging into stable.

If I can do anything (like changing the code) to make this easy for you, let me know.

@bas-t
I would also like to thank you to the big contribution you made to my enjoyment of using MythTV ;-)
Just like you the necessity for ffdecsawrapper will (temporary) vanish now Ziggo/UPC will provide unencrypted channels.
I am even considering on moving away from Mythtv and start using DVBLink and Kodi instead, since receiving TV will be so much easier.

@p-we:
You're welcome.

Though I won't be monitoring development in the dvb core actively, I still can do simple updates. That is, if changes in the core don't completely break dvbloopback.
So whenever dvbdev.c and/or dvbdev.h change:
You know where to reach me, just drop me a line...

@bas-t:
I would like to publically thank you for your huge contribution to MythTV by raising sasc-ng to a whole new level with FFdecsawrapper; which is the goofy but cool name you decided to call it in 2013. It is because of FFdecsawrapper that MythTV is worth anything at all with subscription DTV. If you had not have taken sasc-ng by the horns, we would have been stuck at kernel 3.9 and tuning channels in >5 seconds. Also your modified MythTV ver 0.26 destroyed the official version's LiveTV performance until they finally got it right by 0.27.2. You also have also done alot for OS TBS drivers in the past few months. I'm guessing that most of the guys here don't know you are self-taught which is impressive with the development I've seen you produce.

Thanks again for the passion and dedication! I would like to take it over but I'm concerned I don't have the right stuff and would not have the time for the steep learning curve. I hope we can keep it afloat until internet VOD subscriptions replace TV as we know it.

I hope to see your "bas-t" handle involved with some other linux stuff.

@Robin67 (and all):
It seems that the ziggo moderator was misinformed.
atm ziggo delivers as promised, meaning no encoding whatsoever for any channel I use.
OK, ziggo might decide to start encoding HD channels again in the future.
I might review my descision if and when that happens, but for now it's case closed for FFdecsawrapper as far as I'm concerned.
As of now, FFdecsawrapper is orphaned.

Ok, I'll review my descision later on, based on the actual results.
Thanks for the link.

@bas-t:
Please do check this https://community.ziggo.nl/televisie-17/welke-zenders-ongecodeerd-basispakket-1467

It is clarification of the Ziggo moderator

I mean this list:
https://www.ziggo.nl/televisie/zenderoverzicht-nieuw

@Robin67
According to this official list, you are misinformed.
All of the channels I use have 'ja' (means yes) in the collumn that says I don't need a smartcard for it.

@Bas-t:
Just be aware that it will mostly be SD channels that will be unencrypted. Only NPO's HD channels will be unencrypted. All other HD channels will still be encrypted. So if you don't mind watching just SD ....

I do hope some one else will pick up, because I will continue to be needing ffdecsawrapper

Today (jan 5 2015) my cable provider announced that they will stop encrypting all of the channels that I actually use shortly. As a consequence I won't be able to test the functionality of FFdecsawrapper anymore. I guess I'll get myself another hobby. Feel free to take over further development if you want to.

Fixed an issue with build error in pacman 4.2. See discussion here:
https://bbs.archlinux.org/viewtopic.php?pid=1489378#p1489378

This package now works with all kernels. One size fits all. There have been requests for older kernels and I don't use linux-lts so this will be easier to maintain. Also it will always be ready when a jump is made to a new kernel.

The only disadvantage is that there will be no sum verification. It comes from kernel.org so it is safe. I previously generated the sha256sum assuming it was correct anyway.

@bas-t: OK, package changed to stable branch

@p-we:
I consider FFdecsawrapper master stable enough to rebranch as it is now.
So the stable branch moved to oldstable and current master has moved to stable.

From time to time relevant code from master will appear in stable.
For my peace of mind (and I want to have a playground in master without having to check everything before committing) it would be best when you switch to stable with your package.

Is that OK with you?

Implemented improved mutex patch by Oliver Endress
Thanks to bas-t for this and very good continued development of FFdecsawrapper

All of that is very interesting. I guess just a bit off topic for here but this might prove to be very very nice for:
https://aur.archlinux.org/packages/ffdecsawrapper-git-tbs-unofficial/

@bas-t:
1)So I know that Oliver Endriss is developing the Digital Devices linux drivers, is he also using FFdecsawrapper? VDR's new generation soft cam, and others, do not need a similar dvbdev.c patch. (I think)
2)About the patch, so the current Alves drivers, as tested last weekend on my TBS 6984+6985, the dvbloopback tuners fail, but do work as standalone drivers without the patch with FTA channels. When I tested the standalone Alves drivers with FTA and the patch applied the drivers got really "buggy". This is interesting because if I test the official TBS drivers standalone without FFdecsawrapper, it makes no apparent difference if the patch is there or not. But of course that is the older dvbdev.c file.
3)BTW, I'm glad I have an "old" 6984. The newer 6985 seems like it is still in beta stage.

Thanks for your work!! You da man!

BTW, if you want to test latest Alves drivers with the new patch, do:

git clone git://github.com/bas-t/media_build.git
git clone git://github.com/bas-t/linux_media.git -b latest ./media
cd media
git cherry-pick 909ab2d
cd ../media_build
make dir DIR=../media
make distclean
make allyesconfig
sed -i 's/CONFIG_DVB_MAX_ADAPTERS=8/CONFIG_DVB_MAX_ADAPTERS=16/' v4l/.config
#(you have 8 hw tuners, right?)
make -j3 && make install

#make install installs the lot in /lub/modules/`uname -r`/updates/media
#for arch, you'll have to compress the modules, of course

@p-we
I know that you are having some trouble with th Alves drivers, but I doubt very much that the patch is to blame. Well, for me it is not.
The motivation for the new patch lies in Oliver Endrisses comment on the old one: it is simply wrong and you cannot be sure that new_fops still works.

And I trust his judgement very much.

@bas-t
The newest version, 2.3.0.1 is running and so far doing fine.
I will try the other patch as well. I'm very curious about this patch as the newest Luis Alves open source drivers for TBS work in themselves but have problems with the current dvbdev.c patch which makes his drivers useless for FFdecsawrapper at this time.

New dvbdev.c patch

https://github.com/bas-t/linux_media/commit/909ab2db488bf2a1b9b32a12e82f891248bfd0dd

@p-we,
please test latest commit.
Works for me, need feedback

Indeed, you can skip testing.

OK false alarm on 3.17.4-1-ARCH. It runs fine with FFdecsawrapper v2.3.0. I don't know what happened though, I only re-compiled the kernel and it then worked. glibc was updated since but I doubt that had anything to do with it.

I guess now that --sid-experimental code is already merged there is no need to test it?

@p-we,
I don't have any trouble loading dvbloopback in linux 3.17.4 (or any 3.18-rcx for that matter)
I guess closed source TBS drivers are to blame, I know for a fact that my TBS adapters are not going to work with current TBS drivers as of 3.18-rc1. I moved to opensource. And it works like a charm for me.

However, saa716x will not be intree anytime soon (if at all). I noticed a couple of weeks ago that many DVBSky adapters are supported in the v4l media tree, meaning they will be intree in 3.19 kernels. So I ordered 4 DVBSky T982 adapters, thus solving any problems (to come) with saa716x. I'm very happy with my new adapters. Bye bye TBS!!!

BTW: this one is also supported: http://www.dvbsky.net/Products_S952.html

@bas-t or anyone,
FYI, Last night (late) I rebuilt ffdecsawrapper against recent released 3.17.4-1-ARCH kernel and loopback module failed to load. I noticed in the lastest commit that --sid-experimental is now standard so I removed this from run arguments but still no loading. I still need to investigate but putting this out there for discussion.

Newest GIT commit as of 27-11, Master branch

I have an obscene overkill with 31 tuners too. Nevertheless, getting multirec to work reliable was one of the main reasons to do FFdecsawrapper in the first place. So now that I don't need it anymore, I still want to fix this long standing issue very badly. Having done that, I guess I should get another hobby.

About the multirec config:
having 8 hw tuners and setting them all to max 5 concurrent recordings results in 40 mythtv dvb adapters. The default behaviour of mythtv-setup results in equal priorities for recording and live tv with all tuners. So hw tuner 1 gets 1,1 hw adapter 2 gets 6,6 etc. The trick is to reverse the prio order of live tv. So hw adapter 1 gets 1,36 hw adapter 2 gets 6,31 and so on. This way mythtv does not get confused and allways chooses the last hw tuner for live tv. That is, in my setup. Having a mixed environment (like DVB-C + DVB-S) will most likely need some more adjustments to work the way you want it to.

I don't normally use multirec because I have an obscene overkill with 8 tuners nowadays. Multirec is also a bit weird in MythTV as sometimes when you're zapping with Live TV it thinks you only have a few multirec channels to choose from and "forgets" there are more DVB adaptors left. Then you have to manually choose a different adapter in Live TV to get a choice of all the TV channels. I wish MythTV would address this in EPG options.

However, I'd be glad to torture my server in the weekend testing this.

BTW: typo in my last reply. I use MythTV 0.27.4

Hi p-we!
Nice to hear.
Now, do you want to set all of your tuners to the max of 5 concurrent recordings in mythtv-setup and test multirec?
I'd love to hear results.

Hello All,
I have also been using --sid-experimental since the last commit and it has also cured an intermittent problem I have been having with artefact breakup of the signal which happens every few shows for a few seconds. I was just about to send bas-T a very positive PM about my experience with this. I'm on DVB-S + DVB-S2 with Videoguard2 and MythTV 0.24.4. I am using TBS (out of kernel) drivers.

I'm thumbs up on --sid-experimental code

Thanks to bas-T!!

Absolutely, but not today, use the adapter really little and I must first configure everything in mythtv, including scanning channels .....
I give feedback for tomorrow!

So, it could just be this guy that had problems with the new code...
Does locking and tuning work OK on your DVB-S adapter?

I'd like to get some feedback on this from more DVB-S users

you should think even for multi DVB technology solutions

a little 'complicated I think ....

yes, experimental knows of unstable, bug or just to test .... :-)
then you tell me that there are problems with DVB-S, DVB-S2 and the option --sid-experimental?

I have 2 DVB-T (4 logical adapter) and 1 DVB-S2....

Thanks for your reply.
I'll think of a way to implement this for DVB-C and DVB-T users without the --sid-experimental option. It's an ugly option, I don't like it at all.
The problem is that most of the original code in FFdecsawrapper was written by DVB-S users. (much like TVHeadend and MythTV)

Hi bas-t, nice work!!!

I have 2 DVB-T double adapter (Hauppauge Nova pci)..
Now I'm stressing the boards and at the moment I find no problems but only improvements ....

I mean latest fixes for mythtv multirec blocked proper tuning for this guy, so I did the --sid-experimental workaround for him

@Nede:
nice to hear that it works for others too!
What DVB standard do you use? (like DVB-C, DVB-S)
--sid-experimental seemed to block proper tuning for a DVB-S user.
(that's why I did the --sid-experimental thing, so he would not be affected by the new code)
I'm on DVB-C

Ubuntu 14.04.1
Kernel 3.13.11.8 (compiled manually with patch)
Latest ffdecsawrapper (commit 714)
Latest mythtv 0.27

With option --sid-experimental (and default --daemon) tuning is very fast and solve multirec problem for my system!!!

There has been one case of the master branch causing problems. Of the known results from a few users, including myself, report a subtle improvement with master. I will keep this on master unless I hear of more negative results.

Please share experiences; good or bad!

Changed to use the master branch of FFdecsawrapper as default for now as it is even better than stable. As bas-t mentioned in the previous comment, master is now based on sasc-ng ver 620 codebase instead of ver 570 along with other improvements.

hi p-we,
I just added a new version of FFdecsawrapper, based on rev 620 from the old vdr sasc repo. It compiles and runs OK (on first tests). If you want to, test this one and give me feedback.

It is in the new 'master' branch.

Added --tsbuffer=32 to configure. This is better than the standard 4 if you have alot of tuners

Well, it is possible to combine Endriss sourses with official TBS drivers.
You wil have to backport all of the drivers in the Endriss sources to the ancient v4l API that is used by the official TBS drivers though. If you can, I want you to teach me how to do that!

Combining Endriss v4l branch with TBS drivers is only possible when you are using 6680, 6281 and/or 6285 (the latter two in DVB-C mode only). And with a considerable amount of knowlege on how to do so. So don't bother trying.

well, I do have another adapter, which is not in use, but consumes one of the dvb devices + a loopback. So need to up the amount of dvb adapters to >8. I used that adapter before, and that actually proves the the 16 adapters are available, since I had 10 working devices. (5+5 loopback). I will build a custom kernel, but not on this box. This box is also hosting other services, as wel as a ZFS file system hosting all my data..Dont want to risk that, since I never built a kernel, and may be caught by surprise by something I can't fix. So a new box will go on order soon. Any idea how to combine the TBS tree drivers with the Endriss driver tree? Need one driver from each, also have a Digital Device double duo flex S2 laying around..

Another thing: if you used the old tbsinstall script, you should remove the /lib/modules/`uname -r`/updates/tbs dir yourself

Correction: I misread your info. It seems that you only have one quad adapter.
If this is true, you don't have to recompile your kernel. You just should run the updated tbs script without any options. So just: ./tbsinstall

Sinse you are running Ubuntu, recompile the kernel using

https://github.com/bas-t/tbs-intree/wiki/HOW-TO-%28Ubuntu-Trusty%29

You can omit the Add the TBS drivers to the build system. section, but make sure you set CONFIG_MAX_DVB_ADAPTERS=16

Reboot and run the updated tbs script: ./tbsinstall --adapters=16

You should not use a upstart script for FFdecsawrapper, use a oldschool /etc/init.d/ffdecsawrapper script

6985 quad dvb-s2. Was not supported in the kernel 3.13 in Ubuntu.

What kind of TBS adapters do you own?

Some recordings were running on the same loopback adapter. Since they were delivered through the same transponder/mux. (like NED1 and NED2). From my memory one adapter was recording 4 streams, and 2 other adapters each 2. The last one unused.

Best practice is to recompile the kernel as well for 16 dvb devices.
BTW, the tbs script is updated yesterday.

Yes, recompiled modules for 16 dvb devices. Using the TBS tree, and set for 16 devices. Used the documentation on http://www.lursen.org/wiki/V4l_and_ffdecsawrapper#Get_the_source.2C_configure_and_compile_it to patch( prior to compile) and compile (compile using the script)

John-K,
Are these 8 recordings based on 8 loopback adaptors? If so, have you compiled your kernel and changed standard # of DVB adaptors from 8 to 16? If not, FFdecsawrapper will try to create 8 foldback tuners even if the kernel is not setup for more than 8, and they do seem to be there but fail.

forgot to run a ps aux.. not getting an error message after restarting the service, so it must still be there, not consuming any cpu.. thats for tomorrow

Yes, I thought it was weird. but ffdecsawrapper disappeared, leaving what I think were as much orphans as I had recordings ongoing. Logfiles still kept on running, but output to myth went black. I will try to reproduce it. below idle, 1,2,4 and 8 recordings. At 8 ffdecsawrapper crashes, and disappears.

idle:
top - 00:29:36 up 1 day, 5:10, 1 user, load average: 0.07, 0.15, 0.14
Tasks: 283 total, 2 running, 281 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0.7 us, 2.5 sy, 0.3 ni, 96.5 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem: 3957268 total, 3537352 used, 419916 free, 114996 buffers
KiB Swap: 4103164 total, 103256 used, 3999908 free. 291676 cached Mem

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
4170 mythtv 23 3 2173988 49012 1052 S 10.6 1.2 193:35.30 ffdecsawrapper
4253 mythtv 20 0 5090676 76720 9052 S 7.6 1.9 132:15.99 mythbackend

one recording, no commflagging:
top - 00:30:55 up 1 day, 5:12, 1 user, load average: 0.19, 0.16, 0.14
Tasks: 286 total, 1 running, 285 sleeping, 0 stopped, 0 zombie
%Cpu(s): 1.0 us, 3.2 sy, 0.8 ni, 91.2 id, 3.6 wa, 0.3 hi, 0.0 si, 0.0 st
KiB Mem: 3957268 total, 3640004 used, 317264 free, 115356 buffers
KiB Swap: 4103164 total, 103120 used, 4000044 free. 292588 cached Mem

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
4170 mythtv 23 3 2173988 49020 1052 S 13.9 1.2 193:43.96 ffdecsawrapper
4253 mythtv 20 0 5227960 173220 9304 S 9.3 4.4 132:22.97 mythbackend

two recordings, no commflagging:
top - 00:32:16 up 1 day, 5:13, 1 user, load average: 0.21, 0.17, 0.15
Tasks: 286 total, 2 running, 284 sleeping, 0 stopped, 0 zombie
%Cpu(s): 1.5 us, 3.5 sy, 1.4 ni, 89.8 id, 3.4 wa, 0.3 hi, 0.0 si, 0.0 st
KiB Mem: 3957268 total, 3647400 used, 309868 free, 115548 buffers
KiB Swap: 4103164 total, 102488 used, 4000676 free. 292768 cached Mem

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
4170 mythtv 23 3 2173988 49020 1052 S 17.6 1.2 193:56.44 ffdecsawrapper
4253 mythtv 20 0 5260744 173332 9320 S 11.9 4.4 132:31.37 mythbackend

4 recordings, no commflagging:
top - 00:33:40 up 1 day, 5:14, 1 user, load average: 0.32, 0.23, 0.17
Tasks: 287 total, 3 running, 284 sleeping, 0 stopped, 0 zombie
%Cpu(s): 2.4 us, 4.1 sy, 3.6 ni, 85.4 id, 4.1 wa, 0.4 hi, 0.0 si, 0.0 st
KiB Mem: 3957268 total, 3720152 used, 237116 free, 115716 buffers
KiB Swap: 4103164 total, 101292 used, 4001872 free. 293144 cached Mem

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
4170 mythtv 23 3 2198576 49020 1052 S 26.6 1.2 194:13.77 ffdecsawrapper
4253 mythtv 20 0 5398028 269652 9364 S 17.3 6.8 132:43.96 mythbackend

8 recordings, no commflagging:
top - 00:35:44 up 1 day, 5:16, 1 user, load average: 0.47, 0.28, 0.19
Tasks: 287 total, 2 running, 285 sleeping, 0 stopped, 0 zombie
%Cpu(s): 5.9 us, 5.4 sy, 7.3 ni, 77.4 id, 3.5 wa, 0.5 hi, 0.0 si, 0.0 st
KiB Mem: 3957268 total, 3783532 used, 173736 free, 110312 buffers
KiB Swap: 4103164 total, 102764 used, 4000400 free. 276332 cached Mem

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
4170 mythtv 23 3 2354236 55520 1052 S 98.4 1.4 194:53.22 ffdecsawrapper
4253 mythtv 20 0 5617272 375216 9388 S 30.6 9.5 133:11.12 mythbackend

and after this i have no ffdecsawrapper anymore in top but:

1309 root 39 19 0 0 0 S 0.3 0.0 0:00.39 /-1609628992
1326 root 39 19 0 0 0 S 0.3 0.0 0:03.44 /-1609628992
1327 root 39 19 0 0 0 S 0.3 0.0 0:05.51 /-1609628992
1328 root 39 19 0 0 0 S 0.3 0.0 0:05.16 /-1609628992
1329 root 39 19 0 0 0 S 0.3 0.0 0:05.83 /-1609628992
1347 root 39 19 0 0 0 S 0.3 0.0 0:01.79 /-1609628992
1348 root 39 19 0 0 0 S 0.3 0.0 0:02.22 /-1609628992
1349 root 39 19 0 0 0 S 0.3 0.0 0:02.26 /-1609628992
1351 root 39 19 0 0 0 S 0.3 0.0 0:01.77 /-2144731094
1388 root 39 19 0 0 0 S 0.3 0.0 0:03.05 /-1609628992

John,
This is weird. I also have a i5 at 3.4Ghz (with 16GB RAM) and CPU uses never gets this high unless mythbackend is transcoding something. Also FFdecsawrapper never uses more CPU than mythbackend. I haven't looked with 8 recordings at once yet though. 4 concurrent tuners uses about 12% CPU max for the whole system in my case.

Just to cover bases, are you sure you are looking at %CPU and not %RAM? Are you sure you might not be looking at mythbackend? Mythbackend can use alot of RAM if the HD Ringbuffer is set high and it uses alot of CPU if it is transcoding.

CPU usage:
ffdecsawrapper is using quite a bit of cpu power. Recording about 8-10 channels, on a backend which also hosts myth seems to be too much for my CPU (i5 on 3Gz). Myth uses 45% cpu then, ffdecsawrapper normally needs twice that....at 12 channels ffdecsawrapper disappears from "top", but the decoding seems to be ongoing. What can I do to optimise the CPU usage, any flags during compilation to set perhaps?

If this is a question whether this runs with mythtv, the answer is yes. Be prepared to spend time to get it working. No discussion about how to set it up here. See http://www.lursen.org/wiki/FFdecsawrapper_with_MythTV_and_Oscam_on_Debian/Ubuntu

It is possible to run this as mythtv.

Small change:
Changing permissions of dvbloopback module to 755 (644 before) seemed to fix an irregularity with modprobing of the dvbloopback module with my TBS card. This might also explain why earlier versions of systemd were also more consistant when Group=video was added to service file.

See bas-t's comments below. FFdecsawrapper is getting better and better. A few small changes:
1) Removed tsbuffer parameter to use default 4GB buffer
2) Removed optional parameters from ffdecsawrapper.service as systemd has become better in recent versions.

THANKS BAS-T !!!!

Hi p-we,

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.

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.

Of course I'm still on myth stable/0.26 but I intend to test it with 0.27 somewhere soon.

Meanwhile, I ask you to test this tsbuffer crap, maybe you can do with a much lower setting (or even omit setting it at all)

In a joint effort, TurboSight and I ar 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. After succesfully rolling out that one, I expect your quad card is to be addressed. I can't promise though...

Since linux 3.14, the config optimization does not report accurate FFdecsa speeds and can choose a FFdecsa mode which is not the fastest. In my case, PARALLEL_128_SSE2 with -03 is always fastest at around 1340Mbit/s but the optimization thinks it is only around 700Mbit/s and often chooses another mode. Later during the build process you can see FFdecsawrapper verify what the actual speed will be. For now you can specify the mode by adding to the configure line:

--ffdecsa_mode=PARALLEL_128_SSE2 (example, choose the one you want)

I'll get in touch with bas-T tonight and see if he knows whats going on. It's been awhile since I've talked to him anyway.

I think the change is not so much from DVB-C to DVB-S/S2, but rather from your previous adapters to the TBS ones. The increase of --tsbuffer that I pushed to ffdecsawrapper was only needed when I started to use my TBS adapters. But I'm still on a DVB-C network. However, increasing the buffersize won't hurt anyone, I think.

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.

I'm fine thank you.
I already did a new channel scan in MythTV, but this doesn't help. On the channels table i deleted "Veronica/DisneyXD HD" and after the channel scan it is created again. All values seems to be ok.
As i said before, the combination TVHeadend with OScam works fine. I don't know where to look, to solve this problem.

How are you doing Meindert?
"Could not read first 2048 bytes" is a very generic MythTV error message which happens when mythfrontend doesn't get the live-tv stream it expects. It could be many things. I seriously doubt that FFdecsawrapper is at fault. More likely that some thing is going wrong at the reception, tuning, or encryption level. Since your provider changed some channels, I'll bet the tuning parameters have changed. Running a new channel scan in mythtv-setup will probably fix it, but then you have to do a lot of work very time you run a new scan. It's a bummer. Backup mythconverg first so you can always go back.

Canaldigitaal, dutch satellite provider, replaced the channel "Veronica/DisneyXD" for "Veronica/DisneyXD HD" in Basic abo.

In MythTV i become the following error after tuning the channel: "Could not read first 2048 bytes". The tuner seems to be locked but no picture.

Could this be a problem with ffdecsawrapper?

My system is Debian testing with MythTV 0.27, ffdecsawrapper reading from oscam.

Combination TVHeadend with oscam is working for the channel "Veronica/DisneyXD HD".

OK, until kernel 2.13 hits the repo you can use this PKGBUILD file as a workaround, just replace it before yaou start the 'makepkg'
http://pastebin.com/raw.php?i=RFPtBLxQ

@p-we
I really appreciate your work here, but due to the early change to 2.13 kernel i ended up with a broken package. I have tried to modify the PKGFILE for 2.12 kernel including adding the old mutex.patch but I just don't get it up running again under 2.12. Can you provide the old version in a Tarball on some server until 2.13 is getting into stable branch? TIA

Thanks fro the files p-we. I had to change the name of the kernel patch file in the prepare function, otherwise it worked.

@agnar I PM'ed the 3.12 PKGBUILD to you. 3.13 should go in soon though
I'm going to be unable to do support for the next few weeks.

Now I can't install ffdecsawrapper because Arch Linux still has Linux 3.12 in the official repositories. Is it possible to get a version of ffdecsawrapper that works for Linux 3.12?

Small change in ffdecsawrapper.service. Added Group=video. To change:
# systemctl reenable ffdecsawrapper.service

I've provided the update for 3.13 a bit early as I will be busy in the process of moving accross the world in the next weeks.

There's some developments. With kernel 3.13, V4L lib's have changed and dvbdev.c with it, so a new mutex patch was needed. I've had some interesting results playing around with dvbdev.c on 3.13.1-2 ARCH which is now in testing. It has even run quite flashy without a patch but won't always survive a channel change or a reboot. I'm beginning to wonder if some small changes in this area could improve FFdecsawrapper altogether with the new implementation of V4L. I will look further into it when I get a chance but I'm only a hobbyist hacker, by no means do I really know what I'm doing.

Anybody interested in playing around with mutex lock/unlock parameters in dvbdev.c?

A change and a few remarks which hopefully will get some discussion:
1) I tried to get ffdecsawrapper to run as a daemon again and now it seems to work. It seems better this way. The ffdecsawrapper.service has been changed accordingly so remember to:
# systemctl reenable ffdecsawrapper.service
2) Since MythTV 0.27 changed the tuning fundamentals it has been a rollercoaster for me to get. At the present time it is my experience that the --sid-nocache parameter is once again essential for reliable tuning with MythTV.
3) The tsbuffer build config is weird. I began to question if it did anything. After alot of experimentation --tsbuffer=4 does seem to consistantly have some effect on tuning reliability over default and higher settings on both my systems.

Sorry, it seems to have been caused by a misconfiguration in cardslot.conf

Do you want to share the context?
(I think your message was intended to get help)

I'm getting 3-4 messages like this a second:
"ffdecsawrapper[18349]: [18352] ERROR (smartcard.c,949): Input/output error"

John-K,
See the notes on the provided ffdecsawrapper.conf in the package. There's a lot in there including links to Arch Build System for custom kernels just for this purpose

You don't need to remove any adapters, unless your hardware is in bad shape.
You need to recompile the kernel with max 10 adapters (or more if you need it), not dvb drivers.

In fact, if your dvb cards are supported by the kernel, you should not compile any dvb driver altogether.

I've got 8 adapers in my master backend atm, so I recompiled the kernel for 16.
No problems here, running smooth and rockstable.

Probably hitting the max dvb adapters of 8. Compiled dvb drivers with 12, but does not seem to stick. I have 5 physical adapters. Will remove one and retry.

@John-K
I'm OK on current ARCH 3.12.0-1 and 3.12.2-2 on 2 different machines. Provide logs here if they are not too long. Bas-t might want to know about them.

Otherwise try: https://aur.archlinux.org/packages/ffdecsawrapper-git-v4l
Remember to re-enstate your conf files if you do change AUR packages because it will be considered a change of package, not an update. Or re-name ffdecsawrapper-git-v4l to ffdecsawrapper-git in the PKGBUILD and you can toggle between them as upgrades.

ffdecsa wrapper crashes on 4 loop back devices.
Can provide some log data if required.

FFdecsawrapper now uses the improved optimization method standard in the config process. No --optimize_exp argument anymore.

@p-we:
Wanna play some more? Do ./configure --optimize_exp

EDIT:
according to the code, x means MB
So I'm a bit confused.

How we're getting somewhere. I compared --tsbuffer=128 to --tsbuffer=1024 (assuming that x in this case might mean kb) and I'm pretty sure there is difference. No discernable difference with 128. But, I'm getting a "c" and partial lock immediately with 1024. It goes to full lock in about 3 to 4 seconds now as well.

So I would say faster? Yes. Stable? t.b.d.

Be advised: due to some strange behaviour of the web interface of github.com that I was not aware of, I was forced to push a new stable branch.

The code is ok, no relevant changes there.

Delete your existing repo prior to compile again. This goes for all FFdecsawrapper packages.

Mweh! It does not even crash with --tsbuffer=256
There's no fun in that at all!

Maybe there is a good reason for implementing but not activating this.
When I have time, I'll try and find out.

I can top that! Tomorrow I'll be running with --tsbuffer=256
See if it crashes, fun!

I'm having a Homer Simpson kind of "dooh" moment considering I have been trying to put --tsbuffer=8 in the configuration arguments instead of the build arguments.

EDIT: Running with --tsbuffer=16 now. Tunes fine, not better per se.

BTW:

You can omit the --compiletype=release option

It defaults to 'release' for some time now, so only use the option to set compiletype to 'debug'

@Robin67

Same here, but I did not have time yet to perform tests.
The code itself should give away the purpose of this setting, maybe it is ment to use in special scenarios. But again, no time to investigate right now.

@bas-t

I compiled ffdecsawrapper with --tsbuffer as this:
./configure --compiletype=release --ffdecsa_mode=PARALLEL_128_SSE2 --tsbuffer=8

It is working, but I don't notice any difference

@boomshalek
They changed systemd apparently. When I looked into this, it seems that Wants= is probably an even better choice. So changed. Thanks for that

@blahbla77
I looked into this again and the conf, service, and RC files didn't match. Oops! Thanks for the heads up on that. I don't remember exactly what it was anymore but something was screwy in the conf ARG's as it originally was in open-sasc-ng before the systemd switch so I had to change some things to work; and they do work. The files are syntaxed correctly now.

Possible Bug:
systemd[1]: [/usr/lib/systemd/system/ffdecsawrapper.service:4] Unknown lvalue 'Needs' in section 'Unit'
Possible Fix:
replace 'Needs=' with 'Requires='

I tried --tsbuffer=8M (like the other buffer), I will omit the "M" this time and give it a try with 8.

I've got it running with --tsbuffer=8, vanilla kernel 3.11.2
Have to run some tests to decide if it improves anything

update:
ffdecsawrapper won't start/run with --tsbuffer=8. It started fine at default of 4. Still waiting to see if it is better or not.

@blahbla77
Sorry about that. I felt that the conf and log parameters should be similar in syntax; i.e. both point to a file and not one to a file and one to a directory. No worries. It'l stay that way from now on.

Gee, you don't upgrade often. I changed that a long time ago.

Hi, I just upgraded from open-sasc-ng and had to change /etc/conf.d/ffdecsawrapper - LOGDIR to LOGFILE

I'll give --tsbuffer a shot
B.T.W: those interested can try out bas-t's modified MythTV git at:
https://aur.archlinux.org/packages/mythtv-git-bas-t/

--tsbuffer is a compiletime only option
AFAIK the two buffer options coexist
According to cat /proc/meminfo using a larger tsbuffer does not do anything to vmalloc, while the other buffer option does (in a 32 bits environment, I'm not sure about a 64 bits environment).

But it is an experiment, I want to know if anybody benefits from the 'new' option.
The option itself was introduced by Leslie on 7-23-2011, but nobody bothered to make it work.
Sadly this Leslie guy seems to be untraceable, so we don't exactely know what the leading thought was. I assume he had one..

@bas-t:

is the --buffer superceded by the --tsbuffer argument? Or do they coexist and something different?

@Nede:
The difference is mostly that I did not allow any commits in this branch that seem to make Live TV function less stable. Also, the commits that I don't benefit of in general are omitted. Furthermore, I backported the Nit Other commits into this branch and I committed "OpenGL: Optimize writing packed images to pixel buffer" (#10922)

It' s not perfect, but Live TV gives you a better experience.


And now for something totaly different: TsBufferSize is now configurable in FFdecsawrapper (./configure --tsbuffer=<val>), it defaults to 4 MB. Maybe some of you want to play around with it and report back your ideal TsBufferSize.
If we reach a consencus on this, I will adjust the default behaviour accordingly.

Hi p-we! Good news!!!!!
But, original version of mythtv and the bas-t version what differences do they have???

Well, I did raise both limits up quite a bit and 0.27 has for about 1 day now been tuning good enough to keep it at 0.27. I think I'm at 7000 and 14000. Thanks Nede for that!

The even better news is that bas-t's stable/0.2x mythtv versions tune even better! Bas-t you been holding out on us Archer's here.(wink) LiveTV is particularly better once you have a full lock and a picture then it stays tuned period. I feel a mythtv-bas-t AUR package stirring inside of me.

It makes no sense to increase the value of 'tuning timeout' to 15000 or even more ms. Should the codebase of 0.27 require us to do something in this respect, doubling it to 6000 should do. (for livetv, it gets doubled for recordings anyway) If and when that is not enough, we'll have to file a bugreport.

Mind you, afaik livetv has always been a troublemaker. Sometimes it's ok, but most of the times it is not. To avoid this, I even keep a special branch for 0.26
(git clone -b stable/0.26 https://github.com/bas-t/mythtv)

As soon as the current issues with livetv are solved in 0.27 I intend to keep a special branch for this release too. (it's allready there, but it is not stable yet)

-Hi bas-t! Thanks to you instead for the new project!!! This software needed a dusting!! Keep it up!!!
-Hi p-we! You then tried to increase the "tuning timeout" in mythtv-setup? Maybe even 25000?

Nice work @Nede. It is better on my system but not solved. I get a partial lock within a second now without the --nocache option but getting a full lock is still a problem. I will have to search further.

@Nede:
Thanks for the '--sid-nocache' pointer for 0.27
It runs just fine now.

Hi p-we! 0.27 work fine!!!! I got up to 15000 ms the tuning timeout in mythtv-setup for my four adapter dvb-t and the tuning is ok!
One question: option --sid-nocache in ffdecsawrapper (and the old sasc-ng) cause serious problems in my system when in live tv i change channel (classic zapping). The lock fails and mythfrontend return in main menu with error. I delete this option and all work!!!! You don't have this problem????

Hi p-we, sorry for my broken english!!!! I have same problem with encrypted channels in dvb-t mode (italy pay-tv) but not in dvb-s2 mode (sky italy). Only in 0.27 version of mythtv on ubuntu 13.04 with my patched kernel version 3.8.30 and oscam 8920. Mythtv 0.26 with same kernel, version of ubuntu and oscam work fine!!!!

Hi Robin,
It's about time LTS bumped up. I'll be going to LTS as well. I've wondered if it would be appropiate to make a 2nd AUR for LTS or not. But you asked, I need it, that makes 2. What the heck, LTS coming up.

Anybody having trouble tuning channels with MythTV 0.27? The single FTA channel I have works fine so the loopbackadaptor seems OK. All encrypted channels get a partial lock and show the "c" but have trouble getting a true lock. I'm back to 0.26 for now.

Hi P-We,

I decided to use linux-lts for the time being, since it was just upgraded to kernel version 3.10 which suits my system perfectly and would mean less (drastic) unexpected kernel changes in the future. They are expected to maintain this kernel version for probably 2 years from now.

Would it be possible to make a ffdecsawrapper-lts version within AUR supporting this lts-kernel version 3.10. I noticed you already updated the regular ffdecsawrapper package to support 3.11 (only)

Hi P-we,
Thanks for the quick reply. I didn't realize the location had moved. It is indeed there. I did a clean install and all is working fine. I never liked the --force, so always moved the original file dvb-core.ko.gz myself first. And now noticed there was no new one replaced.... But all is perfect like this. I hope you keep this AUR alive.

Hi Robin,
I can confirm that the package does work. The location of the installed dvb-core.ko.gz has been changed to ... modules/uname -r/updates instead of replacing it in the kernel tree. The updates dir takes presidence over the kernel tree.
It is possible that uninstalling and reinstalling ffdecsawrapper might help your problem by restoring the kernel tree to original. To be sure you could also reinstall the kernel. If you do this, remember to change back your config files cardclient.conf and /etc/conf.d/ffdecswrapper as they will be saved as .pacsave.
BTW, no more pacman -U --force needed anymore after this update. You can install right click with packagekit or install via yaourt from now on.

I believe something is wrong with this latest version.
In the created package there is no installation of the patched dvb-core.ko.gz anymore (so that is when I install with using pacman -U)

FFdecsawrapper is going through some housecleaning with removal of obsolete code and therefore also some directory structure changes. PKGBUILD has changed slightly. Remove ffdecsawrapper and src directories before re-building.

Yahoo! Also discovered the value of ... /modules/`uname -r`/updates presidence function. No need to replace kernel module anymore and thus easier to install; ex. installing with yaourt with no halts.

Open-sasc-ng is being further re-developed under the new name of FFdecsawrapper. This is the new AUR package for it. Open-sasc-ng, and it's AUR, are now obsolete.
Remember to change your sasc-ng.conf file if you are still running the open-sasc-ng version. Also don't forget to:
# systemctl disable sasc-ng.service
# systemctl enable ffdecsawrapper.service

There's also 2 other FFdecsawrapper versions available:
Specifically for the TBS family of DVB cards:
https://aur.archlinux.org/packages/ffdecsawrapper-git-tbs/

Alternate, +/- experimental method using V4l GIT libs:
https://aur.archlinux.org/packages/ffdecsawrapper-git-v4l/