vdr February 2014

vdr@linuxtv.org

21 participants
15 discussions

xmltv2vdr.pl
by Dominic Evans 14 Aug '15

14 Aug '15

I don't know if anyone else still uses the xmltv2vdr.pl perl script for piping XMLTV data into VDR's epg, but I've been keeping a version of it updated with some additional function here: https://github.com/oldmanuk/xmltv2vdr These are the changes since the last version (1.0.9) was released on the mailing list - Add support for XMLTV episode-num. Currently gets added as EPG entry 'sub-title', if no existing subtitle has been found, in the form sXXeXX (e.g., Bones~s01e01). - Change default SVDRP port number to 6419. - Better support for ATSC/PVRINPUT EPG sources. - Allow multiple channels to have the same XMLTV channel id, useful for multi input (e.g., DVB-T, DVB-S) systems where you want to feed VDR the same info. Previously only a 1:1 mapping was permitted. I've also received a pull request from someone who rewrote the whole script to be a lot more readable and to use full XML parsing (rather than just line-by-line scraping), but I still need to investigate what the performance penalty is before accepting that in.

6 10

VDR & Multiple frontends
by Eddi 25 Jul '15

25 Jul '15

Hi, I wrote a patch to Steve Toth hvr3000 repository, so my FlyDVB Trio can use multiple frontend. So I get: /dev/dvb/adapter0/demux0 /dev/dvb/adapter0/demux1 /dev/dvb/adapter0/dvr0 /dev/dvb/adapter0/dvr1 /dev/dvb/adapter0/frontend0 /dev/dvb/adapter0/frontend1 /dev/dvb/adapter0/net0 /dev/dvb/adapter0/net1 The bus of the two frontend is shared, isn't possible to get access to both frontend simultaneously, so I get an -EBUSY error by trying accessing frontend1 if frontend0 is in use. VDR doesn't support yet the second frontend, and it try to get exclusive access on both frontend on start, so the second frontend is inusabile. Vdr should probe for multiple frontend at start, and access frontend only on channel change. Please can someone give me an help to wrote a patch for this issue? Best Regards, Eddi

4 21

cSoftDevice::StillPicture() not updating video in VDR 2.0
by Marko Mäkelä 31 May '14

31 May '14

After upgrading to VDR 2.0, I got Softdevice to almost work (see the mail archive a couple of months ago). Sometimes it is showing garbage (really random noise) on the MGA350 OSD layer; I can live with that, as this box is only used for infrequent recordings. The last annoying problem is that going to the next or previous I-frame when editing (buttons 4 and 6 on the remote control) are not updating the video screen at all. Only the edit mark is moving on the OSD layer. If I press Play, it will start playing from the current edit mark. So, it is possible but much more clumsy to cut recordings. SoftDevice is overriding the method with this: void cSoftDevice::StillPicture(const uchar *Data, int Length) { SOFTDEB("StillPicture...\n"); if (decoder) decoder->StillPicture((uchar *)Data,Length); } It seems to me that mpeg2decoder.c in softdevice is creating a new thread every time I try to move editing mark, and calling cMpeg2Decoder::Action(). In gdb, it will fail as follows: while(ThreadActive) { while (freezeMode && ThreadActive) usleep(50000); BUFDEB("av_read_frame start\n"); if (useAVReadFrame) ret = av_read_frame(ic, &pkt); else ret = av_read_packet(ic, &pkt); if (ret < 0) { BUFDEB("cMpeg2Decoder Stream Error!\n"); if (ThreadActive) usleep(10000); continue; } useAVReadFrame=true, so it is calling av_read_frame(). That will block when running under gdb, like this: #2 0xb68f83a9 in cSigTimer::Sleep (this=0xb2c121f4, timeoutUS=50000, lowLimitUS=0) at sync-timer.c:75 #3 0xb68f1cf0 in cMpeg2Decoder::read_packet (this=this@entry=0xb2c120f0, buf=buf@entry=0x87fc5b0 "v\253T)\251z\366\020[\231a\202\275\237@\006\266\067k*r\370JV\255\364\020\177\247:\353 \004\024\277\004jhjG|] t$X", buf_size=buf_size@entry=10864) at mpeg2decoder.c:1128 #4 0xb68f1dcf in read_packet_RingBuffer (opaque=0xb2c120f0, buf=0x87fc5b0 "v\253T)\251z\366\020[\231a\202\275\237@\006\266\067k*r\370JV\255\364\020\177\247:\353 \004\024\277\004jhjG|] t$X", buf_size=10864) at mpeg2decoder.c:1042 #5 0xb69140c9 in fill_buffer (s=s@entry=0x85ac040) at libavformat/aviobuf.c:319 #6 0xb6916ff7 in get_byte (s=0x85ac040) at libavformat/aviobuf.c:365 #7 get_byte (s=s@entry=0x85ac040) at libavformat/aviobuf.c:360 #8 0xb6958984 in find_next_start_code (header_state=0x8a075e0, size_ptr=<synthetic pointer>, pb=0x85ac040) at libavformat/mpeg.c:142 #9 mpegps_read_pes_header (s=s@entry=0x89f2080, ppos=ppos@entry=0xb10cc190, pstart_code=pstart_code@entry=0xb10cc160, ppts=ppts@entry=0xb10cc170, pdts=pdts@entry=0xb10cc180) at libavformat/mpeg.c:246 #10 0xb695933a in mpegps_read_packet (s=0x89f2080, pkt=0xb10cc290) at libavformat/mpeg.c:419 #11 0xb690c3b4 in av_read_packet (s=s@entry=0x89f2080, pkt=pkt@entry=0xb10cc290) at libavformat/utils.c:591 #12 0xb690ce8b in av_read_frame_internal (s=0x89f2080, pkt=0xb10cc304) at libavformat/utils.c:998 #13 0xb68f2527 in cMpeg2Decoder::Action (this=0xb2c120f0) at mpeg2decoder.c:1228 It will unblock when I hit 4 or 6 again, because the thread would be killed (ThreadActive=false) by this: #0 cMpeg2Decoder::Stop (this=this@entry=0xb2c120f0, GetMutex=GetMutex@entry=false) at mpeg2decoder.c:1545 #1 0xb68f2cec in cMpeg2Decoder::Clear (this=0xb2c120f0) at mpeg2decoder.c:1655 #2 0xb68ea1b6 in Clear (this=0x83d3130) at softdevice.c:492 #3 cSoftDevice::Clear (this=0x83d3130) at softdevice.c:484 #4 0x080cf2da in cDvbPlayer::Empty() () #5 0x080cf7e9 in cDvbPlayer::Goto(int, bool) () #6 0x080d1303 in cDvbPlayerControl::Goto(int, bool) () #7 0x080fd676 in cReplayControl::MarkMove(bool) () #8 0x080fdcc6 in cReplayControl::ProcessKey(eKeys) () #9 0x080aac39 in main () I wonder why this worked in VDR 1.6 but no longer in VDR 2.0? Is it because Softdevice is expecting a PES packet here instead of TS, or is it something else? Marko

2 4

[ANNOUNCE] VDR developer version 2.1.5
by Klaus Schmidinger 10 Mar '14

10 Mar '14

VDR developer version 2.1.5 is now available at ftp://ftp.tvdr.de/vdr/Developer/vdr-2.1.5.tar.bz2 A 'diff' against the previous version is available at ftp://ftp.tvdr.de/vdr/Developer/vdr-2.1.4-2.1.5.diff MD5 checksums: ce561eef64c13e24e4817f70a6d9d5b0 vdr-2.1.5.tar.bz2 f433e78d90bc414bd9d858ca6e58e539 vdr-2.1.4-2.1.5.diff WARNING: ======== This is a *developer* version. Even though *I* use it in my productive environment, I strongly recommend that you only use it under controlled conditions and for testing and debugging. The changes since version 2.1.4: - Now checking whether the primary device actually has a decoder before retuning the current channel after a change in its parameters. This fixes broken recordings on the primary device on "headless" systems. - Increased MIN_TS_PACKETS_FOR_FRAME_DETECTOR to 100 and introduced counting the number of actual video TS packets in cTsPayload in order to be able to record channels that sometimes need even more than 10 TS packets for detecting frame borders (reported by Oliver Endriss). - Fixed sorting recordings by time in the Recordings menu if "Setup/OSD/Recording directories" is set to "no". - Fixed clearing non-editable members in the channel editor (thanks to Rolf Ahrenberg). - Updated the Estonian OSD texts (thanks to Arthur Konovalov). - Further clarified the semantics of cCamSlot::Decrypt(). - Fixed flickering if subtitles are active while the OSD demo is running. - Fixed numbering frames. Previously they were numbered starting from 1, while it is apparently standard to number them from 0. Any existing recordings with editing marks (which will now be off by one) can still be cut with all VDR versions from 1.7.32, because these will automatically adjust editing marks to I-frames. Users of stable releases shouldn't notice any problems. - Fixed a possible crash in the OSD demo (reported by Christopher Reimer). - Fixed some compiler warnings with Clang 3.4.1 (reported by Paul Menzel). - Added LinkageTypePremiere to libsi/si.h and eit.c to avoid a compiler warning with Clang 3.4.1 (suggested by Tony Houghten). - Replaced the NULL pointer assignment in ~cReceiver() to force a segfault with a call to abort() (suggested by Tony Houghten). - Fixed learning keyboard remote control codes (thanks to Lars Hanisch). - Improved PAT/PMT scanning to speed up initial tuning to encrypted channels on transponders with many PAT entries (reported by Mariusz Bialonczyk). - Fixed the replay progress display for very long recordings. - Fixed detecting broken video data streams when recording. - Fixed handling frame detection buffer length (reported by Eike Sauer). Have fun! Klaus

3 6

[announce]: pvr350-1.7.5
by Martin Dauskardt 28 Feb '14

28 Feb '14

There maybe a handful people still using the Hauppauge PVR350 card as output device. Although I have stopped active development, I will adapt the plugin as long as possible for newer vdr versions. I believe that the PVR350 is still a good choice in case you have a SD Tube TV and don't need digital audio output. Version 1.7.5 is online: http://projects.vdr-developer.org/attachments/download/1657/vdr-pvr350-1.7.… - remove support for vdr < version 2.0 - adapt to changes in vdr-2.1.3 - remove support for ancient ivtv driver versions - adapt Makefile to vdr's new Makefile system - fix segfaults on exit when framebuffer device is missing The plugin is still only for PAL ouput. If there are any users who want to use it for NTSC output, I may consider adding it. Please send me a mail. Greets, Martin

2 1

Minimum CPU requirement for xineliboutput + vdr-sxfe for HDTV
by Stephan Loescher 28 Feb '14

28 Feb '14

Hi! I am interested in your experiences with xineliboutput-plugin and vdr-sxfe for HDTV and not using VDPAU but using the plain CPU-power. The plan would be to build a simple system without any special graphics-card and no special X11-configuration or driver, perhaps some cheap system like the one descibed in http://ct.de/-1375124 (German). (Celeron G1820, small case, low power consumption, about 180 EUR without disks.) I know from my own VDR-systems, that a Intel Core2 Duo @ 1.86GHz or a Core i3 540 @ 3.07GHz has far enough power to run VDR and vdr-sxfe for displaying HDTV. But I think even slower and thus cheaper CPUs could do the HDTV-decoding, too. What is you experience? Would it be possible to use these new Haswell-Celerons? TIA and best regards, Stephan. -- loescher(a)gmx.de http://www.loescher-online.de/

7 6

*** Error in VDR 2.0.5
by Guido Cordaro 25 Feb '14

25 Feb '14

*** Error in `./vdr': corrupted double-linked list: 0x0000000000c99110 *** feb 25 18:49:43.378 [cardclient.cccam2] logout from server initiated ======= Backtrace: ========= /lib/x86_64-linux-gnu/libc.so.6(+0x7f4c6)[0x7ff925e134c6] /lib/x86_64-linux-gnu/libc.so.6(+0x80c3a)[0x7ff925e14c3a] /lib64/ld-linux-x86-64.so.2(_dl_deallocate_tls+0x58)[0x7ff927ad4718] /lib/x86_64-linux-gnu/libpthread.so.0(+0x6da6)[0x7ff927686da6] /lib/x86_64-linux-gnu/libpthread.so.0(+0x6ebf)[0x7ff927686ebf] /lib/x86_64-linux-gnu/libpthread.so.0(+0x8062)[0x7ff927688062] /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7ff925e8e9cd] ======= Memory map: ======== 00400000-00570000 r-xp 00000000 08:21 5511403 /usr/local/src/vdr-2.0.5/vdr 00770000-00781000 r--p 00170000 08:21 5511403 /usr/local/src/vdr-2.0.5/vdr 00781000-00783000 rw-p 00181000 08:21 5511403 /usr/local/src/vdr-2.0.5/vdr 00783000-007e4000 rw-p 00000000 00:00 0 00929000-01914000 rw-p 00000000 00:00 0 [heap] 7ff8a4000000-7ff8a434b000 rw-p 00000000 00:00 0 7ff8a434b000-7ff8a8000000 ---p 00000000 00:00 0 7ff8ac000000-7ff8ac021000 rw-p 00000000 00:00 0 7ff8ac021000-7ff8b0000000 ---p 00000000 00:00 0 7ff8b4000000-7ff8b409a000 rw-p 00000000 00:00 0 7ff8b409a000-7ff8b8000000 ---p 00000000 00:00 0 7ff8b8000000-7ff8b80a3000 rw-p 00000000 00:00 0 7ff8b80a3000-7ff8bc000000 ---p 00000000 00:00 0 7ff8bc000000-7ff8bc021000 rw-p 00000000 00:00 0 7ff8bc021000-7ff8c0000000 ---p 00000000 00:00 0 7ff8c0000000-7ff8c0962000 rw-p 00000000 00:00 0 7ff8c0962000-7ff8c4000000 ---p 00000000 00:00 0 7ff8c433c000-7ff8c433d000 ---p 00000000 00:00 0 7ff8c433d000-7ff8c4b3d000 rw-p 00000000 00:00 0 [stack:6146] 7ff8c4b3d000-7ff8c4b62000 r-xp 00000000 08:21 4460423 /lib/x86_64-linux-gnu/libpng12.so.0.49.0 7ff8c4b62000-7ff8c4d61000 ---p 00025000 08:21 4460423 /lib/x86_64-linux-gnu/libpng12.so.0.49.0 7ff8c4d61000-7ff8c4d62000 r--p 00024000 08:21 4460423 /lib/x86_64-linux-gnu/libpng12.so.0.49.0 7ff8c4d62000-7ff8c4d63000 rw-p 00025000 08:21 4460423 /lib/x86_64-linux-gnu/libpng12.so.0.49.0 7ff8c4d63000-7ff8c4d86000 r-xp 00000000 08:21 9307165 /usr/lib/x86_64-linux-gnu/ImageMagick-6.7.7/modules-Q16/coders/png.so 7ff8c4d86000-7ff8c4f85000 ---p 00023000 08:21 9307165 /usr/lib/x86_64-linux-gnu/ImageMagick-6.7.7/modules-Q16/coders/png.so 7ff8c4f85000-7ff8c4f86000 r--p 00022000 08:21 9307165 /usr/lib/x86_64-linux-gnu/ImageMagick-6.7.7/modules-Q16/coders/png.so 7ff8c4f86000-7ff8c4f87000 rw-p 00023000 08:21 9307165 /usr/lib/x86_64-linux-gnu/ImageMagick-6.7.7/modules-Q16/coders/png.so 7ff8c4f87000-7ff8c4f88000 ---p 00000000 00:00 0 7ff8c4f88000-7ff8c5788000 rw-p 00000000 00:00 0 [stack:713] 7ff8c5788000-7ff8c5789000 ---p 00000000 00:00 0 7ff8c5789000-7ff8c5f89000 rw-p 00000000 00:00 0 [stack:712] 7ff8c5f89000-7ff8c5f8a000 ---p 00000000 00:00 0 7ff8c5f8a000-7ff8c678a000 rw-p 00000000 00:00 0 [stack:711] 7ff8c678a000-7ff8c678c000 r-xp 00000000 08:21 9307046 /usr/lib/x86_64-linux-gnu/ImageMagick-6.7.7/modules-Q16/coders/xc.so 7ff8c678c000-7ff8c698b000 ---p 00002000 08:21 9307046 /usr/lib/x86_64-linux-gnu/ImageMagick-6.7.7/modules-Q16/coders/xc.so 7ff8c698b000-7ff8c698c000 r--p 00001000 08:21 9307046 /usr/lib/x86_64-linux-gnu/ImageMagick-6.7.7/modules-Q16/coders/xc.so 7ff8c698c000-7ff8c698d000 rw-p 00002000 08:21 9307046 /usr/lib/x86_64-linux-gnu/ImageMagick-6.7.7/modules-Q16/coders/xc.so 7ff8c69f1000-7ff8c69f2000 ---p 00000000 00:00 0 7ff8c69f2000-7ff8c71f2000 rw-p 00000000 00:00 0 7ff8c71f2000-7ff8c71f3000 ---p 00000000 00:00 0 7ff8c71f3000-7ff8c79f3000 rw-p 00000000 00:00 0 [stack:904] 7ff8c7a04000-7ff8c8000000 rw-s 125b43000 00:05 12417 /dev/nvidiactl 7ff8c8000000-7ff8c80a3000 rw-p 00000000 00:00 0 7ff8c80a3000-7ff8cc000000 ---p 00000000 00:00 0 7ff8cc000000-7ff8cc021000 rw-p 00000000 00:00 0 7ff8cc021000-7ff8d0000000 ---p 00000000 00:00 0 7ff8d0000000-7ff8d0021000 rw-p 00000000 00:00 0 7ff8d0021000-7ff8d4000000 ---p 00000000 00:00 0 7ff8d4000000-7ff8d4532000 rw-p 00000000 00:00 0 7ff8d4532000-7ff8d8000000 ---p 00000000 00:00 0 7ff8d8000000-7ff8d8021000 rw-p 00000000 00:00 0 7ff8d8021000-7ff8dc000000 ---p 00000000 00:00 0 7ff8dc2e7000-7ff8dc2e8000 ---p 00000000 00:00 0 7ff8dc2e8000-7ff8dcae8000 rw-p 00000000 00:00 0 [stack:655] 7ff8dd0e3000-7ff8dd0e8000 r-xp 00000000 08:21 5507266 /usr/lib/x86_64-linux-gnu/gconv/ISO_6937.so 7ff8dd0e8000-7ff8dd2e7000 ---p 00005000 08:21 5507266 /usr/lib/x86_64-linux-gnu/gconv/ISO_6937.so 7ff8dd2e7000-7ff8dd2e8000 r--p 00004000 08:21 5507266 /usr/lib/x86_64-linux-gnu/gconv/ISO_6937.so 7ff8dd2e8000-7ff8dd2e9000 rw-p 00005000 08:21 5507266 /usr/lib/x86_64-linux-gnu/gconv/ISO_6937.so 7ff8dd2e9000-7ff8dd2ea000 ---p 00000000 00:00 0 7ff8dd2ea000-7ff8ddaea000 rw-p 00000000 00:00 0 7ff8ddc2b000-7ff8ddce0000 r--p 00000000 08:21 6161763 /usr/share/fonts/truetype/dejavu/DejaVuSans.ttf 7ff8ddce0000-7ff8ddd89000 r--p 00000000 08:21 6161762 /usr/share/fonts/truetype/dejavu/DejaVuSans-Bold.ttf 7ff8ddd89000-7ff8ddd8a000 rw-s 968da000 00:05 12417 /dev/nvidiactl 7ff8ddd8a000-7ff8ddd8d000 rw-s cb875000 00:05 12417 /dev/nvidiactl 7ff8ddd8d000-7ff8ddd8e000 rw-s cb608000 00:05 12417 /dev/nvidiactl 7ff8ddd8e000-7ff8ddd8f000 rw-s cba37000 00:05 12417 /dev/nvidiactl 7ff8ddd8f000-7ff8ddd90000 rw-s fdc0c000 00:05 12418 /dev/nvidia0 7ff8ddd90000-7ff8ddd93000 rw-s 36303000 00:05 12417 /dev/nvidiactl 7ff8ddd93000-7ff8ddd94000 rw-s 35035000 00:05 12417 /dev/nvidiactl 7ff8ddd94000-7ff8ddd95000 rw-s 35736000 00:05 12417 /dev/nvidiactl 7ff8ddd95000-7ff8ddd96000 rw-s fdc0c000 00:05 12418 /dev/nvidia0 7ff8ddd96000-7ff8ddd99000 rw-s 35f85000 00:05 12417 /dev/nvidiactl knap@knap-pc:/usr/local/src/vdr-2.0.5$

1 0

VDR and ComHem in Sweden?
by Reiner Bühl 21 Feb '14

21 Feb '14

Hi, I would be interested to know if somebody uses VDR with ComHem cable TV in Sweden. Is it possible to use the CAM and SmartCard with VDR if you have a subscription? If so, what DVB cards and CIs are recommended? NOTE: I am NOT asking how to crack it! I just want to use VDR instead of the receiver part of my TV. Best regards, Reiner

2 1

Re: [vdr] softhddevice and alsa dmixer
by Poubelle 14 Feb '14

14 Feb '14

it works thank you

1 0

mp3 plugin for vdr-2.1.4
by Peter Münster 14 Feb '14

14 Feb '14

Hi, When compiling the mp3 plugin, I get this error: --8<---------------cut here---------------start------------->8--- *** Plugin mp3: WARNING: plugin mp3 is using an old Makefile! g++ -g -O3 -Wall -Werror=overloaded-virtual -Wno-parentheses -fPIC -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -c -D_GNU_SOURCE -DAPIVERSNUM=20104 -DHAVE_SNDFILE -DHAVE_VORBISFILE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -I/vdr/soft/vdr-2.1.4/include decoder.c decoder.c: In member function ‘bool cFileInfo::FileInfo(bool)’: decoder.c:224:76: warning: format ‘%llx’ expects argument of type ‘long long unsigned int’, but argument 2 has type ‘__fsblkcnt64_t {aka long unsigned int}’ [-Wformat] decoder.c:224:76: warning: format ‘%llx’ expects argument of type ‘long long unsigned int’, but argument 3 has type ‘__fsfilcnt64_t {aka long unsigned int}’ [-Wformat] decoder.c: In member function ‘char* cInfoCache::CacheFile()’: decoder.c:635:36: error: ‘VideoDirectory’ was not declared in this scope decoder.c:636:1: warning: control reaches end of non-void function [-Wreturn-type] make[1]: *** [decoder.o] Error 1 --8<---------------cut here---------------end--------------->8--- Could anybody help please to make the plugin work with the latest vdr version? Thanks in advance, -- Peter

2 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

vdr February 2014