reported in #8 by DingoSEAD

Thanks for that.

Since it is unrelated to #8 , I opened this ticket.

When using g++ 4.8 or snapshot from 4.9 on Debian, the PARALLEL_64_MMX and PARALLEL_128_2MMX tests segfault with optimization level -O3

Don't have a clue right now.

Hi Tycho (or anyone in the know)

Trying to get ffdecsawrapper working with Intel Coffeelake which requires 4.15 using tbddtv open source drivers. Issue reproducible with gcc 6 and 7. Builds good on Debian 9 on the standard 4.9 and 4.15 kernels but later errors with dvbloopback during runtime so now looking at Ubuntu which give same build error as Arch has had for a long time. Maybe this is not a hard fix for those who know.

(I just tried to remove showioctl from makefile to see if it is an isolated problem with that plugin but it is not. It will eventually fall with a number of these 'sc' plugins so there is a lot wrong here)

If this can't be fixed easily, it would be nice to know what is actually causing this so I know what to avoid. Next I just might try to 'necrofit' of the newer intel video modules from 4.15 into Debian 4.9

g++ -Wall -D__user=  -o objs/plugin_showioctl.o -c  -DRELEASE_VERSION=\"\" -D__KERNEL_STRICT_NAMES -Idvbloopback/src -Idvbloopback/module dvbloopback/src/plugin_showioctl.c
dvbloopback/src/plugin_showioctl.c: In function ‘void demux_ioctl(parser_cmds*, poll_ll*, cmdret_t*, int*, long unsigned int, unsigned char*)’:
dvbloopback/src/plugin_showioctl.c:252:34: error: ‘DMX_KERNEL_CLIENT’ was not declared in this scope
                    (dmx->flags & DMX_KERNEL_CLIENT ? " KERNEL_CLIENT" : ""));
                                  ^~~~~~~~~~~~~~~~~
dvbloopback/src/plugin_showioctl.c:303:34: error: ‘DMX_KERNEL_CLIENT’ was not declared in this scope
                    (dmx->flags & DMX_KERNEL_CLIENT ? " KERNEL_CLIENT" : ""));
                                  ^~~~~~~~~~~~~~~~~
dvbloopback/src/plugin_showioctl.c:327:12: error: ‘DMX_GET_CAPS’ was not declared in this scope
       case DMX_GET_CAPS:
            ^~~~~~~~~~~~
dvbloopback/src/plugin_showioctl.c:327:12: note: suggested alternative: ‘DMX_OUT_TAP’
       case DMX_GET_CAPS:
            ^~~~~~~~~~~~
            DMX_OUT_TAP
dvbloopback/src/plugin_showioctl.c:330:70: error: invalid use of incomplete type ‘struct demux_ioctl(parser_cmds*, poll_ll*, cmdret_t*, int*, long unsigned int, unsigned char*)::dmx_caps’
           tmprintf("","DMX_GET_CAPS(%d): %u num:%d\n", fdptr->fd, dmx->caps,
                                                                      ^~
dvbloopback/src/plugin_showioctl.c:329:18: note: forward declaration of ‘struct demux_ioctl(parser_cmds*, poll_ll*, cmdret_t*, int*, long unsigned int, unsigned char*)::dmx_caps’
           struct dmx_caps *dmx = (struct dmx_caps*)data;
                  ^~~~~~~~
dvbloopback/src/plugin_showioctl.c:331:21: error: invalid use of incomplete type ‘struct demux_ioctl(parser_cmds*, poll_ll*, cmdret_t*, int*, long unsigned int, unsigned char*)::dmx_caps’
                  dmx->num_decoders);
                     ^~
dvbloopback/src/plugin_showioctl.c:329:18: note: forward declaration of ‘struct demux_ioctl(parser_cmds*, poll_ll*, cmdret_t*, int*, long unsigned int, unsigned char*)::dmx_caps’
           struct dmx_caps *dmx = (struct dmx_caps*)data;
                  ^~~~~~~~
dvbloopback/src/plugin_showioctl.c:334:12: error: ‘DMX_SET_SOURCE’ was not declared in this scope
       case DMX_SET_SOURCE:
            ^~~~~~~~~~~~~~
dvbloopback/src/plugin_showioctl.c:334:12: note: suggested alternative: ‘_XOPEN_SOURCE’
       case DMX_SET_SOURCE:
            ^~~~~~~~~~~~~~
            _XOPEN_SOURCE
Makefile:70: recipe for target 'objs/plugin_showioctl.o' failed
make: *** [objs/plugin_showioctl.o] Error 1

As the title says.
Have to dig into this when time permts.

Hi Tbs.
As I can see you are using TBS tuner card. I have a TBS6985 DVB-S/S2 QUAD tuner - I downloaded and installed the latest drivers from TBS site - No problem - DVB Cards shows in dmesg
After compiling and installing ffdecsawrapper - I got the module dvbloopback men my TBS card is gone.
As long as I install FFdecsawrapper/dvbloopback --> my TBS is missing after reboot and gives this error i dmesg:

[ 4.472541] TurboSight TBS6985 DVB-S2 card port0 MAC=00:22:ab:90:81:a4 [ 4.472545] DVB: registering adapter 0 frontend 0 (TurboSight TBS 6985 DVBS/S2 frontend)... [ 4.472639] DVB: registering new adapter (SAA716x dvb adapter) [ 4.597165] r8169 0000:05:00.0 enp5s0: link down [ 4.597167] r8169 0000:05:00.0 enp5s0: link down [ 4.597201] IPv6: ADDRCONF(NETDEV_UP): enp5s0: link is not ready [ 4.945345] TurboSight TBS 6985 Frontend Attaching... [ 5.026146] TurboSight TBS6985 DVB-S2 card port1 MAC=00:22:ab:90:81:a5 [ 5.026148] DVB: registering adapter 1 frontend 0 (TurboSight TBS 6985 DVBS/S2 frontend)... [ 5.026281] DVB: registering new adapter (SAA716x dvb adapter) [ 5.497338] TurboSight TBS 6985 Frontend Attaching... [ 5.578146] TurboSight TBS6985 DVB-S2 card port2 MAC=00:22:ab:90:81:a6 [ 5.578148] DVB: registering adapter 2 frontend 0 (TurboSight TBS 6985 DVBS/S2 frontend)... [ 5.578289] DVB: registering new adapter (SAA716x dvb adapter) [ 6.049339] TurboSight TBS 6985 Frontend Attaching... [ 6.130140] TurboSight TBS6985 DVB-S2 card port3 MAC=00:22:ab:90:81:a7 [ 6.130143] DVB: registering adapter 3 frontend 0 (TurboSight TBS 6985 DVBS/S2 frontend)... [ 6.925499] r8169 0000:05:00.0 enp5s0: link up [ 6.925512] IPv6: ADDRCONF(NETDEV_CHANGE): enp5s0: link becomes ready [ 45.845220] random: nonblocking pool is initialized [ 186.583792] dvbloopback: disagrees about version of symbol dvb_register_adapter [ 186.583798] dvbloopback: Unknown symbol dvb_register_adapter (err -22) [ 186.583817] dvbloopback: disagrees about version of symbol dvb_generic_open [ 186.583820] dvbloopback: Unknown symbol dvb_generic_open (err -22) [ 186.583838] dvbloopback: disagrees about version of symbol dvb_unregister_device [ 186.583841] dvbloopback: Unknown symbol dvb_unregister_device (err -22) [ 186.583857] dvbloopback: disagrees about version of symbol dvb_generic_release [ 186.583859] dvbloopback: Unknown symbol dvb_generic_release (err -22) [ 186.583902] dvbloopback: disagrees about version of symbol dvb_register_device [ 186.583904] dvbloopback: Unknown symbol dvb_register_device (err -22) [ 186.583918] dvbloopback: disagrees about version of symbol dvb_unregister_adapter [ 186.583921] dvbloopback: Unknown symbol dvb_unregister_adapter (err -22)

PS: I have my "Old" Mythtv Backend which just been reinstalled along working with dvbcards and dvbloopback interface. But I cannot make this dvb card work - Since it missing after installing FFdecsawrapper/dvbloopback - and a remove of /lib/modules/$(uname -r)/kernel/drivers/media and then reinstalling the drivers does not do the trick _ Do you have any ideas ?

Just updated both kernel and the TBS DVB S2 card v4l driver for TBS 6984 (http://www.tbsdtv.com/download/document/common/linux-tbs-drivers_150130.tar.bz2) patched with the linux-2.6.38-dvb-mutex patch.
When starting a fresh compiled (and github synced version) of ffdecsawrapper, the following error is displayed: " ERROR: could not insert 'dvbloopback': Unknown symbol in module, or unknown parameter (see dmesg)". Dmesg output: "dvbloopback: Unknown symbol dvb_usercopy (err 0)"
Running on Mythbuntu 14.04 using kernel 3.13.0-46-generic

Just a reminder to myself

Dear Bas-T,

first of all, kudos for your work! I am using it to decrypt HD channels on Astra using a purchased smart card - so I am using it to see what I have paid for on the hardware I have chosen for the task - that's how life is supposed to be.

I have problems thought, quite frequent drop-outs leading to skipped frames (more than a second missing, whole dialogues sometimes) or block artifacts. (vmalloc = 256M) and I am blank on where to start and look for a solution or even error analysis.

Now I am aware that here is not the place for support questions - can you recommend a forum where I find help?

Thanks in advance, and thanks for your work done, great job!

Zaphod

As title.

On a new kernel install, (Linux mythtv 3.13.0-51-generic #84-Ubuntu SMP Wed Apr 15 12:08:34 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux) the dvb-core.ko is installed as the folder name, rather than module, so dvbloopback and dvb-core dont exist

I just compiled ffdecsawrapper (dvbloopback) against 3.13, but needed a slightly different patch for dvbdev.c

--- a/drivers/media/dvb-core/dvbdev.c 2014-01-20 03:40:07.000000000 +0100
+++ b/drivers/media/dvb-core/dvbdev.c 2014-01-23 23:39:41.357710804 +0100
@@ -81,8 +81,11 @@
goto fail;
file->private_data = dvbdev;
replace_fops(file, new_fops);

•           if (file->f_op->open)
  

•           if (file->f_op->open) {
  

•                    mutex_unlock(&dvbdev_mutex);
                  err = file->f_op->open(inode,file);
  

•                    mutex_lock(&dvbdev_mutex);
  

•            }
          up_read(&minor_rwsem);
          mutex_unlock(&dvbdev_mutex);
          return err;
  

Hi Tycho,

Long time no see. I hope you are well. My Intel sandybeach system is getting old and bought new coffeelake which needs 4.15 or better. Still using out of tree open source TBS drivers. Please see
linux 4.15 patch.zip

Wes (p-we)

Could be that MythTV sends ambiguous commands, or FFdecsawrapper does not understand.
Refs #26

Using a 8k buffer, it claims to be up to 18% faster then SSE/SSE2

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=d764593af924930d5c15685bc5946cb943da1a55

Hi,

Seemed like I was missing the lsb_release package :)

Compiling now! Thanks.

Danny

I've been having problems with ffdecsawrapper since I upgraded my kernel and recompiled ffdecsawrapper. I'm running a stock ubuntu kernel with no external drivers of any kind and have been installing ffdecsawrapper by cloning the git repository and running the configure script.

Everything compiles ok, the kernel sources are downloaded and the kernel is patched and new modules installed. A new ffdecsawrapper is compiled and installed. After reboot everything (including mythtv) is started ok, but as soon as I activate a recording in mythtv ffdecsawrapper dies instantly!
I also end up having two empty recordings in mythtv with no file associated to them.

In ffdecsawrapper.log I have this (in the end):
Mar 12 14:09:47.988 CHANNEL: Clearing tuning cache due to switch cmd
Mar 12 14:09:48.029 frontend: Didn't read enough data
Mar 12 14:09:48.152 THREAD: Netwatcher thread ended (pid=4868, tid=-1239436248)

I've also tried the stable branch with exactly the same result....

As a last resort I tried the oldstable branch and this branch actually works with my kernel!
The recording is stable and everything works as expected with the oldstable branch...

What could be wrong?

/MH

Hi,
I think there is bug in code related to allocation of DeCsaTsBuffSize.
Looking on /sc/PLUGINS/src/device.c:

tsBuffer=new cDeCsaTSBuffer(fd_dvr,MEGABYTE(ScSetup.DeCsaTsBuffSize),CardIndex()+1,decsa,ScActive());

there is macro 'MEGABYTE'.
./sc/include/ffdecsawrapper/tools.h:#define MEGABYTE(n) ((n) * 1024 * 1024)

So setting DeCsaTsBuffSize=2048 means allocating it with 2GB not 2MB...or I do miss something?

Is there any chance to get concurrent recordings (multirec) with ffdecsawrapper to work?

Without ffdecsawrapper mythtv records multiple streams on the same transponder perfectly.
Enabling ffdecsawrapper allows only one recording at the same time. And I have got a dual tuner.
As a workaround I've configured ffdecsawrapper only to use one of the two available adapters.
So that I can use one for the free to air channels (with multirec on the same transponder),
and the other to record encrypted channels (without multirec).

Is there anyone who does multiple recordings with ffdecsawrapper?
Is there a configuration option I have to add?
Is there a special firmware I need to use?

ffdecsawrapper Log says: ** Concurrent FF recordings are NOT allowed
ffdecsawrapper Version: 1.1.8-Stable
mythbuntu (Ubuntu 12.04.4 LTS)
mystique SaTiX-S2 Dual (nGene PCI-Express Multimedia Controller)
kernel 3.2.0-60-generic

/etc/default/ffdecsawrapper
USER="ffdecsawrapper"
NUMADAPTERS="1"
DELAY="3"
JOIN="--join 1:2"
CAMDIR="/etc/ffdecsawrapper"
OPTS="--cam-budget --sid-allpid --sid-filt 20 --buffer 16M"

O_SYNC is overkill for not hard debuging tasks. Using it with ffdecsawrapper logging facility (--log used in your init scripts) causing mythtv channel switching timeouts and failures (Ubuntu 12.04.4, Mythtv 27, Intel(R) Celeron(R) CPU 847 @ 1.10GHz, 4G ram, 500G Hdd WDC WD5000BEVT) because of huge disk IO. Following patch fixing this issue and removing missleading comment. Mythtv itself do not using O_SYNC for years.

diff --git a/dvbloopback/src/forward.c b/dvbloopback/src/forward.c
index 64c45d0..0ca831d 100644
--- a/dvbloopback/src/forward.c
+++ b/dvbloopback/src/forward.c
@@ -223,9 +223,7 @@ int init_osd(int real, int virt) {
.
 int log_rotate(int report_error)
 {
-  /* http://www.gossamer-threads.com/lists/mythtv/dev/110113 */
-
-  int new_logfd = open(logfile, O_WRONLY|O_CREAT|O_APPEND|O_SYNC|O_LARGEFILE, 0664);
+  int new_logfd = open(logfile, O_WRONLY|O_CREAT|O_APPEND|O_LARGEFILE, 0664);
   if (new_logfd < 0) {
     // If we can't open the new logfile, send data to /dev/null
     if (report_error) {

When using 2 smartcards with same CAID, ffdecsawrapper can't work on second card.

In file system-common.c, function cSystemScCore::ProcessECM :
*card=smartcards.LockCard(scId); calls function in smarcard.c with takes the first card with matching scId.

The problem here is that if there is no matching ecm->provId on card, the routine diden't look for second card ..
Here code must be done for looking on each card for matching provId before selecting it and call function Decode

Hi,

Reading other issues I think you may have moved on, but I will ask anyway :-)

I think these are two diffrent issues. I was watching Canal Digitaal ( DVB-S2), on 14.04 with an updated kernel. I updated to 16.04, and all seemd ok, but I now have two I believe seperate issues.

ffdecsawrapper uses ~6% of CPU all the time on my server. I just reverted to 14.04, and it doese not, so it is probably a kernel thing (?) with
Linux mythtv 4.4.0-31-generic #50-Ubuntu SMP Wed Jul 13 00:07:12 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

Also I have lost most of the dutch channels. NPO 1 and 3, een are on the same MUX, and they decode perfectly. NPO2 and others do not.

Hopefully you have some advice ?

I need to dig through the logs and add the info below

I have stumbled on a problem which seems to be ffdecsawrapper related.
I'm using mythtv 0.27 under Linux Mint 17 XFCE (kernel 3.13) and latest ffdecsawrapper git sources.

Symptoms:
After some time (from a few minutes upto a few hours), mythtv and ffdecsawrapper start using a high CPU load.

• When watching LiveTV, the video freezes.
• When doing recordings on the backend (i.e. without running the frontend), they fail.

First, I tried all sorts of things to resolve the problem:

• Building and using the latest kernel from kernel.org (first applying the DVB patch of course)
• Using another PC (with the same DVB-S2 card)
• Using the latest mythtv, build from source
• Using the latest ffdecsawrapper, build from source
  They all show the same problem.

After spending days and late evenings debugging the mythtv and ffdecsawrapper code (I have some experience with kernel drivers and character device interfaces), I have discovered (and solved) a problem in ffdecsawrapper.

I discovered that the problem only occurs when there are transport errors in the MPEG transport stream (coming from the DVB-S2 card), i.e. when the Transport Error Indicator (TEI) is set in the MPEG transport stream header.
See http://en.wikipedia.org/wiki/MPEG_transport_stream

So I did some monitoring on the transport stream.
The TEI errors are only seen on one specific transponder, being Astra 19.2, 12721.75 (TV Vlaanderen). This is a rather busy transponder which is using a non standard symbol rate of 23500.
I don't know if this has anything to do with it dough.
At some times, about 0.1% of the packets contain a TEI error but during other parts of the day I do not see any errors at all, in which case the CPU load/freeze problem does not occur.

Anyhow, the ffdecsawrapper code should be able to cope with this but it doesn't :-)

When a packet contains such a TEI error, the PID (also a header field) is most often also invalid.
I.e. the PID in the header isn't in use by any channel in the complete tuned transponder.
Now there seems to be a flaw in the handling of unknown PID's in ffdecsawrapper.

The problem is located in process_ts() in dvblb_plugins/plugin_ffdecsa.c
In short, an encrypted packet with an invalid PID can get 'stuck' in the ringbuffer when it's at the end of the buffer, finally overflowing the ringbuffer. I can explain the details later on ...

I've modified the code a bit and now the problem is gone :-)
I would like to share this mod and contribute to the source code.

Cheers,
Tom

As documented it is not possible to use more than 8 adapter without modifying your drivers. I did this since I want to use 12 cards. I set the maximum of cards in the driver to 64 cards. All cards are detected so that part works. The problem is now that I would like to use a loopback on every card, hower the default maximum for the loopback is set at 8. Changing this in the module will allow for more loopbacks to be present. The total number of adapter recognized by the kernel is now indeed 24.

The problem is that when ffdecsawrapper is started using multiple joins between card and loopback the process will stop with the error "Could not connect to loopback device 20"

Using less than 9 joins will run fine and will also descramble the streams so it looks like somewhere there is some check somewhere for the max number of adapter.

Could you tell me what might be wrong?

Kind regards,

Simon Wamelink

Logging info:

3.14-0.bpo.1-amd64 #1 SMP Debian 3.14.4-1~bpo70+1 (2014-05-14) x86_64 GNU/Linux

  /usr/src/ffdecsawrapper# ffdecsawrapper -d 0xFFFFFFFF -j 0:12 -j 1:13 -j 2:14 -j 3:15 -j 4:16 -j 5:17 -j 6:18 -j 7:19 -j 8:20 -j 9:21 -j 10:22 -j 11:23
May 28 23:32:15.252 : Version: 2.0.1-Stable
May 28 23:32:15.253 CAM: initializing plugin: SoftCam (2.0.1-Stable): A software emulated CAM
*snip*
May 28 23:30:12.149 : Could not connect to loopback device 20
May 28 23:30:12.149 : Are you sure you have loaded the dvbloopback module
May 28 23:30:12.149 : properly and/or used the correct values to the '-j' switch

/usr/src/ffdecsawrapper# ffdecsawrapper -i
0: STV0367 DVB-C DVB-T
1: STV0367 DVB-C DVB-T
10: CXD2837 DVB-C DVB-T/T2
11: CXD2837 DVB-C DVB-T/T2
2: STV0367 DVB-C DVB-T
3: STV0367 DVB-C DVB-T
4: CXD2843 DVB-C/C2 DVB-T/T2
5: CXD2843 DVB-C/C2 DVB-T/T2
6: CXD2843 DVB-C/C2 DVB-T/T2
7: CXD2843 DVB-C/C2 DVB-T/T2
8: CXD2843 DVB-C/C2 DVB-T/T2
9: CXD2843 DVB-C/C2 DVB-T/T2

/usr/src/ffdecsawrapper# mumudvb -l
MuMuDVB Version 1.7.2_20130525_master
 --- Build information ---
Built without CAM support.
Built with SCAM support.
Built without transcoding support.
Built with ATSC support.
Built with support for DVB API Version 5.4.
Built with support for DVB-T2.
---------
Originally based on dvbstream 0.6 by (C) Dave Chapman 2001-2004
Released under the GPL.
Latest version available from http://mumudvb.braice.net/
Project from the cr@ns (http://www.crans.org)
by Brice DUBOST ([email protected])

Info:  DVB:  ==================================
Info:  DVB:          DVB CARDS LISTING
Info:  DVB:  ==================================
Info:  DVB:  =========== Card 0 - Tuner 0 ===========
Info:  DVB:   Frontend : STV0367 DVB-C DVB-T
Info:  DVB:   Cable (DVB-C) card
Info:  DVB:   Frequency: 47125 kHz to 865000 kHz
Info:  DVB:   Symbol rate: 870 k symbols/s to 11700 k symbols/s 
Info:  DVB:  
Info:  DVB:  =========== Card 1 - Tuner 0 ===========
Info:  DVB:   Frontend : STV0367 DVB-C DVB-T
Info:  DVB:   Cable (DVB-C) card
Info:  DVB:   Frequency: 47125 kHz to 865000 kHz
Info:  DVB:   Symbol rate: 870 k symbols/s to 11700 k symbols/s 
Info:  DVB:  
Info:  DVB:  =========== Card 2 - Tuner 0 ===========
Info:  DVB:   Frontend : STV0367 DVB-C DVB-T
Info:  DVB:   Cable (DVB-C) card
Info:  DVB:   Frequency: 47125 kHz to 865000 kHz
Info:  DVB:   Symbol rate: 870 k symbols/s to 11700 k symbols/s 
Info:  DVB:  
Info:  DVB:  =========== Card 3 - Tuner 0 ===========
Info:  DVB:   Frontend : STV0367 DVB-C DVB-T
Info:  DVB:   Cable (DVB-C) card
Info:  DVB:   Frequency: 47125 kHz to 865000 kHz
Info:  DVB:   Symbol rate: 870 k symbols/s to 11700 k symbols/s 
Info:  DVB:  
Info:  DVB:  =========== Card 4 - Tuner 0 ===========
Info:  DVB:   Frontend : CXD2843 DVB-C/C2 DVB-T/T2
Info:  DVB:   Cable (DVB-C) card
Info:  DVB:   Frequency: 47125 kHz to 865000 kHz
Info:  DVB:   Symbol rate: 870 k symbols/s to 11700 k symbols/s 
Info:  DVB:  
Info:  DVB:  =========== Card 5 - Tuner 0 ===========
Info:  DVB:   Frontend : CXD2843 DVB-C/C2 DVB-T/T2
Info:  DVB:   Cable (DVB-C) card
Info:  DVB:   Frequency: 47125 kHz to 865000 kHz
Info:  DVB:   Symbol rate: 870 k symbols/s to 11700 k symbols/s 
Info:  DVB:  
Info:  DVB:  =========== Card 6 - Tuner 0 ===========
Info:  DVB:   Frontend : CXD2843 DVB-C/C2 DVB-T/T2
Info:  DVB:   Cable (DVB-C) card
Info:  DVB:   Frequency: 47125 kHz to 865000 kHz
Info:  DVB:   Symbol rate: 870 k symbols/s to 11700 k symbols/s 
Info:  DVB:  
Info:  DVB:  =========== Card 7 - Tuner 0 ===========
Info:  DVB:   Frontend : CXD2843 DVB-C/C2 DVB-T/T2
Info:  DVB:   Cable (DVB-C) card
Info:  DVB:   Frequency: 47125 kHz to 865000 kHz
Info:  DVB:   Symbol rate: 870 k symbols/s to 11700 k symbols/s 
Info:  DVB:  
Info:  DVB:  =========== Card 8 - Tuner 0 ===========
Info:  DVB:   Frontend : CXD2843 DVB-C/C2 DVB-T/T2
Info:  DVB:   Cable (DVB-C) card
Info:  DVB:   Frequency: 47125 kHz to 865000 kHz
Info:  DVB:   Symbol rate: 870 k symbols/s to 11700 k symbols/s 
Info:  DVB:  
Info:  DVB:  =========== Card 9 - Tuner 0 ===========
Info:  DVB:   Frontend : CXD2843 DVB-C/C2 DVB-T/T2
Info:  DVB:   Cable (DVB-C) card
Info:  DVB:   Frequency: 47125 kHz to 865000 kHz
Info:  DVB:   Symbol rate: 870 k symbols/s to 11700 k symbols/s 
Info:  DVB:  
Info:  DVB:  =========== Card 10 - Tuner 0 ===========
Info:  DVB:   Frontend : CXD2837 DVB-C DVB-T/T2
Info:  DVB:   Cable (DVB-C) card
Info:  DVB:   Frequency: 47125 kHz to 865000 kHz
Info:  DVB:   Symbol rate: 870 k symbols/s to 11700 k symbols/s 
Info:  DVB:  
Info:  DVB:  =========== Card 11 - Tuner 0 ===========
Info:  DVB:   Frontend : CXD2837 DVB-C DVB-T/T2
Info:  DVB:   Cable (DVB-C) card
Info:  DVB:   Frequency: 47125 kHz to 865000 kHz
Info:  DVB:   Symbol rate: 870 k symbols/s to 11700 k symbols/s 
Info:  DVB:  
Info:  DVB:  =========== Card 12 - Tuner 1 ===========
Info:  DVB:   Frontend : CXD2837 DVB-C DVB-T/T2
Info:  DVB:   Cable (DVB-C) card
Info:  DVB:   Frequency: 47125 kHz to 865000 kHz
Info:  DVB:   Symbol rate: 870 k symbols/s to 11700 k symbols/s 
Info:  DVB:  
ERRO:  DVB:  FRONTEND DEVICE: /dev/dvb/adapter12/frontend0 : Bad address
ERRO:  DVB:  FE_GET_INFO: Bad file descriptor 
Info:  DVB:  =========== Card 13 - Tuner 1 ===========
Info:  DVB:   Frontend : CXD2837 DVB-C DVB-T/T2
Info:  DVB:   Cable (DVB-C) card
Info:  DVB:   Frequency: 47125 kHz to 865000 kHz
Info:  DVB:   Symbol rate: 870 k symbols/s to 11700 k symbols/s 
Info:  DVB:  
ERRO:  DVB:  FRONTEND DEVICE: /dev/dvb/adapter13/frontend0 : Bad address
ERRO:  DVB:  FE_GET_INFO: Bad file descriptor 
Info:  DVB:  =========== Card 14 - Tuner 1 ===========
Info:  DVB:   Frontend : CXD2837 DVB-C DVB-T/T2
Info:  DVB:   Cable (DVB-C) card
Info:  DVB:   Frequency: 47125 kHz to 865000 kHz
Info:  DVB:   Symbol rate: 870 k symbols/s to 11700 k symbols/s 
Info:  DVB:  
ERRO:  DVB:  FRONTEND DEVICE: /dev/dvb/adapter14/frontend0 : Bad address
ERRO:  DVB:  FE_GET_INFO: Bad file descriptor 
Info:  DVB:  =========== Card 15 - Tuner 1 ===========
Info:  DVB:   Frontend : CXD2837 DVB-C DVB-T/T2
Info:  DVB:   Cable (DVB-C) card
Info:  DVB:   Frequency: 47125 kHz to 865000 kHz
Info:  DVB:   Symbol rate: 870 k symbols/s to 11700 k symbols/s 
Info:  DVB:  
ERRO:  DVB:  FRONTEND DEVICE: /dev/dvb/adapter15/frontend0 : Bad address
ERRO:  DVB:  FE_GET_INFO: Bad file descriptor 
Info:  DVB:  =========== Card 16 - Tuner 1 ===========
Info:  DVB:   Frontend : CXD2837 DVB-C DVB-T/T2
Info:  DVB:   Cable (DVB-C) card
Info:  DVB:   Frequency: 47125 kHz to 865000 kHz
Info:  DVB:   Symbol rate: 870 k symbols/s to 11700 k symbols/s 
Info:  DVB:  
ERRO:  DVB:  FRONTEND DEVICE: /dev/dvb/adapter16/frontend0 : Bad address
ERRO:  DVB:  FE_GET_INFO: Bad file descriptor 
Info:  DVB:  =========== Card 17 - Tuner 1 ===========
Info:  DVB:   Frontend : CXD2837 DVB-C DVB-T/T2
Info:  DVB:   Cable (DVB-C) card
Info:  DVB:   Frequency: 47125 kHz to 865000 kHz
Info:  DVB:   Symbol rate: 870 k symbols/s to 11700 k symbols/s 
Info:  DVB:  
ERRO:  DVB:  FRONTEND DEVICE: /dev/dvb/adapter17/frontend0 : Bad address
ERRO:  DVB:  FE_GET_INFO: Bad file descriptor 
Info:  DVB:  =========== Card 18 - Tuner 1 ===========
Info:  DVB:   Frontend : CXD2837 DVB-C DVB-T/T2
Info:  DVB:   Cable (DVB-C) card
Info:  DVB:   Frequency: 47125 kHz to 865000 kHz
Info:  DVB:   Symbol rate: 870 k symbols/s to 11700 k symbols/s 
Info:  DVB:  
ERRO:  DVB:  FRONTEND DEVICE: /dev/dvb/adapter18/frontend0 : Bad address
ERRO:  DVB:  FE_GET_INFO: Bad file descriptor 
Info:  DVB:  =========== Card 19 - Tuner 1 ===========
Info:  DVB:   Frontend : CXD2837 DVB-C DVB-T/T2
Info:  DVB:   Cable (DVB-C) card
Info:  DVB:   Frequency: 47125 kHz to 865000 kHz
Info:  DVB:   Symbol rate: 870 k symbols/s to 11700 k symbols/s 
Info:  DVB:  
ERRO:  DVB:  FRONTEND DEVICE: /dev/dvb/adapter19/frontend0 : Bad address
ERRO:  DVB:  FE_GET_INFO: Bad file descriptor 
Info:  DVB:  =========== Card 20 - Tuner 1 ===========
Info:  DVB:   Frontend : CXD2837 DVB-C DVB-T/T2
Info:  DVB:   Cable (DVB-C) card
Info:  DVB:   Frequency: 47125 kHz to 865000 kHz
Info:  DVB:   Symbol rate: 870 k symbols/s to 11700 k symbols/s 
Info:  DVB:  
ERRO:  DVB:  FRONTEND DEVICE: /dev/dvb/adapter20/frontend0 : Bad address
ERRO:  DVB:  FE_GET_INFO: Bad file descriptor 
Info:  DVB:  =========== Card 21 - Tuner 1 ===========
Info:  DVB:   Frontend : CXD2837 DVB-C DVB-T/T2
Info:  DVB:   Cable (DVB-C) card
Info:  DVB:   Frequency: 47125 kHz to 865000 kHz
Info:  DVB:   Symbol rate: 870 k symbols/s to 11700 k symbols/s 
Info:  DVB:  
ERRO:  DVB:  FRONTEND DEVICE: /dev/dvb/adapter21/frontend0 : Bad address
ERRO:  DVB:  FE_GET_INFO: Bad file descriptor 
Info:  DVB:  =========== Card 22 - Tuner 1 ===========
Info:  DVB:   Frontend : CXD2837 DVB-C DVB-T/T2
Info:  DVB:   Cable (DVB-C) card
Info:  DVB:   Frequency: 47125 kHz to 865000 kHz
Info:  DVB:   Symbol rate: 870 k symbols/s to 11700 k symbols/s 
Info:  DVB:  
ERRO:  DVB:  FRONTEND DEVICE: /dev/dvb/adapter22/frontend0 : Bad address
ERRO:  DVB:  FE_GET_INFO: Bad file descriptor 
Info:  DVB:  =========== Card 23 - Tuner 1 ===========
Info:  DVB:   Frontend : CXD2837 DVB-C DVB-T/T2
Info:  DVB:   Cable (DVB-C) card
Info:  DVB:   Frequency: 47125 kHz to 865000 kHz
Info:  DVB:   Symbol rate: 870 k symbols/s to 11700 k symbols/s 
Info:  DVB:  
ERRO:  DVB:  FRONTEND DEVICE: /dev/dvb/adapter23/frontend0 : Bad address
ERRO:  DVB:  FE_GET_INFO: Bad file descriptor

The following patch will reduce glitching by increasing the tolerances that the application will allow for delayed key response. I've been using this for 12 months on a 3G/GPRS connection with positive results. I would think it would be of benefit to other network connection types because there will always be occasions where ECM replies take 700ms or 1000ms to come back, due to unforseen network congestion.

diff --git a/device.c b/device.c
index 2c1a5ec..5535d76 100644
--- a/device.c
+++ b/device.c
@@ -978,10 +978,10 @@ bool cScCiAdapter::Assign(cDevice *Device, bool Query)

 #define MAX_CSA_PIDS 8192
 #define MAX_CSA_IDX  16
-#define MAX_STALL_MS 70
+#define MAX_STALL_MS 140

 #define MAX_REL_WAIT 100 // time to wait if key in used on set
-#define MAX_KEY_WAIT 500 // time to wait if key not ready on change
+#define MAX_KEY_WAIT 2000 // time to wait if key not ready on change

 #define FL_EVEN_GOOD 1
 #define FL_ODD_GOOD  2

please change

diff -u plugin_ffdecsa.c.orig plugin_ffdecsa.c
--- plugin_ffdecsa.c.orig 2015-03-08 20:27:31.222156132 +0100
+++ plugin_ffdecsa.c 2015-03-08 20:28:23.747661474 +0100
@@ -9,7 +9,9 @@
#include "plugin_ringbuf.h"
#include "plugin_getsid.h"

+extern "C" {
#include "../FFdecsa/FFdecsa.h"
+}

#define PLUGIN_ID 30
#define DBG_NAME "CSA"

As of linux-2.6.36 (I think) we are using a patch to overcome the mutex lock for fops in file->f_op->open
in dvbdev.c

While the mutex unlock/lock patch is very usefull, we should think of a different way to address this change in the linux kernel.

All other drivers (afaik) make use of the usercopy (with interruptable mutexes), why don't we?

As a reminder to myself:

CHANGE THAT TRIGGERRED THE USE OF THE PATCH (imo):

https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/patch/drivers/media/dvb/dvb-core/dvbdev.c?id=72024f1ec5164a70d84dd8cf4458fe4064a6b692

CONTENT (just to make sure that I can still read it when the above link dies):

http://pastebin.com/qr3hQ65g

POSSIBLE CLUE:

http://pastebin.com/DbadzuX2

Env: ARMv7 Processor (v7l)
Version: 1.1.7

Compiled with ffdecsa_mode=PARALLEL_64_LONG and --compiletype=debug ffdecsawrapper crash with a segfault:

Feb 1 20:19:33.763 CAM(cardclient.cccam2): got CW, current shareid 0014f577 (pending 0, EMM 0, maxecmcount=0)
Feb 1 20:19:33.764 CAM(cardclient.cccam2extra): wait returned after 1079
Feb 1 20:19:33.764 CAM(cardclient.cccam2shares): added shareid 0014f577 for 0bc5/88c0/1b4b5 status 1
Feb 1 20:19:33.764 CAM(cardclient.cccam2): got CW
Feb 1 20:19:33.765 CSA: Got command(0): E idx: 1 pid: 0 key: cf29...7a
Feb 1 20:19:33.765 CSA: Got command(0): O idx: 1 pid: 0 key: 623f...fe
Feb 1 20:19:33.765 CSA: Creating csa for rb: 0
Feb 1 20:19:33.765 CAM(core.ecm): cache add prgId=6303 source=88c0 transponder=1b4b5 ecm=bc5/80
Feb 1 20:19:33.766 CAM(core.ecm): 2.1: correct key found
Feb 1 20:19:33.766 CAM(cardclient.cccam2): 2: ECM caid 0100 prov 3311 sid 6303 pid 0bc5
Feb 1 20:19:33.767 CAM(cardclient.cccam2shares): shareid 0014f577 for 0bc5/88c0/1b4b5 status 1
Feb 1 20:19:33.767 CAM(cardclient.cccam2shares): share try list for caid 0100 prov 003311 pid 0bc5
Feb 1 20:19:33.767 CAM(cardclient.cccam2shares): shareid 0014f579 hops 2 lag 1000
Feb 1 20:19:33.768 CAM(cardclient.cccam2shares): shareid 001570d9 hops 4 lag 1000
Feb 1 20:19:33.768 CAM(cardclient.cccam2shares): shareid 001570da hops 4 lag 1000
Feb 1 20:19:33.768 CAM(cardclient.cccam2shares): shareid 001570db hops 4 lag 1000
Feb 1 20:19:33.768 CAM(cardclient.cccam2shares): shareid 001570dc hops 4 lag 1000
Feb 1 20:19:33.768 CAM(cardclient.cccam2shares): shareid 001570d8 hops 4 lag 1000
Feb 1 20:19:33.769 CAM(cardclient.cccam2shares): shareid 00156da0 hops 4 lag 1000
Feb 1 20:19:33.769 CAM(cardclient.cccam2shares): shareid 00157163 hops 4 lag 1000
Feb 1 20:19:33.769 CAM(cardclient.cccam2shares): shareid 00157164 hops 4 lag 1000
Feb 1 20:19:33.769 CAM(cardclient.cccam2shares): shareid 0014f577 hops 2 + lag 1039
Feb 1 20:19:33.770 CAM(cardclient.cccam2extra): now try shareid 0014f579
Segmentation fault (core dumped)

This is the backtrace of the core dumped using gdb:

Core was generated by `ffdecsawrapper -j 2:0 -b 8M --sid-allpid --cam-budget --cam-dir /etc/ffdecsawra'.
Program terminated with signal 11, Segmentation fault.
#0 0x000a4778 in block_decypher_group(unsigned long long_, unsigned char_, unsigned char*, int) ()

(gdb) bt
#0 0x000a4778 in block_decypher_group(unsigned long long_, unsigned char_, unsigned char*, int) ()
#1 0x000beac4 in decrypt_packets(void_, unsigned char_*) ()
#2 0x00085268 in process_ts (csa=0x11f86e0,

buffer=0xb63c1c08 "G\002w\027\360\236\003n\211\344\343\353\275\320J\206\210\237\357\020\262s\317\360'\232\324qtb_m\361[\345|\330{\006\372aM$S;\266\206\342N\356\341\236\313\371\f\255\202\334Pf|\033\211\062\261\234\060pravy\237\217\357e\251\267\350\334\336\266\ri\030\266o\335Eghs@\024\034\300u\346'\321@5\035\266\371\062\236~\272ȋu\267\301n\306\302v\016\257\235\372\062=g.\322)\312\313p\224\265\364\022\372\270\300\257\221\062\243\322Q+\212\202\272\222\340\214\340\021\367\201َ\371", <incomplete sequence \343\262>, end=13160, force=0) at dvblb_plugins/plugin_ffdecsa.c:321

#3 0x00085d10 in process_ffd (msg=0x11f25c8, priority=1) at dvblb_plugins/plugin_ffdecsa.c:506
#4 0x00079900 in msg_loop (arg=0x1) at dvbloopback/src/msg_passing.c:118
#5 0xb6ed4e2c in start_thread () from /lib/libpthread.so.0
#6 0xb6b4da28 in ?? () from /lib/libc.so.6
#7 0xb6b4da28 in ?? () from /lib/libc.so.6

Backtrace stopped: previous frame identical to this frame (corrupt stack?)

I have just finished upgrading my MythTV box from Mythbuntu 12.04 to 14.04. As part of that, I moved from using the legacy version of ffdecsawrapper to the current version, so I installed it from scratch using the tbsinstall script as I am using a TBS 5922 tuner. But I ran across a problem in tbsinstall. When it tried to install the TBS driver modules, it reported an error that it could not load the saa716x_tbs_dvb driver. On checking the TBS drivers, I found that this driver is actually named saa716x_tbs-dvb. So I did a global replace of all saa716x_tbs_dvb strings in tbsinstall with saa716x_tbs-dvb and ran it again and the install worked.

I am using tbs-linux-drivers_v140819.zip.

Mythbuntu 14.04, MythTV 0.27-fixes

There was a new kernel today, so I did apt-get dist-upgrade to install it and then ran tbsinstall as usual. But after rebooting, when I tried to use LiveTV to tune to any ffdecsawrapper channel, mythbackend logged that it had sent the tuning command but the channel never tuned. So I edited tbsinstall to add this line just after the "cd ffdecsawrapper" line:

git checkout 2bd9a7e

That takes me back to the code before the commits of 26-Oct-2014. With that fix, running tbsinstall builds a version of ffdecsawrapper that again works for me. So it looks like something in those commits seriously broke ffdecsawrapper on my system.

Hi!

I'd like to have the option to pre-answer yes/no questions on the configure script by using command line parameters, so I can make the update/installation run in a script (pull from git, build, patch kernel, install, reboot).

Is that possible?

Thanks for any reply.

The recent ffdecsawrapper doesn't compile on CentOS 7 with TBS DVB-S driver. The error is:

I tried both manual compilation and the automated script for official (closed-source) TBS drivers: https://raw.githubusercontent.com/bas-t/tbsinstall/master/tbsinstall

In both cases the error is the same:

$ make
g++ -Wall -D__user= -o objs/dvbdevice.o -c -DRELEASE_VERSION="v2.0.0-22-g2399092" -D__KERNEL_STRICT_NAMES -Isc/PLUGINS/src -I./sc/include -Idvbloopback/module sc/dvbdevice.cpp
sc/dvbdevice.cpp:13:30: fatal error: libv4l1-videodev.h: No such file or directory
#include <libv4l1-videodev.h>
^
compilation terminated.
make: *** [objs/dvbdevice.o] Error 1

uname -a

Linux vertex 3.10.0-123.8.1.el7.x86_64 #1 SMP Mon Sep 22 19:06:58 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

find / -name libv4l1-videodev.h

I appreciate any help to fix this issue.

Hi,

I'm trying to use kaffeine with ffdecsawrapper, but it even does not start if ffdecsawrapper is running. Have you ever tested ffdecsawrapper with kaffeine? Is it supposed to work?

the CCCam 2 protocol does not support ECM > 256 bytes for the HDTV

Dear Tycho

First of all thanks for good job you are doing here :)

Previously I used sasc-ng for softcam. I have DVBSky S952 card using DVBSky patch for stock kernel - previously 3.9.7 and 3.13.0 at the moment and mythTV recently upgraded to 0.27 (Ubuntu 14.04 LTS).
After changes in october on NC+ transponders some channels are not descrambled ( tp 11278.36). Sometimes it works fine but it's very unreliable.
Then I found ffdecsawrapper repository and compiled as described in your wiki. Unfortunately on ffdecsawrapper the same problem can be observed. Today I even tried to rescan channels in MythTV on those transponders but nothing changed. I can see in Oscam that no ECM's are exchanged for those "unlucky" channels.
I think you can try to reproduce problem trying to tune/descramble Canal + HD Polska (SID 13020).

Let me know if you need some logs.

Best Regards

kamiKAC

Which one is the best FFdecsa or libdvbcsa ?

http://www.videolan.org/developers/libdvbcsa.html

Hello,

ffdecsawrapper works better for me than scsc-ng. Great work!

I have Sky Germany (DVB-S). In my Oscam logs I can see that when I tune to one channel ffdecsawrapper requests also the ecm for another channel on the same transponder. Is that normal behavior? I think this double-loaded my card. I'am using mythtv 0.27.

Best regards!

Hello
g++-4.7 don't exist with ubuntu 12.04 TLS , it's g++-4.6

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 :-)

Hi
i have 2 6981 tuners in my system, only the first tuner of every card is working fine with dvbloopback, the second tuner of every card gets only a lock at fta

mythtv is the media solution ;-)
Ubuntu tried with 3.11, 3.13 and 3.5, still same error

Any hints ?

Regards

Hello,

Unfortunately ffdecsawrapper segfaults as soon as i start watching any encrypted channel since i have upgraded to Kernel 4.2 (Problem also exists on Linux 4.3-rc7). Unencrypted channels are watchable without any problems.

My setup:
ArchLinux; Smartmuse Easymouse 2 (with ORF Card) using oscam. ffdecsawrapper connects with newcamd to oscam. DVB-S2 Card is a TechniSat SkyStar S2. Astra 19.2E

Maybe it has something to do with the new skystar2 kernel module since 4.2?

Backtrace:
http://pastebin.com/raw.php?i=st23t6aK

config.mak:
http://pastebin.com/raw.php?i=XC1j0NUU

On systems with upstart mythbackend starts before ffdecsawrapper is ready for use. And because of that mythbackend cannot interact with the tv-tuner. => No recordings, no live TV.

To prevent this issue I use the following upstart configurations (see down).

The interesting part is the addition of "and started ffdecsawrapper" in the "start on" line of the mythtv-backend.conf, which lets mythbackend wait before starting until ffdecsawrapper has been started.

Perhaps this is of any use for you or other users.

/etc/init/ffdecsawrapper.conf:

description "DVB Loopback adapter with FFdecsa decryption"

start on runlevel [2345]
stop  on runlevel  [016]

emits ffdecsawrapper-started
emits ffdecsawrapper-stopped

console log

respawn
respawn limit 5 60

script
    . /etc/default/ffdecsawrapper

    rmmod dvbloopback 2> /dev/null || true
    sleep $DELAY
    modprobe dvbloopback num_adapters=$NUMADAPTERS
    sleep $DELAY

    cmd="/usr/bin/ffdecsawrapper $JOIN $OPTS --cam-dir $CAMDIR"
    echo "Starting ffdecsawrapper:"
    echo "$cmd"
    exec sudo -u $USER $cmd
end script

post-start script
    #sleep until listening and ready to start mythbackend
    while [ "`netstat -lnt | grep -c 5456`" != "1" ]; do
        sleep 1s
    done
    logger "ffdecsawrapper is listening..."
    initctl emit --no-wait ffdecsawrapper-started
end script

post-stop script
    rmmod dvbloopback 2> /dev/null || true
    initctl emit --no-wait ffdecsawrapper-stopped
end script

/etc/init/mythtv-backend.conf:

# MythTV Backend service

description     "MythTV Backend"
author          "Mario Limonciello <[email protected]>"

start on (local-filesystems and net-device-up IFACE!=lo and started udev-finish and started ffdecsawrapper)
stop on runlevel [016]

#should die within 5 seconds, but we don't want data loss, so set it to 30
#before we send SIGKILL
kill timeout 30

#if we crash, but not quickly
respawn
respawn limit 2 3600

#because we're daemonizing to avoid logging to upstart log
expect fork

pre-start script 
    [ -x /usr/sbin/mysqld ] || exit 0
    for i in `seq 1 30` ; do
       /usr/bin/mysqladmin --defaults-file=/etc/mysql/debian.cnf ping >/dev/null && exit 0
       sleep .5
    done
end script

script
    test -f /etc/default/locale && . /etc/default/locale || true
    LANG=$LANG exec /usr/bin/mythbackend --syslog local7 --user mythtv --daemon
end script

In France, some pay TV are forced not to be encrypted at certain times. If you start looking at a non-encrypted channel and the coding starts , ffdecsawrapper (sasc too) stops working.
Is it possible to solve this problem?

VLC was not working with ffdecsawrapper/dvbloopback/ virtual adapter on my machine.
I was a little frustrated because VLC is a great video debuging tool and was working very well on real adapter.
I'll using debug options of both dvbloopback and ffdecsawrapper and after adding a new debug point in ffdecsawrapper i'll fond the bug.
Bug happens with both ubuntu 16 lts (32 and 64 bits and perhaps others ?) and is located in file plugin_ringbuf.c , function read_call
rb->flags is not set correctly for VLC, for Kaffeine it is.. , rb_get_bytes can't be done....

So i have done a patch in function open_call line 244:
rb->flags = fdptr->flags; to: rb->flags = fdptr->flags | O_NONBLOCK ;

now all is working fine with VLC ;)

Can you release the patch please ?

HI

I have managed to get all the code to build with what looks like no errors.

When i do /etc/init.d/ffdecsawrapper start i get the following
Can not load dvbloopback, your adapters did not initialise correct.

I have 2 cards, one is DVB-S2 on DVB-T,both dual tuner.

Adapter 0 and 1 = DVB-S2
Adapter 2 and 3 DVB-t

I have set the default file correctly i think and trying to join 0:4 and 1:5

ADAPTERS = 3 and NUMADAPTERS= 2

Any advice?

TBS brand DVB-S and DVB-C drivers are built from their own tar file of V4L. This simple patch will allow a user of TBS cards to have dvbloopback link with the correct module symbol versions. Once this patch is applied, they need to specify --dvb_dir to point to their built drivers.

./configure --dvb_dir=/root/tbs/linux-tbs-drivers/linux
make

root@satellite:~/ffdecsawrapper/contrib/ffdecsawrapper# git diff
diff --git a/contrib/ffdecsawrapper/configure b/contrib/ffdecsawrapper/configure
index 06f45c3..d0ff64e 100755
--- a/contrib/ffdecsawrapper/configure
+++ b/contrib/ffdecsawrapper/configure
@@ -445,7 +445,11 @@ fi
 # Distinguish between '3.6 or lower' and '3.7 or higher' kernels

 if test "x$dvb_path" != "x"; then
-  cp -f $dvb_path/drivers/media/dvb-core/dvbdev.h dvbloopback/module/dvbdev.h
+  if [ -e "$dvb_path/drivers/media/dvb/dvb-core/dvbdev.h" ]; then
+    cp -f $dvb_path/drivers/media/dvb/dvb-core/dvbdev.h dvbloopback/module/dvbdev.h
+  else
+    cp -f $dvb_path/drivers/media/dvb-core/dvbdev.h dvbloopback/module/dvbdev.h
+  fi
 else
   if [ $FIRST_DIGIT -eq 3 ]; then
     if [ $SECOND_DIGIT -lt 7 ]; then

Hello,

i have another Problem with one Channel.

N24HD Germany and N24HD Austria (HD+). Both channels are on the same transponder and have the same Video/Audio PIDs. Only the service id is different (http://www.satindex.de/frequenz/10773/).

I have only N24HD Germany subscribed. Sometimes ffdecswrapper requests an ecm for N24Germany and sometimes for N24Austria. So sometimes I can watch the channel, sometimes not. I can see it in the oscam webif that the requests are for the wrong channel.

I use ffdecsawrapper master and mythtv 0.27 with newcamd protocol.
I have also tested with stable branch and i changed the protocol to cccam2. Same problem.

Best regards.

I have a Hauppauge HVR-4000 dvb card and it has a DVB-T and a DVB-S receiver. it shows up as /dev/dvb/adaptor0/ with two frontends 0 and 1. My problem is that ffdecsawrapper shows in the end of the log file that it start threads at frontend1 and this is the DVB-T receiver, I would like it to be joined with frontend0 instead. Is it possible to choose what frontend ffdecsawrapper is joining with? Or is it something that I have overlooked?

Adding the following code to init.d script?

# Check if MythTv sym link exist since MythTv repo updates remove it
if ! test -e /etc/init.d/mythtv-backend; then
    ln -s /lib/init/upstart-job /etc/init.d/mythtv-backend
    echo "Created symoblic link in /etc/init.d for mythbackend to up-start job"
fi

Well, title says it all.

While it is more versatile and performs better then the old code, it is not up to date.

More specific: FFdecsawrapper does not support 2.x or even lower kernels. I might be wrong, but AFAIK no 3.x kernel is compiled with gcc/g++ version 4.1 or lower. So we allways use compiler's 'native' flags.

The script I imported was last updated in 2011. Meaning that a lot of old kernels, built with ancient gcc/g++ versions had to be supported. If old gcc/g++ versions did not know about specific cpu features, the script had to provide proper gcc/g++ compiling flags.

Nowadays we smile when looking at that, like "oh gush, our grandparents had a hard time back then"

So strip all of that and make the script mean and lean again.

Hello,

I don't know if this is the correct place to ask, but I cannot get ffdecsawrapper to run on my machine.
I am trying to put it between my hdhomerun and mythtv, but it freezes as soon as a process tries to access the loopback device.

I have tested it with me-tv, and it works if I restrict the app on the "physical" device, but not on the loopback.
If I keep the app running accessing the loopback, I see this in the syslog around 2 minutes later:

Apr 22 23:30:31 myth-vm kernel: [13920.116212] INFO: task ffdecsawrapper:9445 blocked for more than 120 seconds.
Apr 22 23:30:31 myth-vm kernel: [13920.116223] Tainted: G OE 3.16.0-34-generic #47~14.04.1-Ubuntu
Apr 22 23:30:31 myth-vm kernel: [13920.116226] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Apr 22 23:30:31 myth-vm kernel: [13920.116231] ffdecsawrapper D ffff880123c130c0 0 9445 1 0x00000000
Apr 22 23:30:31 myth-vm kernel: [13920.116239] ffff8800b638bb90 0000000000000086 ffff8800b63f28c0 ffff8800b638bfd8
Apr 22 23:30:31 myth-vm kernel: [13920.116246] 00000000000130c0 00000000000130c0 ffffffff81c1a480 ffffffffc06eb080
Apr 22 23:30:31 myth-vm kernel: [13920.116252] ffffffffc06eb084 ffff8800b63f28c0 00000000ffffffff ffffffffc06eb088
Apr 22 23:30:31 myth-vm kernel: [13920.116258] Call Trace:
Apr 22 23:30:31 myth-vm kernel: [13920.116276] [] schedule_preempt_disabled+0x29/0x70
Apr 22 23:30:31 myth-vm kernel: [13920.116284] [] __mutex_lock_slowpath+0xd5/0x1d0
Apr 22 23:30:31 myth-vm kernel: [13920.116291] [] mutex_lock+0x1f/0x2f
Apr 22 23:30:31 myth-vm kernel: [13920.116304] [] dvb_device_open+0x22/0xf0 [dvb_core]
Apr 22 23:30:31 myth-vm kernel: [13920.116312] [] chrdev_open+0x9f/0x1d0
Apr 22 23:30:31 myth-vm kernel: [13920.116319] [] do_dentry_open+0x1ff/0x350
Apr 22 23:30:31 myth-vm kernel: [13920.116324] [] ? cdev_put+0x30/0x30
Apr 22 23:30:31 myth-vm kernel: [13920.116330] [] vfs_open+0x49/0x50
Apr 22 23:30:31 myth-vm kernel: [13920.116337] [] do_last+0x564/0x1240
Apr 22 23:30:31 myth-vm kernel: [13920.116344] [] ? link_path_walk+0x71/0x8a0
Apr 22 23:30:31 myth-vm kernel: [13920.116352] [] ? apparmor_file_alloc_security+0x5b/0x180
Apr 22 23:30:31 myth-vm kernel: [13920.116358] [] path_openat+0xbb/0x670
Apr 22 23:30:31 myth-vm kernel: [13920.116364] [] ? wake_futex+0x66/0x90
Apr 22 23:30:31 myth-vm kernel: [13920.116370] [] ? futex_wake_op+0x312/0x530
Apr 22 23:30:31 myth-vm kernel: [13920.116376] [] do_filp_open+0x3a/0x90
Apr 22 23:30:31 myth-vm kernel: [13920.116383] [] ? __alloc_fd+0xa7/0x130
Apr 22 23:30:31 myth-vm kernel: [13920.116390] [] do_sys_open+0x129/0x280
Apr 22 23:30:31 myth-vm kernel: [13920.116397] [] SyS_open+0x1e/0x20
Apr 22 23:30:31 myth-vm kernel: [13920.116403] [] system_call_fastpath+0x1a/0x1f

The ffdecsawrapper log don't say much:

Apr 22 23:20:32.405 CAM(core.load): ** Conax (pri -10)
Apr 22 23:20:32.405 CAM(core.load): ** Cardclient (pri -15)
Apr 22 23:20:32.414 THREAD: SC housekeeper thread started (pid=9436, tid=140573548549888)
Apr 22 23:20:33.417 frontend: Starting thread on /dev/dvb/adapter4/frontend1
The thread scheduling parameters indicate:
policy = 0
priority = 0
Apr 22 23:20:33.417 demux: Starting thread on /dev/dvb/adapter4/demux1
The thread scheduling parameters indicate:
policy = 0
priority = 0
Apr 22 23:20:33.417 dvr: Starting thread on /dev/dvb/adapter4/dvr1
The thread scheduling parameters indicate:
policy = 0
priority = 0
Apr 22 23:20:34.433 frontend: Starting thread on /dev/dvb/adapter5/frontend1
The thread scheduling parameters indicate:
policy = 0
priority = 0
Apr 22 23:20:34.434 dvr: Starting thread on /dev/dvb/adapter5/dvr1
The thread scheduling parameters indicate:
policy = 0
priority = 0
Apr 22 23:20:34.436 demux: Starting thread on /dev/dvb/adapter5/demux1
The thread scheduling parameters indicate:
policy = 0
priority = 0
Apr 22 23:20:35.452 frontend: Starting thread on /dev/dvb/adapter6/frontend1
The thread scheduling parameters indicate:
policy = 0
priority = 0
Apr 22 23:20:35.452 dvr: Starting thread on /dev/dvb/adapter6/dvr1
The thread scheduling parameters indicate:
policy = 0
priority = 0
Apr 22 23:20:35.452 demux: Starting thread on /dev/dvb/adapter6/demux1
The thread scheduling parameters indicate:
policy = 0
priority = 0
Apr 22 23:20:36.467 frontend: Starting thread on /dev/dvb/adapter7/frontend1
The thread scheduling parameters indicate:
policy = 0
priority = 0
Apr 22 23:20:36.468 demux: Starting thread on /dev/dvb/adapter7/demux1
The thread scheduling parameters indicate:
policy = 0
priority = 0
Apr 22 23:20:36.468 dvr: Starting thread on /dev/dvb/adapter7/dvr1
The thread scheduling parameters indicate:
policy = 0
priority = 0
Apr 22 23:20:36.468 : Listening on port 5456

I am currently trying to run this on a mythbuntu up to date (kernel 3.16.0.34) and tried too a kernel 3.13.0.49 (as I saw the 3.13 kernel branch referenced in the doc).
please feel free to redirect me to another place if needed. I have tried to look for a direct contact, but didn't found any.

Thanks.

I use endriss' media_build_experimental for ddbridge module and I've applied the mutex patch to 4.3.0 (but I don't think that's necessary since media_build_experimental has it's own patched dvb-core.c?). Anyway, this results in frequent lockups like other kernels before without patches.