vdr

vdr@linuxtv.org

2 participants
6731 discussions

vdr-plugin-dvbapi, howto connect to oscam?
by cedric.dewijs＠telfort.nl 25 Dec '13

25 Dec '13

Hi All, I am trying to connect vdr-plugin-dvbapi to oscam. both programs are running on the D-link DNS-323 NAS. The NAS is running debian armel https://github.com/manio/vdr-plugin-dvbapi When I stream an encrypted channel into my browser, I see the following errors in /var/log/oscam/oscam.log 013/12/24 16:14:37 14F4DA8 c [DVBAPI] Receiver sends PMT command 3 for channel 001F 2013/12/24 16:14:37 14F4DA8 c [DVBAPI] Receiver wants to demux srvid 001F on adapter 0000 camask 0001 index 0000 2013/12/24 16:14:37 14F4DA8 c [ADD PID 0] CAID: 0B00 ECM_PID: 0BCB PROVID: 000000 2013/12/24 16:14:37 14F4DA8 c Found 1 ECMpids and 2 STREAMpids in PMT 2013/12/24 16:14:37 14F4DA8 c [DVBAPI] Receiver wants to demux srvid 001F on adapter 0000 camask 0001 index 0000 2013/12/24 16:14:37 14F4DA8 c New program number: 001F (0B00:001F unknown) [pmt_list_management 3] 2013/12/24 16:14:37 14F4DA8 c [DVBAPI] Demuxer #0 no suitable readers found that can be used for decoding! 2013/12/24 16:14:37 14F4DA8 c [DVBAPI] Demuxer #0 (re)starting decodingrequests on all 1 ecmpids! 2013/12/24 16:14:37 14F4DA8 c [DVBAPI] Demuxer #0 no suitable readers found that can be used for decoding! 2013/12/24 16:14:37 14F4DA8 c [DVBAPI] Demuxer #0 (re)starting decodingrequests on all 1 ecmpids! 2013/12/24 16:14:38 14F4DA8 c [DVBAPI] Demuxer #0 no suitable readers found that can be used for decoding! 2013/12/24 16:14:38 14F4DA8 c [DVBAPI] Demuxer #0 (re)starting decodingrequests on all 1 ecmpids! 2013/12/24 16:14:38 14F4DA8 c [DVBAPI] Demuxer #0 no suitable readers found that can be used for decoding! 2013/12/24 16:14:39 14F4DA8 c [DVBAPI] Demuxer #0 (re)starting decodingrequests on all 1 ecmpids! 2013/12/24 16:14:39 14F4DA8 c [DVBAPI] Demuxer #0 no suitable readers found that can be used for decoding! 2013/12/24 16:14:39 14F4DA8 c ERROR: Can't open device /dev/dvb/adapter0/ca0 (errno=2 No such file or directory And in /var/log/syslog: Dec 24 16:14:37 debian vdr: [14383] Streamdev: Accepted new client (HTTP) 192.168.31.112:58954 Dec 24 16:14:37 debian vdr: [14383] DVBAPI: 0.0 set CAM decrypt (SID 31, caLm 4, HasCaDescriptors 1) Dec 24 16:14:37 debian vdr: [14808] streamdev-livestreaming thread started (pid=14370, tid=14808) Dec 24 16:14:37 debian vdr: [14807] streamdev-writer thread started (pid=14370, tid=14807) Dec 24 16:14:37 debian vdr: [14809] receiver on device 1 thread started (pid=14370, tid=14809) Dec 24 16:14:37 debian vdr: [14810] TS buffer on device 1 thread started (pid=14370, tid=14810) Dec 24 16:14:39 debian vdr: [14383] client (HTTP) 192.168.31.112:58954 has closed connection Dec 24 16:14:39 debian vdr: [14383] streamdev-server: closing HTTP connection to 192.168.31.112:58954 Dec 24 16:14:39 debian vdr: [14808] streamdev-livestreaming thread ended (pid=14370, tid=14808) Dec 24 16:14:39 debian vdr: [14383] DVBAPI: 0.0 set CAM decrypt (SID 31, caLm 5, HasCaDescriptors 1) Dec 24 16:14:39 debian vdr: [14810] TS buffer on device 1 thread ended (pid=14370, tid=14810) Dec 24 16:14:39 debian vdr: [14809] buffer stats: 0 (0%) used Dec 24 16:14:39 debian vdr: [14809] receiver on device 1 thread ended (pid=14370, tid=14809) Dec 24 16:14:39 debian vdr: [14807] streamdev-writer thread ended (pid=14370, tid=14807) Dec 24 16:14:39 debian vdr: [14383] buffer stats: 0 (0%) used When I start VDR, I see the following in /var/log/syslog: Dec 24 16:08:51 debian vdr: [14370] VDR version 1.7.28 started Dec 24 16:08:51 debian vdr: [14370] loading plugin: /usr/lib/vdr/plugins/libvdr-dvbapi.so.1.7.28 Dec 24 16:08:51 debian vdr: [14370] loading /var/lib/vdr/setup.conf Dec 24 16:08:51 debian vdr: [14370] loading /var/lib/vdr/sources.conf Dec 24 16:08:51 debian vdr: [14370] loading /var/lib/vdr/diseqc.conf Dec 24 16:08:51 debian vdr: [14370] loading /var/lib/vdr/scr.conf Dec 24 16:08:51 debian vdr: [14370] loading /var/lib/vdr/channels.conf Dec 24 16:08:51 debian vdr: [14370] loading /var/lib/vdr/timers.conf Dec 24 16:08:51 debian vdr: [14370] loading /var/lib/vdr/commands.conf Dec 24 16:08:51 debian vdr: [14370] loading /var/lib/vdr/reccmds.conf Dec 24 16:08:51 debian vdr: [14370] loading /var/lib/vdr/svdrphosts.conf Dec 24 16:08:51 debian vdr: [14370] loading /var/lib/vdr/keymacros.conf Dec 24 16:08:52 debian vdr: [14370] DVBAPI: Probe: capturing device 0/0 (subsystem ID 00000000) Dec 24 16:08:52 debian vdr: [14370] DVBAPI: creating standard device 0/0 Dec 24 16:08:52 debian vdr: [14370] new device number 1 Dec 24 16:08:53 debian vdr: [14370] frontend 0/0 provides DVB-T with QPSK,QAM16,QAM64 ("DiBcom 7000PC") Dec 24 16:08:53 debian vdr: [14370] DVBAPI: Using software decryption on card 0/0 Dec 24 16:08:53 debian vdr: [14370] DVBAPI: SCCIAdapter: built caid table with 1 caids for 65 channels Dec 24 16:08:53 debian vdr: [14370] found 1 DVB device Dec 24 16:08:53 debian vdr: [14380] SC-CI adapter on device 0 thread started (pid=14370, tid=14380) Dec 24 16:08:53 debian vdr: [14370] initializing plugin: dvbapi (1.0.5): DVBAPI type SOFTCAM Dec 24 16:08:53 debian vdr: [14370] DVBAPI: plugin version 1.0.5 initializing (VDR 1.7.28) Dec 24 16:08:53 debian vdr: [14370] SVDRP listening on port 6419 Dec 24 16:08:53 debian vdr: [14370] starting plugin: dvbapi Dec 24 16:08:53 debian vdr: [14370] DVBAPI: plugin started Dec 24 16:08:53 debian vdr: [14370] DVBAPI: 0.0: doReply changed, reset triggered Dec 24 16:08:53 debian vdr: [14370] DVBAPI: 0.0: now using CAIDs version 16843009 Dec 24 16:08:53 debian vdr: [14370] DVBAPI: 0.0: status 'present' Dec 24 16:08:53 debian vdr: [14370] DVBAPI: 0.0: status 'reset' Dec 24 16:08:54 debian vdr: [14370] DVBAPI: 0.0: status 'ready' Dec 24 16:08:54 debian vdr: [14380] CAM 1: module ready Dec 24 16:08:54 debian vdr: [14380] DVBAPI: CaInfo: 0.0 sending CA info Dec 24 16:08:55 debian vdr: [14380] CAM 1: replies to QUERY - multi channel decryption possible Dec 24 16:08:55 debian vdr: [14370] switching to channel 1 Dec 24 16:08:55 debian vdr: [14370] CAM 1: assigned to device 1 Dec 24 16:08:55 debian vdr: [14370] DVBAPI: Forcing transfermode on card 0/0 Dec 24 16:08:55 debian vdr: [14370] setting watchdog timer to 60 seconds Dec 24 16:08:55 debian vdr: [14370] ERROR: no OSD provider available - using dummy OSD! Dec 24 16:08:56 debian vdr: [14370] max. latency time 1 seconds Dec 24 16:08:58 debian vdr: [14370] DVBAPI: Forcing transfermode on card 0/0 I have the following configuration: cat /etc/oscam/oscam.conf # main configuration [global] nice = -1 WaitForCards = 1 # logging pidfile = /var/run/oscam.pid logfile = /var/log/oscam/oscam.log usrfile = /var/log/oscam/oscamuser.log cwlogdir = /var/log/oscam/cw # monitor [monitor] port = 8988 aulow = 120 monlevel = 1 # protocols [newcamd] key = 000102030405060708090A0B0C0D port = 15050@0B00:0E030 [dvbapi] enabled = 1 au = 1 boxtype = pc user = vdr pmt_mode = 4 request_mode = 1 cat /etc/oscam/oscam.server # reader configuration [reader] label = reader1 protocol = mouse detect = CD device = /dev/ttyUSB0 group = 1 emmcache = 1,3,2 services = services1 caid = 0B00 mhz = 500 cardmhz = 500 cat /etc/oscam/oscam.services # definition of services # # format: # [name] # caid=CAID[,CAID]... # provid = provider ID[,provider ID]... # srvid = service ID[,service ID]... [services1] caid=0B00 provid=0E030 srvid= cat /etc/oscam/oscam.user # user configuration [account] user = user1 pwd = password1 monlevel = 0 uniq = 0 group = 1 au = 1 ident = 0B00:0E030 caid = 0B00 # user for group 2 with monitor access, AU enabled #[account] user = user2 pwd = password2 monlevel = 0 uniq = 0 group = 1 au = 1 ident = 0B00:0E030 caid = 0B00 What could this be? A remote PC running VDR + vdr-plugin-sc can get the keys from the NAS without problems via the newcamd protocol. Regards, Cedric

3 2

[PATCH] vdr -v ... --edit ignores -v to set videodir
by Marko Mäkelä 25 Dec '13

25 Dec '13

Hi all, I am not sure if this was reported already, but I encountered this bug when trying to edit a recording without setting up VDR: ./vdr -v /tmp/video --edit /tmp/video/Rec_name/2013-08-12.20.58.50.99.rec Without the attached patch, VDR would try to create /srv/vdr/video, and would fail to cut the recording. With the patch, VDR successfully cut the recording. The source files were in PES format, and also the new recording is in PES format. Based on a discussion from 2008, this is the expected behaviour. Is there some tool for converting old PES recordings to TS format? Marko --- vdr.c 2013-10-16 12:46:36.000000000 +0300 +++ vdr.c 2013-12-16 18:47:42.526981566 +0200 @@ -331,6 +331,7 @@ int main(int argc, char *argv[]) } break; case 'e' | 0x100: + SetVideoDirectory(VideoDirectory); return CutRecording(optarg) ? 0 : 2; case 'E': EpgDataFileName = (*optarg != '-' ? optarg : NULL); break;

2 4

vdr 2.1.2 segfaults in libc using vdr --genindex
by Lou 25 Dec '13

25 Dec '13

hi list vdr 2.1.2 segfaults in libc, as soon as I use the terminal syntax (vdr --genindex) to recreate a missing index file. Trying the same thing in a user interface (vdr-sxfe) works as planed. Here's a backtrace of what's happing: /usr/local/src/vdr/vdr-2.1.2/vdr --genindex=/var/lib/video/True_blood/At_last/2013-11-29.00.30.203-0.rec/ Speicherzugriffsfehler (Speicherabzug geschrieben) gdb /usr/local/src/vdr/vdr-2.1.2/vdr ./core Reading symbols from /usr/local/src/vdr/vdr-2.1.2/vdr...done. Loaded symbols for /lib/i686/cmov/libc.so.6 <<snip>> Core was generated by `/usr/local/src/vdr/vdr-2.1.2/vdr --genindex=/var/lib/video/True_blood/At_l'. Program terminated with signal 11, Segmentation fault. #0 0xb7496df5 in ?? () from /lib/i686/cmov/libc.so.6 (gdb) bt #0 0xb7496df5 in ?? () from /lib/i686/cmov/libc.so.6 #1 0x0813b644 in strstr (this=0xbfb16560, FileName=0x82600a8 "/var/lib/video/True_blood/At_last/2013-11-29.00.30.203-0.rec") at /usr/include/string.h:335 #2 cRecording (this=0xbfb16560, FileName=0x82600a8 "/var/lib/video/True_blood/At_last/2013-11-29.00.30.203-0.rec") at recording.c:814 #3 0x0813be54 in GenerateIndex (FileName=0xbfb177ee "/var/lib/video/True_blood/At_last/2013-11-29.00.30.203-0.rec/") at recording.c:2679 #4 0x0818c589 in main (argc=2, argv=0xbfb16904) at vdr.c:345 vdr source is unpatched, built using "make LCLBLD=1" OS is Ubuntu 12.04 & Debian/Squeeze. Any ideas what is causing this? Can somebody else reproduce this as well with an unpatched source? Regards, Lou@vdr-portal

2 4

vdr on an underpowered NAS (D-link DNS 323)
by cedric.dewijs＠telfort.nl 25 Dec '13

25 Dec '13

Hi All, I am trying to install VDR on my NAS, a D-link DNS-323. This goes great, I can play & record unencrypted channels. without any problem. Next I try to compile the connax softcam plugin, as per this guide: https://wiki.debian.org/VDR#Install_vdr-plugin-sc_and_libvdr-sc-cardclient_… I get the following errors during compile: make[1]: Nothing to be done for `update-config'. make[1]: Leaving directory `/home/cedric/sc' touch debian/stamp-patched /bin/sh debian/configure_FFdecsa Processor capabilities: native ( ) Trying various FFdecsa optimizations... PARALLEL_32_INT: build failed PARALLEL_32_4CHAR: build failed PARALLEL_32_4CHARA: build failed PARALLEL_64_8CHAR: build failed PARALLEL_64_8CHARA: build failed PARALLEL_64_2INT: build failed PARALLEL_64_LONG: build failed PARALLEL_64_MMX: build failed PARALLEL_128_16CHAR: build failed PARALLEL_128_16CHARA: build failed PARALLEL_128_4INT: build failed PARALLEL_128_2LONG: build failed PARALLEL_128_2MMX: build failed PARALLEL_128_SSE: build failed PARALLEL_128_SSE2: build failed Choosing PARALLEL_MODE = PARALLEL_32_INT /usr/bin/make all DVBDIR=/usr VDRDIR=/usr/include/vdr LIBDIR=. LOCALEDIR=debian/tmp/usr/share/locale make[1]: Entering directory `/home/cedric/sc' make[1]: Leaving directory `/home/cedric/sc' make[1]: Entering directory `/home/cedric/sc' Has anybody succeded in compiling this on an arm system? Some info on the system: # uname -a Linux debian 3.2.0-4-orion5x #1 Debian 3.2.51-1 armv5tel GNU/Linux # cat /proc/cpuinfo Processor : Feroceon rev 0 (v5l) BogoMIPS : 331.77 Features : swp half thumb fastmult edsp CPU implementer : 0x41 CPU architecture: 5TEJ CPU variant : 0x0 CPU part : 0x926 CPU revision : 0 Hardware : D-Link DNS-323 Revision : 0000 Serial : 0000000000000000 Best regards, Cedric

2 7

Re: [vdr] vdr-iptv "sh -c" iptvstream.sh issue
by Ian_and_joanna 24 Dec '13

24 Dec '13

Hi, In Brief Have you checked file permissions? Detail The first example you quote that works is the way iptvstream.sh should be called I think (so that parameters can be passed to the script). The first thing I'd check are the file permissions on iptvstream.sh (i.e. the output from ls -l /etc/vdr/iptvstream.sh ) and that they allow the user running vdr to execute the script. In general I hesitate in modifying the source until I have ruled out other possibilities as I imagine an error of this nature in the source would have been picked up by others sooner (unless it is a very recent change). In closing First step check file permissions on the shell script. Regards, Ian. Sent from my mobile phone. -------- Original message -------- From: Zouhair <infonux(a)gmail.com> Date: 2013/12/23 22:43 (GMT+00:00) To: VDR Mailing List <vdr(a)linuxtv.org> Subject: [vdr] vdr-iptv "sh -c" iptvstream.sh issue Hi, the external script iptvstream.sh not execute from iptv plugins ? I get: "ERROR: Script execution failed: /etc/vdr/iptvstream.sh 1 4321" after looking at the source code "protocolext.c" ------ // Create a new session for a process group ERROR_IF_RET(setsid() == -1, "setsid()", _exit(-1)); if (execl(EXTSHELL, "sh", "-c", *cmd, (char *)NULL) == -1) { error("Script execution failed: %s", *cmd); _exit(-1); ... I tried to execute it in the same way: sh -c /etc/vdr/iptvstream.sh 1 4321 not work. (the shell exit with no execution) I try with the cote (like): sh -c "/etc/vdr/iptvstream.sh 1 4321" or, sh /etc/vdr/iptvstream.sh 1 4321 and, work fine. Should add cote or remove "-c" in source code to fix this ? Or any other solution ? Using: vdr-iptv-2.0.0 and VDR 2.0.2 Thanks. _______________________________________________ vdr mailing list vdr(a)linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

3 2

vdr-iptv "sh -c" iptvstream.sh issue
by Zouhair 23 Dec '13

23 Dec '13

Hi, the external script iptvstream.sh not execute from iptv plugins ? I get: "ERROR: Script execution failed: /etc/vdr/iptvstream.sh 1 4321" after looking at the source code "protocolext.c" ------ // Create a new session for a process group ERROR_IF_RET(setsid() == -1, "setsid()", _exit(-1)); if (execl(EXTSHELL, "sh", "-c", *cmd, (char *)NULL) == -1) { error("Script execution failed: %s", *cmd); _exit(-1); ... I tried to execute it in the same way: sh -c /etc/vdr/iptvstream.sh 1 4321 not work. (the shell exit with no execution) I try with the cote (like): sh -c "/etc/vdr/iptvstream.sh 1 4321" or, sh /etc/vdr/iptvstream.sh 1 4321 and, work fine. Should add cote or remove "-c" in source code to fix this ? Or any other solution ? Using: vdr-iptv-2.0.0 and VDR 2.0.2 Thanks.

1 0

libcec integration
by Torgeir Veimo 23 Dec '13

23 Dec '13

Have anyone looked into integrating libcec into VDR, similar to lirc?

2 4

merge old vdr files using cat
by Lou 19 Dec '13

19 Dec '13

hi list Older vdr recordings where recorded as MPEG-PES, and split right before the 2GB size limit. Is it save to use cat and merge them into one big file? I remember my recording vdr was one of those "multipatch" editions, which might have tampered with the filestructure. Any thoughts on that? Regards, Lou

2 1

[Announce] streamdev-0.6.1
by Frank Schmirler 17 Dec '13

17 Dec '13

Hi, it was about time to publish a streamdev release for VDR 2.0. Streamdev-0.6.1 is now available from http://projects.vdr-developer.org/projects/plg-streamdev/files. The server plugin requires at least VDR 1.7.25. The client plugin should even work with VDR 1.6. On VDR version up to 1.7.33 the Makefiles have to be replaced by the old versions which are shipped along with the source. Besides bugfixes and internal changes the following features have been added since 0.6.0: The client plugin can now provide multiple devices, allowing the client to receive more than one transponder from the same server (e.g. for PiP or clientside recordings). So it is no longer necessary to add a copy of the plugin unless you want to connect with multiple servers. Basic support for HTTP streaming of recordings. There is still a lot to do. In particular a proper menu and remuxing are missing. At the moment the recording is streamed "as-is" (usually TS), even if the menu suggests something different. In addition to the HTML menu and the M3U playlists, the HTTP server now also offers RSS feeds. Some smart TV apps should be able to make use of it. A new option in streamdev-server suspends local output when starting. The default value "auto" will do this only if no output device is detected. Here's the complete changelog: - Updated Slovak translation (thanks to Milan Hrala) - Updated Finnish translation (thanks to Rolf Ahrenberg) - Disabled PS remuxer which is said to produce anything but PS - The patches intcamdevices and ignore_missing_cam are no longer required on VDR >= 1.7.30. The localchannelprovide patch became obsolete with VDR 1.7.21. - Added option to suspend live TV when the server starts - Set device occupied when streamdev switches away LiveTV on the server, to reduce the risk that the VDR main loop immediately switches back, resulting in a black screen on the client (reported by hummel99) - Fixed channel switch issues with priority > 0 (reported by hummel99) - Removed noisy debug messages - Fixed HTTP menu destruction - API change of VDR 2.1.2 - Fixed priority handling, messed up when adding multi-device support - Added HTTP "Server" header (suggested by hivdr) - Ignore dummy file extensions (.ts, .vob, .vdr) when parsing HTTP URIs - Select start position for replaying a recording by parameter pos=. Supported values are resume, mark.#, time.#, frame.# or a plain # representing a percentage if < 100 or a byte position otherwise (thanks to hivdr) - Start cSuspendCtl hidden or it will prevent idle shutdown (thanks to thomasjfox) - Fixed recordings menu inode numbers: ino_t is a long long on some systems - Updated Slovak translation (thanks to Milan Hrala) - Adapted Makefiles to VDR 1.7.36+ (thanks to macmenot). Old makefiles have been renamed to Makefile-1.7.33. - API changes of VDR 1.7.38 (thanks to mal@vdr-developer) - Added simple recordings menu in HTTP server - Restructured menuHTTP classes - Added RSS format for HTTP menus - Recordings can now also be selected by struct stat "st_dev:st_ino.rec" - Implemented multi-device support for streamdev client (suggested by johns) - Basic support for HTTP streaming of recordings - Close writer when streamer is finished - Don't abort VTP connection if filter stream is broken - Restructured cStreamdevStreamer: Moved inbound buffer into actual subclass. - In cStreamdevStreamer dropped Activate(bool) and moved its code into Start(). - Moved cStreamdevFilterStreamer to livefilter.[hc] - Return HTTP/1.1 compliant response headers plus some always useful headers - Return HTTP URL parameters ending with ".dlna.org" as response headers - Store HTTP URL parameters in a map - Support HTTP HEAD requests with external remuxer - Fixed always using priority 0 for HTTP HEAD requests - Start writer right after creating it - Corrected typos (thanks to Ville Skyttä) - Fixed compiler error in client/device.c with VDR < 1.7.22 (reported by Uwe@vdrportal) - Updated Italian translation (thanks to Diego Pierotto) - Added DeviceName() and DeviceType() to client device. The server IP and the number of the device used on the server are returned respectively. Have fun, Frank

4 10

Why use /var/lib/vdr?
by cedric.dewijs＠telfort.nl 11 Dec '13

11 Dec '13

Hi All, I have build VDR systems based on arch linux and debian. On both, one half of the configuration files in is /etc/vdr, the other half in /var/lib/vdr. Why has the location /var/lib/vdr been choosen for the configuration files? Best regards, Cedric

4 3

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

vdr