vdr November 2013

vdr@linuxtv.org

21 participants
16 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

[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

start VDR without hardware for test and tutorial
by cedric.dewijs＠telfort.nl 03 Dec '13

03 Dec '13

Hi All, I'm writing a tutorial on VDR for debian. To make the individual steps as small as possible, I would like to begin without any special hardware, just a normal PC. It turns out VDR refuses to run when no DVB card is found. Is there a configuration option somewhere to let VDR run without hardware? Can I create a dummy DVB device somehow? The guide (unfinished) is here: https://wiki.debian.org/VDR Best regards, Cedric My versions: VDR 1.7.28 Debian 7.2.0 Stable (installed today) The error in /var/log/syslog ... No DVB device found ERROR: invalid primary device number: 1 ERROR: no primary device found = using first device! ERROR: invalid primary device number: 1 ... exiting, exit code 2 runvdr: stopping after fatal fail (vdr: no primary device found - using first device!)

4 6

Really stupid question about Full-Function DVB Cards
by Brian-Imap 02 Dec '13

02 Dec '13

Hi, dont kill me please.............. I'm using a 4 Tuner Cine 2 DVB S2 setup for recording TV programs. For playback I was using a DVB-C FF Card, so this was not being used to record as there were no Cable channel entries defined and no cable attached to it. Worked perfectly, but now the DVB C card has broken. So I need a replacement. But I have multiple FF DVB-S cards laid around here not in use. As the dvbttpci driver is only used for this one card, wouldn't it be possible to patch the driver so that it reports the DVB-S card as a DVB-C card? Maybe even by an optional parameter? That way I wouldn't need to buy a new DVB-C card. Stupid idea or not? Cheers Brian

3 7

aufs instead of mhddfs with vdr 2.1.2
by Mike Constabel 02 Dec '13

02 Dec '13

Hi Klaus, i tried mhddfs since I've 5 disks with together 8 TB. The problem is that mhddfs didn't run reliable for me. I tried Debian Wheezy with kernel 3.2, 3.6, 3.10, but every time after starting an recording I got vdr: [19801] ERROR (tools.c,423): /video1: Der Socket ist nicht verbunden/var/log/syslog.6.gz:Nov 24 19:54:38 video1 vdr: [20399] ERROR (recording.c,856): /video1/Spielfilm/Romantik~Liebe/Ein_verlockendes_Spiel/2011-12-11.20.05.8-0.rec/info: Der Socket ist nicht verbunden vdr: [20399] ERROR (recording.c,914): /video1/Spielfilm/Romantik~Liebe/Ein_verlockendes_Spiel/2011-12-11.20.05.8-0.rec/summary.vdr: Der Socket ist nicht verbunden vdr: [20399] ERROR (tools.c,613): /video1/Spielfilm/Romantik~Liebe/Ein_verlockendes_Spiel/2011-12-11.20.05.8-0.rec: Der Socket ist nicht verbunden vdr: [20431] ERROR (recorder.c,159): /video1/Doku/Natur/Terra_X:_Faszination_Erde_-_mit_Dirk_Steffens/Teil_:_Wildes_Mittelmeer_-_Wiege_Europas/2013-11-24.19.28.51-0.rec/00001.ts: Der Socket ist nicht verbunden vdr: [20397] ERROR (tools.c,423): /video1: Der Socket ist nicht verbunden So I tried aufs. This works nearly great for me. mount -t aufs -o br=/video1.1=rw:/video1.2=rw:/video1.3=rw:/video1.4=rw:/video1.0=rw -o create=mfsrr:$((10*1024*1024*1024)):30 -o udba=reval,sum,verbose none /video1 But now I cannot delete recordings from within vdr. I found something about this: http://aufs.sourceforge.net/aufs.html#Incompatible%20with%20an%20Ordinary%2… To rename(2) directory may return EXDEV even if both of src and tgt are on the same aufs. When the rename-src dir exists on multiple branches and the lower dir has child(ren), aufs has to copyup all his children. It can be recursive copyup. Current aufs does not support such huge copyup operation at one time in kernel space, instead produces a warning and returns EXDEV. Generally, mv(1) detects this error and tries mkdir(2) and rename(2) or copy/unlink recursively. So the result is harmless. If your application which issues rename(2) for a directory does not support EXDEV, it will not work on aufs. Also this specification is applied to the case when the src directory exists on the lower readonly branch and it has child(ren). Is it possible that vdr supports aufs? aufs would be better than mhddfs: faster, not fuse, in kernel, under development... Regards, Mike

6 6

DNS-323 NAS with 64MB ram, can this run VDR?
by cedric.dewijs＠telfort.nl 18 Nov '13

18 Nov '13

Hi All, I have been given a D-link DNS-323 NAS. This machine runs linux, but only has 64MB RAM. I have tested on my x86 machine. VDR uses 28MB RAM while idle, and this rises to 48MB while decrypting and recording one SD channel. Is it possible to run VDR on this machine? How can I keep the RAM usage low? Best regards, Cedric

2 1

Valgrind warnings with LCARS OSD
by Marko Mäkelä 16 Nov '13

16 Nov '13

Hi all, I played a little with Valgrind: valgrind --vgdb=yes --vgdb-error=0 ./vdr ... and in gdb, (gdb) target remote |vgdb This seems to give me a false alarm for cRecording::cRecording(): Program received signal SIGTRAP, Trace/breakpoint trap. 0x0811951a in cRecording::cRecording (this=0xbee4d958, FileName=0x0) at recording.c:801 801 if (*(fileName + strlen(fileName) - 1) == '/') The machine code is doing some magic after the strdup() on the previous line. I suspect that it is gcc that is performing strlen() with some black magic that trips this warning: ==3212== Invalid read of size 4 ==3212== at 0x811951A: cRecording::cRecording(char const*) (recording.c:801) ==3212== by 0x80CEF77: cDvbPlayer::cDvbPlayer(char const*, bool) (dvbplayer.c:268) ==3212== Address 0x4454004 is 76 bytes inside a block of size 78 alloc'd ==3212== at 0x4028308: malloc (vg_replace_malloc.c:263) ==3212== by 0x4315E1F: strdup (strdup.c:43) ==3212== by 0x81194FE: cRecording::cRecording(char const*) (recording.c:800) Then I got and fixed many warnings in Softdevice, which forgot to initialize some class members in constructors. Finally, I got a real warning for VDR: ==3212== Conditional jump or move depends on uninitialised value(s) ==3212== at 0x4029654: __GI_strcmp (mc_replace_strmem.c:712) ==3212== by 0x813ACD8: cSkinLCARSDisplayReplay::DrawTrack() (skinlcars.c:1786) ==3212== by 0x813AE9F: cSkinLCARSDisplayReplay::Flush() (skinlcars.c:1861) ==3212== by 0x80FCA55: cReplayControl::ShowProgress(bool) (menu.c:4670) ==3212== by 0x80FCBF7: cReplayControl::ShowTimed(int) (menu.c:4583) ==3212== by 0x80FCDEF: cReplayControl::cReplayControl(bool) (menu.c:4510) ==3212== by 0x80AC745: main (vdr.c:1307) "(gdb) monitor get_vbits" tells me that all of lastTrackId is uninitialized: (gdb) up #1 0x0813acd9 in cSkinLCARSDisplayReplay::DrawTrack ( this=this@entry=0x457c3a0) at skinlcars.c:1786 1786 if (!Track && *lastTrackId.description || Track && strcmp(lastTrackId.description, Track->description)) { (gdb) p lastTrackId $27 = {id = 0, language = "\000\000\000\000\000\000\000", description = '\000' <repeats 31 times>} (gdb) p &lastTrackId $28 = (tTrackId *) 0x457c434 (gdb) p sizeof lastTrackId $29 = 42 (gdb) monitor get_vbits 0x457c434 42 ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffff BTW, !Track && x || Track && y should IMO be simpler written Track ? y : x. It looks like a memset() is missing from the cSkinLCARSDisplayReplay constructor. cSkinLCARSDisplayChannel::cSkinLCARSDisplayChannel() is doing the right thing: memset(&lastTrackId, 0, sizeof(lastTrackId)); Adding the memset() made this message go away. (Patch attached.) The next problem is this one, which I get every time by pressing Play, Pause, Menu, Recordings after startup: ==3601== Conditional jump or move depends on uninitialised value(s) ==3601== at 0x810C0DB: cRect::Intersected(cRect const&) const (osd.h:411) ==3601== by 0x810E3D1: cPixmapMemory::DrawRectangle(cRect const&, unsigned int) (osd.c:1333) ==3601== by 0x810AA0B: cOsd::DrawRectangle(int, int, int, int, unsigned int) (osd.c:1922) ==3601== by 0x8130482: cSkinLCARSDisplayMenu::Clear() (skinlcars.c:1463) ==3601== by 0x810651F: cOsdMenu::Display() (osdbase.c:223) ==3601== by 0x80FA3D1: cMenuMain::Set() (menu.c:3432) ==3601== by 0x80FA9FD: cMenuMain::cMenuMain(eOSState, bool) (menu.c:3376) ==3601== by 0x80AC21B: main (vdr.c:1078) According to "monitor get_vbits", the cRect is totally uninitialized. Program received signal SIGTRAP, Trace/breakpoint trap. 0x0810c0db in IsEmpty (this=0xbeba08a0) at osd.h:411 411 bool IsEmpty(void) const { return Width() <= 0 || Height() <= 0; } (gdb) up #1 cRect::Intersected (this=this@entry=0xbeba08a0, Rect=...) at osd.c:912 912 if (!IsEmpty() && !Rect.IsEmpty()) { (gdb) up #2 0x0810e3d2 in cPixmapMemory::DrawRectangle (this=0x6d3fe78, Rect=..., Color=2566914048) at osd.c:1333 1333 cRect r = Rect.Intersected(DrawPort().Size()); As far as I can tell, the entirely uninitialized cRect is being passed as the Rect parameter to cPixmapMemory::DrawRectangle(). Unfortunately, gdb cannot show me the stack above that. It would seem to me that cSkinLCARSDisplayMenu::Clear() is passing uninitialized bounds to cOsd::DrawRectangle(), which will lead to funny values like this: (gdb) p *this $31 = {point = {x = 1418239204, y = 0}, size = {width = -1379480940, height = 201}, static Null = {point = {x = 0, y = 0}, size = {width = 0, height = 0}, static Null = <same as static member of an already seen type>}} As a workaround, I guess that I will be switching away from the LCARS skin for now. I got into this exercise because vdr sometimes crashed when I pressed the Recordings or Menu button when using the LCARS skin. I am also attaching my patch against softdevice CVS, in case someone finds it useful. I was unable to figure out how to clear the garbage at the bottom of the OSD screen. It goes away if the dfb:mgatv video display area is high enough (4:3 video instead of 16:9). Best regards, Marko

2 4

[PATCH] spelling in usage text
by Lars Hanisch 16 Nov '13

16 Nov '13

Hi, " --vfat for backwards compatibility (same as\n" " --dirnames=250,40,1\n" Either use a comma before "same" or a closing bracket in the second line. Whatever you prefer, I would take the comma. :) Patches attached for both variants. Lars.

1 0

freeze with ZDF HD and streamdev
by Peter Münster 13 Nov '13

13 Nov '13

Hi, When watching ZDF HD (from Astra-19E), my vdr-2.0.4-streamdev-client freezes after about 10 seconds. When adding "-wX" to the command line, the watchdog works and makes vdr exit after X seconds. There is no such problem with "Das Erste HD" or "Arte HD". Here the channel line: ZDF HD;ZDFvision:11361:HC23M5O35P0S1:S19.2E:22000:6110=27:6120=deu@3,6121=mis@3,6123=mul@3;6122=deu@106:6130;6131=deu:0:11110:1:1011:0 How could I solve that problem please? TIA for any help, -- Peter

1 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

vdr November 2013