search

manio / vdr-plugin-dvbapi

VDR dvbapi plugin for use with OSCam
http://www.streamboard.tv/wbb2/thread.php?threadid=40060
GNU General Public License v2.0
58 stars 25 forks source link

Use libdvbcsa to replace FFdecsa #2

Closed ghost closed 11 years ago

ghost commented 12 years ago

I wonder if it would worthwhile removing FFdecsa from the source entirely, and switching to libdvbcsa, actively being developed by the VLC guys and seemingly already accepted into the debian repositories.

http://www.videolan.org/developers/libdvbcsa.html http://packages.debian.org/search?keywords=libdvbcsa

manio commented 12 years ago

It's worth to consider. I was also thinking about it :) But currently my main goal is to add support for full featured cards (dvbsddevice, dvbhddevice) and this is currently under testing...

manio commented 12 years ago

I was playing with libdvbcsa over the weekend. The results are in my libdvbcsa branch. Please give it a try :)

macmenot commented 12 years ago

manio I see from the other issue that you said "I think that libdvbcsa is more portable, but there is a bug in the code. The bug is sometimes causing the picture stall (i need to figure out- is this still a known issue with libdvbcsa branch at the moment? the problem)"

manio commented 12 years ago

Hi macmenot, yes, the problem is still there, I will dig into it when I have some time...

manio commented 12 years ago

The mentioned problem is now fixed in 4f67e09 You can give it another try :)

macmenot commented 11 years ago

I've been running with this branch for a while now and it seems to be working well.

Is it worth making libdvbcsa the default and remove FFdecsa?

manio commented 11 years ago

Good to know it is working fine for you :) Currently I am not going to definitely remove FFdecsa. More info here: http://www.oscam.to/wbb3/index.php?page=Thread&postID=120478#post120478

macmenot commented 11 years ago

OK, in which case I guess the best thing would be to move FFdecsa into its own separate github repository and then (as you say) have a Makefile switch for WITH_FFDECSA vs WITH_LIBDVBCSA

That'll make it easier for getting the deb into debian tree, as the source .tar.gz will only contain the clean code.

manio commented 11 years ago

It's worth to consider, but please also keep this thing in mind: if it gets into debian it is useless without oscam, which is not in debian (any chances to be also included?) :) Next questions is: do you maybe know if there is a public and updated FFdecsa "official" sources? Is there any?

macmenot commented 11 years ago

RE: oscam, what you say is correct. However, whereas oscam is a standalone compile, and so easily installable from PPA, VDR-plugins are dependant on vdr version, and need recompiling whenever that changes. So it makes sense to try and get them into the debian archive

macmenot commented 11 years ago

RE: 'official' FFdecsa sources, afaik there aren't any

FFdecsa was originally released by a Turkish guy (fatih89r) and it was packaged and shipped alongside vdr and vdr-sc on various softcamming forums

FFdecsa-1.0.0.tar.bz2 was the 'final' official release and can still be found around the internet. I don't think anyone makes changes to it or maintains it anymore. Although I did notice a few tweaks had been made post 1.0.0 that were present in the sc mercurial repo (see gist)

kentnielsen commented 11 years ago

I've been testing the plugin with libdvbcsa on ARM platfrom (armv5te, Kirkwood, Segate Goflex Net). With FFdecsa it's not usable, 100% CPU utilizitation, and works only with alignment fixup (echo 2 > /proc/cpu/alignment) With libdvbcsa it also works only with alignment fixup, but performance seems good. Without alignement fixup, it just logs that channel is not availabe. Would you be willing to look into it, so it would work without the alignment fixup? I'd be more than willing to provide you with logs and testing. Just let me know what you need and if it is possbile to place more debug logs for the plugin.

Linux vdr 3.3.2-kirkwood-dg #1 Mon Apr 23 17:09:27 CDT 2012 armv5tel GNU/Linux

vdr (1.7.28/1.7.28) - The Video Disk Recorder dvbapi (1.0.2) - DVBAPI type SOFTCAM

SCam cardserver v1.20-unstable_svn, build #0 (arm-linux-gnueabi-libusb-pcsc) Features : webif dvbapi debug smartreader pcsc Protocols : Readers : conax

Package: libdvbcsa1 Status: install ok installed Priority: optional Section: video Installed-Size: 132 Maintainer: Debian Multimedia Maintainers pkg-multimedia-maintainers@lists.alioth.debian.org Architecture: armel Source: libdvbcsa (1.1.0-2) Version: 1.1.0-2em1

. ...

manio commented 11 years ago

Hi, I am afraid that this is rather a question for libdvbcsa guys. I am only using the library, and if there is some alignment problem it will be rather visible in the libdvbcsa as it heavily utilizes the cpu...

kentnielsen commented 11 years ago

OK, I try to do more testing. Would you please update your libdvbcsa branch? I think I'm not able to use new oscam with this branch version.

manio commented 11 years ago

Sure, branch updated

wr35nn89 commented 11 years ago

I'd like to test dvbapi with a FF card, but it doesn't compile with dvbhddevice. Do I need any special version of dvbhddevice ? Thanks by advance !

manio commented 11 years ago

The branch is updated so the dvbhddevice changes should be in place. You need normal dvbhddevice from vdr. What problem you have exactly?

wr35nn89 commented 11 years ago

Le 11/10/2012 16:01, Mariusz Białończyk a écrit :

The branch is updated so the dvbhddevice changes should be in place. You need normal dvbhddevice from vdr. What problem you have exactly?

— Reply to this email directly or view it on GitHub https://github.com/manio/vdr-plugin-dvbapi/issues/2#issuecomment-9340863.

OK, thanks. My hddvddevice plugin was not up to date. Thanks again for your work !

ghost commented 11 years ago

my fault sorry! I got it! But i get :

user.err vdr: [3401] VNSI-Error: Can't get device for channel 49 - TNT Serie HD user.err vdr: [3326] VNSI: Client with ID 8 seems to be disconnected, removing from client list

This happens for all scrambled channels. /tmp/oscam.log stoods still no "incomming" anything from dvbapi.

vdr is 1.7.27

with 'echo 2 > /proc/cpu/alignment' as sugested here, The Key is obtained right by oscam. Xbmc say no signal. an vdr log looks like this=

user.err vdr: [3453] VNSI: Successfully switched to channel 39 - Cartoon Network HD user.err vdr: [3453] VNSI: Started streaming of channel Cartoon Network HD (timeout 10 seconds) user.err vdr: [3496] receiver on device 1 thread started (pid=3441, tid=3496) user.err vdr: [3497] TS buffer on device 1 thread started (pid=3441, tid=3497) user.err vdr: [3495] VNSI: Created stream demuxer for pid=6531 and type=8 user.err vdr: [3495] VNSI: Created stream demuxer for pid=6532 and type=1 user.err vdr: [3495] VNSI: Created stream demuxer for pid=6533 and type=1 user.err vdr: [3495] DVBAPI: 0.0 set CAM decrypt (SID 50016, caLm 4, HasCaDescriptors 1) user.err vdr: [3497] TS buffer on device 1 thread ended (pid=3441, tid=3497) user.err vdr: [3496] buffer stats: 100016 (2%) used user.err vdr: [3496] receiver on device 1 thread ended (pid=3441, tid=3496) user.err vdr: [3499] receiver on device 1 thread started (pid=3441, tid=3499) user.err vdr: [3500] TS buffer on device 1 thread started (pid=3441, tid=3500) user.err vdr: [3495] VNSI: No Signal user.err vdr: [3495] VNSI: No Signal user.err vdr: [3495] VNSI: No Signal user.err vdr: [3495] VNSI: No Signal .........

The solution feels really close! Any suggestion on this ?

manio commented 11 years ago

Are you sure you have dvbapi configured correctly on the oscam side? Is it sending keys back to VDR plugin via UDP? I don't see it in the logs.

ghost commented 11 years ago

Thanks for that really quick reply ;) I did it as i know it from ubuntu:

oscam.conf; [dvbapi] Enabled = 1 Boxtype = pc User = vdr decodeforever = 1 AU = 2

oscam.server; [reader] Label = CCcamRemote1 Protocol = cccam Device = 192.168.2.1,50000 User = jep Password = jop cccreshare = 2 ccckeepalive = 1 Group = 4

oscam.user; [account] User = vdr AU = 1 Group = 4

Oscam log: 2013/01/20 12:12:06 196ED38 c dvbapi: [ADD PID 0] CAID: 1834 ECM_PID: 19DA PROVID: 000000 2013/01/20 12:12:06 196ED38 c dvbapi: [ADD PID 1] CAID: 1861 ECM_PID: 19D7 PROVID: 000000 2013/01/20 12:12:06 196ED38 c dvbapi: [ADD PID 2] CAID: 09C7 ECM_PID: 19DB PROVID: 000000 2013/01/20 12:12:06 196ED38 c dvbapi: Found 3 ECMpids and 2 STREAMpids in PMT 2013/01/20 12:12:06 196ED38 c dvbapi: New program number: C359 (1834:C359 unknown) [pmt_list_management 3] 2013/01/20 12:12:08 196ED38 c dvbapi: Start descrambling PID #0 (CAID: 1834) 1 2013/01/20 12:12:08 196ED38 c vdr (1722&000000/0000/C359/93:D023): found (1845 ms) by cccamremote1(btun 1834) 2013/01/20 12:12:16 196ED38 c vdr (1834&000000/0000/C359/89:C072): found (1055 ms) by cccamremote1 2013/01/20 12:12:26 196ED38 c vdr (1722&000000/0000/C359/93:FBED): found (735 ms) by cccamremote1(btun 1834) 2013/01/20 12:12:37 196ED38 c vdr (1722&000000/0000/C359/93:EAD3): found (1827 ms) by cccamremote1(btun 1834) 2013/01/20 12:12:47 196ED38 c vdr (1722&000000/0000/C359/93:B71F): found (1889 ms) by cccamremote1(btun 1834) 2013/01/20 12:12:57 196ED38 c vdr (1722&000000/0000/C359/93:3924): found (1601 ms) by cccamremote1(btun 1834)

vdr log: Jan 20 12:10:39 OpenWrt user.err vdr: [2768] VNSI: Client with ID 0 connected: 192.168.137.1:55864 Jan 20 12:10:39 OpenWrt user.err vdr: [2769] VNSI: Welcome client 'XBMC Media Center' with protocol version '3' Jan 20 12:10:39 OpenWrt user.err vdr: [2757] DVBAPI: 0.0: doReply changed, reset triggered Jan 20 12:10:39 OpenWrt user.err vdr: [2757] DVBAPI: 0.0: now using CAIDs version 16843009 Jan 20 12:10:39 OpenWrt user.err vdr: [2757] DVBAPI: 0.0: status 'present' Jan 20 12:10:40 OpenWrt user.err vdr: [2757] DVBAPI: 0.0: status 'reset' Jan 20 12:10:40 OpenWrt user.err vdr: [2757] DVBAPI: 0.0: status 'ready' Jan 20 12:10:40 OpenWrt user.err vdr: [2767] CAM 2: module ready Jan 20 12:10:40 OpenWrt user.err vdr: [2767] DVBAPI: CaInfo: 0.0 sending CA info Jan 20 12:10:41 OpenWrt user.err vdr: [2765] CAM 1: no module present Jan 20 12:10:41 OpenWrt user.err vdr: [2767] CAM 2: replies to QUERY - multi channel decryption possible Jan 20 12:10:41 OpenWrt user.err vdr: [2757] switching to channel 1 Jan 20 12:10:41 OpenWrt user.err vdr: [2757] ERROR: no usable font found for 'Sans Serif:Bold' Jan 20 12:10:41 OpenWrt user.err vdr: [2757] ERROR: no usable font found for 'Courier:Bold' Jan 20 12:10:41 OpenWrt user.err vdr: [2757] ERROR: no usable font found for 'Sans Serif' Jan 20 12:10:41 OpenWrt user.err vdr: [2757] OSD size changed to 720x480 @ 1 Jan 20 12:10:41 OpenWrt user.err vdr: [2757] ERROR: no OSD provider available - using dummy OSD!

after switching channel: Jan 20 12:12:06 OpenWrt user.err vdr: [2772] VNSI: Successfully switched to channel 37 - kabel eins HD Jan 20 12:12:06 OpenWrt user.err vdr: [2772] VNSI: Started streaming of channel kabel eins HD (timeout 10 seconds) Jan 20 12:12:06 OpenWrt user.err vdr: [2779] receiver on device 1 thread started (pid=2757, tid=2779) Jan 20 12:12:06 OpenWrt user.err vdr: [2780] TS buffer on device 1 thread started (pid=2757, tid=2780) Jan 20 12:12:06 OpenWrt user.err vdr: [2778] VNSI: Created stream demuxer for pid=6611 and type=8 Jan 20 12:12:06 OpenWrt user.err vdr: [2778] VNSI: Created stream demuxer for pid=6612 and type=1 Jan 20 12:12:06 OpenWrt user.err vdr: [2778] VNSI: Created stream demuxer for pid=6614 and type=11 Jan 20 12:12:06 OpenWrt user.err vdr: [2778] DVBAPI: 0.0 set CAM decrypt (SID 50009, caLm 4, HasCaDescriptors 1) Jan 20 12:12:06 OpenWrt user.err vdr: [2780] TS buffer on device 1 thread ended (pid=2757, tid=2780) Jan 20 12:12:06 OpenWrt user.err vdr: [2779] buffer stats: 122764 (2%) used Jan 20 12:12:06 OpenWrt user.err vdr: [2779] receiver on device 1 thread ended (pid=2757, tid=2779) Jan 20 12:12:06 OpenWrt user.err vdr: [2781] receiver on device 1 thread started (pid=2757, tid=2781) Jan 20 12:12:06 OpenWrt user.err vdr: [2782] TS buffer on device 1 thread started (pid=2757, tid=2782) Jan 20 12:12:16 OpenWrt user.err vdr: [2778] VNSI: No Signal Jan 20 12:12:26 OpenWrt user.err vdr: [2778] VNSI: No Signal Jan 20 12:12:36 OpenWrt user.err vdr: [2778] VNSI: No Signal

On this plattform its eglibc 2.11 running instead of openwrts uglibc

manio commented 11 years ago

Does the case matter in oscam.conf? I have boxtype not Boxtype. I don't know if it matters but only giving you a tip...

ghost commented 11 years ago

root@OpenWrt:/etc/config/vdr# netstat -apn Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:34890 0.0.0.0:* LISTEN 2757/vdr tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 1743/uhttpd tcp 0 0 127.0.0.1:6419 0.0.0.0:* LISTEN 2757/vdr tcp 0 0 0.0.0.0:53 0.0.0.0:* LISTEN 1790/dnsmasq tcp 0 0 0.0.0.0:21 0.0.0.0:* LISTEN 1765/vsftpd tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 1718/dropbear tcp 0 0 0.0.0.0:8888 0.0.0.0:* LISTEN 1906/oscam-bin tcp 0 0 192.168.137.42:43977 192.168.2.1:1024 ESTABLISHED 1906/oscam-bin tcp 0 0 192.168.137.42:34890 192.168.137.1:56161 ESTABLISHED 2757/vdr tcp 0 0 192.168.137.42:22 192.168.137.1:55726 ESTABLISHED 2671/dropbear tcp 0 0 192.168.137.42:34890 192.168.137.1:56167 ESTABLISHED 2757/vdr netstat: /proc/net/tcp6: No such file or directory udp 0 0 127.0.0.1:9000 0.0.0.0:* 2757/vdr udp 0 0 0.0.0.0:53 0.0.0.0:* 1790/dnsmasq udp 0 0 127.0.0.1:44484 127.0.0.1:9000 ESTABLISHED 1906/oscam-bin

i changed boxtype - no change. afaik oscam conf isnt casesensitive (ex pws) netstat says "yes Sir!" there is an udp connection ;)

This is an arm plattform btw

EDIT: Dont know if this matters, but tvheadend (latest git wit libdvbcsa) does on that same Plattform with dvbapi. Oscam config is the same as shown here. And i dont need to "echo 2 > /proc/cpu/alignment"

manio commented 11 years ago

I can't tell you more without more detailed log (increased loglevel from vdr and oscam level=128)

manio commented 11 years ago

Closing this as the libdvbcsa support is now in master. If you have other problems - please create new issue.