vdr November 2012

vdr@linuxtv.org

33 participants
25 discussions

get a segmentation fault when starting vdr (backtrace included)
by Dieter Bloms 02 Dec '12

02 Dec '12

Hello, I've compiled vdr on alpinelinux 2.5.0 and get a segfault during start of vdr. Even without plugins I get this segfault (I didn't apply any patch to vdr sources). Vdr was started with the command: /usr/local/bin/vdr --config=/etc/vdr --epgfile=/tmp/epg.data --grab=/dev/shm --log=3.1 --mute --no-kbd --user=root --video=/remote/vdr/ I've made a backtrace with gdb: --snip-- vdrservernew:/tmp# gdb --core core /usr/local/bin/vdr GNU gdb (GDB) 7.5 Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-unknown-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /usr/local/bin/vdr...done. [New LWP 26493] [New LWP 26492] [New LWP 26494] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/libthread_db.so.1". Core was generated by `/usr/local/bin/vdr --config=/etc/vdr --epgfile=/tmp/epg.data --grab=/dev/shm --'. Program terminated with signal 11, Segmentation fault. #0 skipspace (s=0x40800000 <Address 0x40800000 out of bounds>) at tools.h:196 196 if ((uchar)*s > ' ') // most strings don't have any leading space, so handle this case as fast as possible (gdb) bt #0 skipspace (s=0x40800000 <Address 0x40800000 out of bounds>) at tools.h:196 #1 isempty (s=0x40800000 <Address 0x40800000 out of bounds>) at tools.c:249 #2 0x00000000004a1eb9 in FromString (s=0x2e531d2 "1 01 deu 4:3", this=0x2e4aba0) at epg.c:36 #3 cComponents::SetComponent (this=<optimized out>, Index=0, s=s@entry=0x2e531d2 "1 01 deu 4:3") at epg.c:81 #4 0x00000000004a40f3 in cEvent::Parse (this=0x2e43360, s=<optimized out>) at epg.c:495 #5 0x00000000004e9ea6 in cRecordingInfo::Read (this=0x2e2d110, f=f@entry=0x2e2c330) at recording.c:468 #6 0x00000000004eb4e3 in cRecording::cRecording (this=0x2e2c650, FileName=0x2e4c15c "Sex_and_the_City_2/2012-11-19.20.10.27-0.rec") at recording.c:723 #7 0x00000000004eceb1 in cRecordings::ScanVideoDir (this=0x7fe7c0 <Recordings>, DirName=0x2e412b0 "/remote/vdr/Sex_and_the_City_2", Foreground=false, LinkLevel=0) at recording.c:1165 #8 0x00000000004ed32c in cRecordings::ScanVideoDir (this=0x7fe7c0 <Recordings>, DirName=0x2e25ff0 "/remote/vdr", Foreground=false, LinkLevel=0) at recording.c:1180 #9 0x000000000052694e in cThread::StartThread (Thread=0x7fe7e0 <Recordings+32>) at thread.c:262 #10 0x00006e6b7ce69406 in start_thread () from /lib/libpthread.so.0.9.32 #11 0x00006e6b7ce61885 in clone () from /lib/libpthread.so.0.9.32 #12 0x0000000000000000 in ?? () --snip-- does anybody see what is wrong here ? -- Regards Dieter -- I do not get viruses because I do not use MS software. If you use Outlook then please do not put my email address in your address-book so that WHEN you get a virus it won't use my address in the >From field.

8 17

Re: [vdr] Skystar USB HD + VDR + Astra 23.5E 11817 V / 8psk, fec=5/6
by N. D. 30 Nov '12

30 Nov '12

>-------- Оригинално писмо -------- >От: Newsy Paper newspaperman_germany(a)yahoo.com >Относно: Re: [vdr] Skystar USB HD + VDR + Astra 23.5E 11817 V / 8psk, fec=5/6 >До: VDR Mailing List <vdr(a)linuxtv.org> >Изпратено на: Вторник, 2012, Ноември 27 22:38:10 EET > --- N. D. schrieb am Do, 22.11.2012: > > > Von: N. D. > > Betreff: Re: [vdr] Skystar USB HD + VDR + Astra 23.5E 11817 V / 8psk, fec=5/6 > > An: "Ales Jurik" > > CC: "VDR Mailing List" > > Datum: Donnerstag, 22. November, 2012 14:31 Uhr > > > > > > >-------- Оригинално писмо -------- > > > > >От: Ales Jurik ajurik(a)quick.cz > > > > >Относно: Re: [vdr] Skystar USB HD + VDR + Astra > > 23.5E 11817 V / 8psk,fec=5/6 > > > > >До: VDR Mailing List > > > > >Изпратено на: Сряда, 2012, Юни 13 > > 18:34:55 EEST > > > > > > > > > > > On 06/13/12 10:45, N. D. wrote: > > > > > > > > > > > > > > > > > > Hi, > > > > > > Since recently I have been using Skystar USB HD > > with my vdr > > > > > > box. However I have some strange issues with > > 11817V on Astra 23.5E. > > > > > > Femon reports that there is a lock and sound comes > > but the image is > > > > > > completely garbled. I am starting to suspect that > > there might be > > > > > > something wrong with the driver, because I have no > > trouble with the > > > > > > other transpoders. Maybe it is the combination of > > fec=5/6 and 8psk on > > > > > > the said transponder that is the reason for this. > > Other transponders > > > > > > with fec=3/4 and 8psk are OK. The same setup with > > an HVR-4000 works > > > > > > fine. > > > > > > > > > > > > Kernel: 3.3.4 > > > > > > > > > > > > VDR: 1.7.27 > > > > > > > > > > > > Could someone who owns a Skystar USB HD and has > > access to Astra 23.5E > > > > > > share his experience? Is this a driver issue a > > problem with vdr or is my card faulty? > > > > > > > > > > > > If someone would be kind enough to test this with > > his/hers hardware, there is a FTA channel on the problematic > > transponder: > > > > > > > > > > > > > > > > > > > > > > > > Planeta > > HD;SatelliteBG:11817:VC56M5O35S1:S23.5E:27500:1001=27:1002=@3:0:0:5410:3:3206:0 > > > > > > > > > > > > > > > > > > > > > > > > Any help would be greatly > > appreciated. > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > few months ago on this transponder was nearly 30% of > > null PID packets > > > > > broadcasted, but now it seems to be much better (less > > than 1Mbps). Also > > > > > multiplexing of this transponder was not equal within > > time - there was > > > > > chunks of packets of PlanetHD multiplexed with chunks > > of other SD > > > > > channels mixed packets. Maybe the buffers for USB are > > not big enough to > > > > > memorize such chunks? But I didn't done measuring for > > some months, so > > > > > the situation may be different now. > > > > > > > > > > You can see bitrates of this transponder at > > > > > http://www.digitalbitrate.com/dtv.php?mux=11817&pid=5410&live=70&lang=en > > . > > > > > > > > > > The bitrate of this channel is nothing special, with > > maximum about 11 > > > > > Mbps, the peak of 20.2Mbps at 22.5. was maybe a joke. > > > > > > > > > > Regards, > > > > > > > > > > Ales > > > > Hi, > > > > Since 20 Nov transponders 12051V and 12207V on the same > > satellite Astra 3B were switched to fec=5/6 and they also > > became unwatchable. Before the change they were 8psk, > > fec=3/4. Now they are 8psk, fec=5/6. > > > > _______________________________________________ > have you tried this patch written by Old_Man? > > http://www.vdr-portal.de/board16-video-disk-recorder/board85-hdtv-dvb-s2/p9… > > kind regards > > Newsy > > _______________________________________________ I am running kernel 3.6.2 on that particular machine and as far as I can tell that patch is already included. I also tried reverting it but it didn't help. For me the telling difference can be seen here: http://www.digitalbitrate.com/dtv.php?liste=1&live=70&lang=en&mux=12207 Before the change to fec=5/6 the total bitrate of 12207V and 12051V was below 60Mbps. Now it is over 65Mbps. According to the spec for Technotrend S2-3200 (http://www.tt-downloads.de/update/engl/techspec_tt-budget_s2-3200_en.pdf) 60Mbps is the limit for DVB-S. For DVB-S2 it is stated that the card supports bitrates of up to 90Mbps. So my next guess is that the linux driver implementation somehow precludes the support of bitrates above 90Mbps for DVB-S2, which are technically possible nonetheless. After all I was able to accidentally get proper lock on these transponders a couple of times but it is very hard to reproduce.

1 0

ScaleVideo Discussion: API extension or custom service?
by Lucian Muresan 28 Nov '12

28 Nov '12

Hi there, let me start with the background of this, in the last few weeks, a very promising new true color skin raised some attention on the german speaking VDR-Portal, namely "nOpacity" ([1] and [2]). The layout of some of the screens quickly brought up the idea that it would be nice to have the video properly scaled to the available size (smaller than the actual screen), which I tried to already patch with some (but only some) success ([3]). The patch is based on an old hack, called "YaEPG patch", which introduces a member of type tArea in cOsd, which then can be filled with geometry information, whose "bpp" member is abused as a hint weather or not to scale by some skin or plugin which wants to scale down the video material, and you got it, it's as ugly as can be. The problems which we encountered where that the output plugin (in this case softhddevice) knows much more about the video material (like if it is for example 4:3 letterboxed, if the user selected some zooming, some cropping, and so on) than a skin or any other plugin can cope with, in order to get the video scaled right, and there are cases where the scaling is simply wrong. It is and should remain the job of the output plugin to do this right with all the information it has access to, other plugins should only have to ask them to "properly" scale inside an available rectangle, possibly with the hint to just scale (back) full-size of the output device (which could also be an X window). Now, my question, is this issue worth an API extension in cDevice, for example something like bool ScaleVideo(tArea availableRectangle); bool ScaleVideoFullScreen(); which could return true only if the output plugin is capable of doing this, or should plugin developers rather agree upon a custom service which output plugins may provide and skins or other plugins may ask for? Regards, Lucian [1]: http://www.vdr-portal.de/board1-news/board2-vdr-news/115810-announce-skin-n… [2]: http://www.vdr-portal.de/board16-video-disk-recorder/board55-vdr-plugins/11… [3]: http://www.vdr-portal.de/board1-news/board2-vdr-news/p1106087-announce-skin…

3 3

[ANNOUNCE] epgfixer-plugin 0.3.1
by Matti Lehtimäki 28 Nov '12

28 Nov '12

This release fixes a critical memory leak in the plugin introduced in previous version. Bug fixes: - Fix memory leak. - Drop OBJS dependency from cppcheck target (thanks to Ville Skyttä). Homepage for the plugin: http://projects.vdr-developer.org/projects/plg-epgfixer -- Matti Lehtimäki

1 0

How remove underscore ( _ ) directory from vdr recording directories?
by Michael Smith 28 Nov '12

28 Nov '12

Hello, I'm so sorry to ask this, because it may seems silly, but my vdr 1.7.x creates an directory named just _ (underscore) and then create recording directories for date-time. I'v searched internet, and found this post from Klaus which describes why underscore is created: http://osdir.com/ml/linux.vdr/2003-10/msg00208.html But I can't find any comment on how disable this behavior. The underscore is annoying in my case, because most of my recordings has not any episode name, and this means additional underscores without any use. Best regards. Mike Smith.

2 2

Re: [vdr] Skystar USB HD + VDR + Astra 23.5E 11817 V / 8psk, fec=5/6
by N. D. 27 Nov '12

27 Nov '12

>-------- Оригинално писмо -------- >От: Ales Jurik ajurik(a)quick.cz >Относно: Re: [vdr] Skystar USB HD + VDR + Astra 23.5E 11817 V / 8psk,fec=5/6 >До: VDR Mailing List <vdr(a)linuxtv.org> >Изпратено на: Сряда, 2012, Юни 13 18:34:55 EEST > On 06/13/12 10:45, N. D. wrote: > > > > Hi, > > Since recently I have been using Skystar USB HD with my vdr > > box. However I have some strange issues with 11817V on Astra 23.5E. > > Femon reports that there is a lock and sound comes but the image is > > completely garbled. I am starting to suspect that there might be > > something wrong with the driver, because I have no trouble with the > > other transpoders. Maybe it is the combination of fec=5/6 and 8psk on > > the said transponder that is the reason for this. Other transponders > > with fec=3/4 and 8psk are OK. The same setup with an HVR-4000 works > > fine. > > > > Kernel: 3.3.4 > > > > VDR: 1.7.27 > > > > Could someone who owns a Skystar USB HD and has access to Astra 23.5E > > share his experience? Is this a driver issue a problem with vdr or is my card faulty? > > > > If someone would be kind enough to test this with his/hers hardware, there is a FTA channel on the problematic transponder: > > > > > > > > Planeta HD;SatelliteBG:11817:VC56M5O35S1:S23.5E:27500:1001=27:1002=@3:0:0:5410:3:3206:0 > > > > > > > > Any help would be greatly appreciated. > > > > Hi, > > few months ago on this transponder was nearly 30% of null PID packets > broadcasted, but now it seems to be much better (less than 1Mbps). Also > multiplexing of this transponder was not equal within time - there was > chunks of packets of PlanetHD multiplexed with chunks of other SD > channels mixed packets. Maybe the buffers for USB are not big enough to > memorize such chunks? But I didn't done measuring for some months, so > the situation may be different now. > > You can see bitrates of this transponder at > http://www.digitalbitrate.com/dtv.php?mux=11817&pid=5410&live=70&lang=en . > > The bitrate of this channel is nothing special, with maximum about 11 > Mbps, the peak of 20.2Mbps at 22.5. was maybe a joke. > > Regards, > > Ales Hi, Since 20 Nov transponders 12051V and 12207V on the same satellite Astra 3B were switched to fec=5/6 and they also became unwatchable. Before the change they were 8psk, fec=3/4. Now they are 8psk, fec=5/6.

2 1

Digital Devices (Linux 4 Media) 4 port (8 tuner) octopus/Duoflex experiences
by Oliver Schinagl 27 Nov '12

27 Nov '12

Hey VDR friends, I'm thinking of getting into the whole satellite thing (DVB-T user for now) and was searching for interesting DVB-S2 tuners. I found that the l4m octopus/duoflex-s2 a very interesting device. While expensive you can connect up to 8 tuners! to a single PCI-e 1x lane (Bandwith should be more then enough). While I know there is a octopus mini-pcie device, I heard that there where some PCB issues so decided on getting the PCI-e version. I have tried googling for some up to date linux! information but found very little. Are there any l4m/dd octopus/duoflex DVB-S2 (or even CAM/DVB-C/DVB-T) users here that can share their current (and past) experiences? The tuner (only 1 dualtuner board and the octopus) will set you back a good 200Euro so I want to be sure that the devices is properly supported. Thanks, Oliver

10 32

Redundancy in Make.config and Make.global
by Christopher Reimer 21 Nov '12

21 Nov '12

I just noticed that both Make.confg and Make.global contain this block: ifdef PLUGIN CFLAGS += -fPIC CXXFLAGS += -fPIC endif I tried to remove this block out of Make.config, which leads to plugin compilation problems, because -fPIC is not set. After a closer look into the Makefiles, I've started to think that there's a bigger problem. The main Makefile starts more or less the plugin Makefile Inside the plugin Makefile: At first it defines PLUGIN (e.g. PLUGIN = dvbsddevice) Then it sets the plugin compile parameters (-g -O3 -Wall -Werror=overloaded-virtual -Wno-parentheses) Afterwards it reads Make.global and it adds fPIC (-g -O3 -Wall -Werror=overloaded-virtual -Wno-parentheses -fPIC) And after that the Make.config gets included, which overwrites all parameters. We're back at the beginning without -fPIC (-g -O3 -Wall -Werror=overloaded-virtual -Wno-parentheses) I think Make.global and Make.config are included in the wrong order. Make.config should be included first, and Make.global afterwards. I know that all plugin Makefiles need to be edited again. But I think that is the only working solution. Christopher Reimer

1 0

vdr-1.7.32 plugin dvbhddevice fails
by Richard Scobie 21 Nov '12

21 Nov '12

I have just upgraded from vdr-1.7.31 to vdr-1.7.32 with S2-6400 and on making plugins, I receive the following error: make[2]: Entering directory `/home/rs/vdr-1.7.32/PLUGINS/src/dvbhddevice/libhdffcmd' gcc -O3 -Wall -fPIC -shared -o libhdffcmd-0.1.0.so bitbuffer.o hdffcmd_av.o hdffcmd_base.o hdffcmd_generic.o hdffcmd_hdmi.o hdffcmd_mux.o hdffcmd_osd.o hdffcmd_remote.o /usr/bin/ld: bitbuffer.o: relocation R_X86_64_PC32 against undefined symbol `memset@@GLIBC_2.2.5' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: Bad value collect2: ld returned 1 exit status make[2]: *** [libhdffcmd-0.1.0.so] Error 1 As "-fPIC" is being used, I am not sure how to handle the comment, "recompile with -fPIC" Regards, Richard

4 6

[ANNOUNCE] VDR developer version 1.7.32
by Klaus Schmidinger 20 Nov '12

20 Nov '12

VDR developer version 1.7.32 is now available at ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.32.tar.bz2 A 'diff' against the previous version is available at ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.31-1.7.32.diff MD5 checksums: 068ba78fd427694dcc480fe3b2d07148 vdr-1.7.32.tar.bz2 222f1e9b4d4edaa6fe57286409614cc7 vdr-1.7.31-1.7.32.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 main focus of this version is on an improved frame detection code, and improvements to the cutting process. When cutting a recording, VDR now removes any "dangling" TS packets from the beginning of an editing sequence and pulls in any "pending" TS packets at the end of a sequence. It also fixes all timestamps and continuity counters. However, while the results look much better now in, for instance, Kaffeine, the TT S2-6400 still shows some video artifacts at the editing points, and the Mac video player sometimes totally chokes on edited material. I did spend a lot of time trying to find out what could still be wrong here, but couldn't come up with any new ideas. So I think it's now time to invite others to test this new cutting code, read the source code and try to find out what's still going wrong here. Maybe (hopefully ;-) it's just some stupid little error... ;-) The changes since version 1.7.31: - Pressing the Play key during normal live viewing mode now opens the Recordings menu if there is no "last viewed" recording (thanks to Alexander Wenzel). The same behavior has been implemented for the Blue key in the main menu. - cIoThrottle::Engaged() is now also checked in cRemoveDeletedRecordingsThread::Action(), to suspend removing deleted recordings in case this is necessary to make room for new, ongoing recordings (suggested by Udo Richter). - The cThread constructor now has an additional boolean parameter that can be set to true to have this thread run at a lower priority. Plugin authors that use low priority threads may want to use this instead of the calls to SetPriority(19) and SetIOPriority(7). The priority of a thread ("low" or "high") is now logged when the thread starts. - Changed DTV_DVBT2_PLP_ID to DTV_STREAM_ID in dvbdevice.c to adapt to an incompatible change in DVB API 5.8 (reported by Derek Kelly). Removed the meanwhile obsolete definition of FE_CAN_TURBO_FEC. - Fixed some compiler warnings under gcc version 4.7.1. - Fixed setting the video format in the dvbhdffdevice (thanks to Torsten Lang). - Fixed 'make install' to not overwrite existing configuration files (thanks to Peter Münster). - Added including the Make.global and Make.config files to the dvbdhffdevice's libhdffcmd/Makefile. - Added options to build a 32-bit version of VDR on a 64-bit machine to Make.config.template. - Fixed handling VPS timers in case the running status of an event goes to '1' (not running) and later goes to '4' (running). - If a frame position in the 'marks' file of a recording doesn't point to an I-frame, it will now be shifted towards the next I-frame, either up or down, whichever is closer (suggested by Udo Richter). - Fixed a possible memory leak in SI::StructureLoop::getNextAsPointer() (reported by Sundararaj Reel). - Fixed handling timers in case an event is modified and "phased out" while the timer is recording. - Improved frame detection by parsing just far enough into the MPEG-4 NAL units to get the necessary information about frames and slices. - The initial syncing of the frame detector is now done immediately after the first complete GOP has been seen. This makes recordings and especially pausing live video start up to twice as fast as before. - Updated the Romanian OSD texts (thanks to Lucian Muresan). - Fixed handling the very last entry in a recording index. - The return type of cMarks::Add() has been changed to void, since due to the sorting of the list of marks the returned pointer might have pointed to a totally different mark. Besides, the return value was never actually used. - Improved editing TS recordings by + stripping dangling TS packets from the beginning of a sequence + including pending TS packets at the end of a sequence + fixing all timestamps and continuity counters + generating editing marks for the edited version in such a way that each cutting point is marked by an "end" and "begin" mark with the same offset + no longer generating an editing mark at the "end" of the edited recording (this was actually generated at the beginning of the last GOP, so that a subsequent edit would have cut off the last GOP) + no longer generating any editing marks if the edited recording results on just one single sequence + ignoring pairs of editing marks that are placed at exactly the same position of a recording when actually cutting the recording + not doing anything if the editing marks in place would result in the edited version being the same as the original recording - Editing marks can now be placed directly on top of each other, in which case they simply mark a position, but have no effect on the actual cutting process. - When positioned at an offset where two (or more) editing marks are placed on top of each other, the '4' key moves the first one of them to the left, while the '6' key moves the last one of them to the right. The '7' and '9' key handle multiple marks at the same place as if it were one single mark. - Modified editing marks are now written to disk whenever the replay progress display gets hidden (thanks to Christoph Haubrich). Have fun! Klaus

3 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

vdr November 2012