Closed ghost closed 11 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...
I was playing with libdvbcsa over the weekend. The results are in my libdvbcsa branch. Please give it a try :)
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)"
Hi macmenot, yes, the problem is still there, I will dig into it when I have some time...
The mentioned problem is now fixed in 4f67e09 You can give it another try :)
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?
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
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.
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?
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
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)
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
. ...
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...
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.
Sure, branch updated
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 !
The branch is updated so the dvbhddevice changes should be in place. You need normal dvbhddevice from vdr. What problem you have exactly?
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 !
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 ?
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.
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
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...
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"
I can't tell you more without more detailed log (increased loglevel from vdr and oscam level=128)
Closing this as the libdvbcsa support is now in master. If you have other problems - please create new issue.
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