Re: [vdr] EEPG (was Re: Channel 4 HD on Freesat)
On 12.03.2012 23:01, Tony Houghton wrote: ... I do have to restart VDR every few days anyway, because it has a memory leak. Disabling eepg didn't fix that IIRC, and the leak hides from valgrind. Which version of VDR are you using? Are you sure this is caused by the core VDR code, or could this be one of the plugins or patches you are using (if any)? I'm asking because I don't see an ever increasing memory footprint on my VDR. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] EEPG (was Re: Channel 4 HD on Freesat)
On Tue, 13 Mar 2012 09:55:06 +0100 Klaus Schmidinger wrote: > On 12.03.2012 23:01, Tony Houghton wrote: > > ... > >I do have to restart VDR every few days > > anyway, because it has a memory leak. Disabling eepg didn't fix that > > IIRC, and the leak hides from valgrind. > > Which version of VDR are you using? > Are you sure this is caused by the core VDR code, or could this > be one of the plugins or patches you are using (if any)? > I'm asking because I don't see an ever increasing memory footprint > on my VDR. No, I haven't seen anybody else complain about this either. It's been happening to me for quite a long time, for several versions. I use the Debian packages. I thought it could be the eepg plugin but disabling that didn't seem to fix the leak. I also use xineliboutput and remote plugins, but I've been using those for years, before the leak started. At one point it stopped leaking and I realised I'd messed up my channels.conf so either all the DVB-T or all the DVB-S channels were broken and the leak came back when I fixed that. I think I tried reproducing similar conditions but for some reason I didn't make an effort to record or remember the results! I should repeat that and make notes, but it takes about a day on each run before I can be reasonably sure whether it's leaking or not. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] vdr crashes when replaying zero length recording
I've seen this a lot lately. due to tuning problems with my nova-t 500s, I've gotten frequent zero length recordings. Playing back these either using the xine plugin, or xineliboutput, causes VDR to crash and restart. I'm using yavdr with only trivial modifications. -- -Tor ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] EEPG (was Re: Channel 4 HD on Freesat)
On 13.03.2012 14:44, Tony Houghton wrote: On Tue, 13 Mar 2012 09:55:06 +0100 Klaus Schmidinger wrote: On 12.03.2012 23:01, Tony Houghton wrote: ... I do have to restart VDR every few days anyway, because it has a memory leak. Disabling eepg didn't fix that IIRC, and the leak hides from valgrind. Which version of VDR are you using? Are you sure this is caused by the core VDR code, or could this be one of the plugins or patches you are using (if any)? I'm asking because I don't see an ever increasing memory footprint on my VDR. No, I haven't seen anybody else complain about this either. It's been happening to me for quite a long time, for several versions. I use the Debian packages. I thought it could be the eepg plugin but disabling that didn't seem to fix the leak. I also use xineliboutput and remote plugins, but I've been using those for years, before the leak started. At one point it stopped leaking and I realised I'd messed up my channels.conf so either all the DVB-T or all the DVB-S channels were broken and the leak came back when I fixed that. I think I tried reproducing similar conditions but for some reason I didn't make an effort to record or remember the results! I should repeat that and make notes, but it takes about a day on each run before I can be reasonably sure whether it's leaking or not. Can you give me an estimate of the rate at which memory is consumed? Maybe you could have a shell running the command top -b -d 600 | grep -w vdr for a while and see whether the numbers increase. This will show a line like 27558 kls 20 0 206m 49m 3860 S2 2.5 0:33.44 vdr every ten minutes, where "206m" and "49m" are the relevant columns. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr crashes when replaying zero length recording
On Tue, Mar 13, 2012 at 8:08 AM, Torgeir Veimo wrote: > I've seen this a lot lately. due to tuning problems with my nova-t > 500s, I've gotten frequent zero length recordings. Playing back these > either using the xine plugin, or xineliboutput, causes VDR to crash > and restart. > > I'm using yavdr with only trivial modifications. I compile VDR myself and never have this problem. I use vdr-xine and have been test softhddevice but in case of an empty recording, VDR just returns to live tv. Sounds like a yavdr problem -- last I heard yavdr uses a bunch of patches but since I don't use it I don't know that 100%. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Memory leak (was Re: Channel 4 HD on Freesat)
On Tue, 13 Mar 2012 16:11:44 +0100 Klaus Schmidinger wrote: > Can you give me an estimate of the rate at which memory is consumed? > Maybe you could have a shell running the command > >top -b -d 600 | grep -w vdr At the moment: 25956 vdr 20 0 520m 213m 5136 S 0.7 11.3 28:27.27 vdr After a restart: 24585 vdr 20 0 257m 43m 5316 S 0.0 2.3 0:00.88 vdr It starts to have a noticeable impact on the box's general performance when %MEM reaches 50% IME. I'll run top for longer like you suggest, then try all plugins disabled and with DVB-T and DVB-S lines removed from channels.conf in turn. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr crashes when replaying zero length recording
> last I heard yavdr uses a bunch of patches but since I don't use it I don't > know that 100%. Well that's always good and cheap to talk about things about any individual heard about ... :-( @Torgeir Which version of yavdr do you use? Might it be possible to open a case on vdr-portal.de in yavdr sub-forum? English language is pretty much ok, at least I'm able to answer ... ;-) Regards fnu of yavdr-team ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Memory leak (was Re: Channel 4 HD on Freesat)
Am 13.03.2012 17:52, schrieb Tony Houghton: > memory leak I just met hepi, he also is a Doctor Who fan and is tuned to Astra2 as I am. He complained about the bad status of EEPG, restarting his server every three days or so due to a memory leak within that plugin. As this is a 'must have' if you are on Freesat, it might be closely related, even if you feel it is not... I personally do not care because I have the receiver off most of the time. How would you analyze or debug a memory leak in a running environment: - which thread/plugin is the root cause? - which datastructure sees the growth? - which allocs are not bracketed by a proper de-alloc? Here is the output: 3621 vdruser 20 0 636m 80m 17m S2 1.1 0:00.78 vdr 3621 vdruser 20 0 638m 96m 17m S3 1.3 0:17.30 vdr 3621 vdruser 20 0 643m 100m 17m S3 1.3 0:34.20 vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr crashes when replaying zero length recording
On Tue, Mar 13, 2012 at 11:54 AM, Frank Neumann wrote: >> last I heard yavdr uses a bunch of patches but since I don't use it I don't >> know that 100%. > > Well that's always good and cheap to talk about things about any individual > heard about ... :-( There is nothing wrong with passing along what you've heard. Furthermore, I intentionally pointed out that I don't know that to be 100% true. Your claim that my comment is "cheap" is completely uncalled for. If you wanted to reply, rather than trying to insult me you should have clarified that YES yavdr applies patches to VDR, or NO it does not. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr crashes when replaying zero length recording
> Your claim that my comment is "cheap" is completely uncalled for. Well, just needless, even you should realize that comments like this don't help anybody. That's what I read: "Hey stupid I'm super cool and able to compile VDR by myself, you're a nobody just able to use this bullshit yaVDR ..." And I guess I'm pretty much not alone with this impression, or did you had just a fragment of any helpful value for that guy ... Cheers fnu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] remote.conf question
I have a remote control that on pressing a single specific key it sends two keys at once 80010051 00 KEY_3 VRC-1100 8001004c 00 KEY_5 VRC-1100 Can I use this key somehow in vdr´s remote.con (to assign a command in the even that KEY_3 and KEY_5 are received at once) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr crashes when replaying zero length recording
On Tue, Mar 13, 2012 at 12:43 PM, Frank Neumann wrote: > That's what I read: "Hey stupid I'm super cool and able to compile VDR by > myself, you're a nobody just able to use this bullshit yaVDR ..." Then you're a complete idiot because that is NOT what I said. Grow up. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr crashes when replaying zero length recording
Got some hints at the vdr portal on how to get debug output. The crashlog contains this stacktrace; I presume it would be cause by one of the patches yavdr uses, since it also happens with only the xine plugin enabled. This is yavdr 0.4, with latest updates as of today. Program terminated with signal 6, Aborted. #0 0x00c06416 in __kernel_vsyscall () #0 0x00c06416 in __kernel_vsyscall () #1 0x0040ae71 in raise () from /lib/i386-linux-gnu/libc.so.6 #2 0x0040e34e in abort () from /lib/i386-linux-gnu/libc.so.6 #3 0x004427f7 in ?? () from /lib/i386-linux-gnu/libc.so.6 #4 0x0044cbe1 in ?? () from /lib/i386-linux-gnu/libc.so.6 #5 0x0044e50b in ?? () from /lib/i386-linux-gnu/libc.so.6 #6 0x0045169d in free () from /lib/i386-linux-gnu/libc.so.6 #7 0x001e94d1 in operator delete(void*) () from /usr/lib/i386-linux-gnu/libstdc++.so.6 #8 0x080d23c4 in cDvbPlayer::~cDvbPlayer (this=0xaea43030, __in_chrg=) at dvbplayer.c:323 #9 0x080d24c3 in cDvbPlayer::~cDvbPlayer (this=0xaea43030, __in_chrg=) at dvbplayer.c:329 #10 0x080d4d7c in cDvbPlayerControl::Stop (this=0xaea42ec0) at dvbplayer.c:963 #11 0x081080dd in cReplayControl::Stop (this=0xaea42ec0) at menu.c:5165 #12 0x08107e2d in cReplayControl::~cReplayControl (this=0xaea42ec0, __in_chrg=) at menu.c:5131 #13 0x007607f1 in myReplayControl::~myReplayControl() () from /usr/lib/vdr/plugins/libvdr-extrecmenu.so.1.7.22 #14 0x00760842 in myReplayControl::~myReplayControl() () from /usr/lib/vdr/plugins/libvdr-extrecmenu.so.1.7.22 #15 0x081214c0 in cControl::Shutdown () at player.c:106 #16 0x081615fa in main (argc=49, argv=0xbfa68634) at vdr.c:1241 -- -Tor ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr crashes when replaying zero length recording
Hi Tor, well honestly, I don't think it's one of the patches, it seems for me rather to be again somehow "vdr-plugin-extrecmenu". The VDR version as of today has been tested since 2 month, to become part for stable-vdr (first lucid, then natty) and nobody did realize this problem. But I need to mention, pretty sure nobody did test extrecmenu, it isn't part of "yavdr-essential". Could you please try to replay these recordings using the VDRs own functionality? Regards fnu PS.: It would be much easier to chat about this in a thread in vdr-portal.de, instead of bothering this mailing list. -Original Message- From: vdr-boun...@linuxtv.org [mailto:vdr-boun...@linuxtv.org] On Behalf Of Torgeir Veimo Sent: Wednesday, March 14, 2012 1:34 AM To: VDR Mailing List Subject: Re: [vdr] vdr crashes when replaying zero length recording Got some hints at the vdr portal on how to get debug output. The crashlog contains this stacktrace; I presume it would be cause by one of the patches yavdr uses, since it also happens with only the xine plugin enabled. This is yavdr 0.4, with latest updates as of today. Program terminated with signal 6, Aborted. #0 0x00c06416 in __kernel_vsyscall () #0 0x00c06416 in __kernel_vsyscall () #1 0x0040ae71 in raise () from /lib/i386-linux-gnu/libc.so.6 #2 0x0040e34e in abort () from /lib/i386-linux-gnu/libc.so.6 #3 0x004427f7 in ?? () from /lib/i386-linux-gnu/libc.so.6 #4 0x0044cbe1 in ?? () from /lib/i386-linux-gnu/libc.so.6 #5 0x0044e50b in ?? () from /lib/i386-linux-gnu/libc.so.6 #6 0x0045169d in free () from /lib/i386-linux-gnu/libc.so.6 #7 0x001e94d1 in operator delete(void*) () from /usr/lib/i386-linux-gnu/libstdc++.so.6 #8 0x080d23c4 in cDvbPlayer::~cDvbPlayer (this=0xaea43030, __in_chrg=) at dvbplayer.c:323 #9 0x080d24c3 in cDvbPlayer::~cDvbPlayer (this=0xaea43030, __in_chrg=) at dvbplayer.c:329 #10 0x080d4d7c in cDvbPlayerControl::Stop (this=0xaea42ec0) at dvbplayer.c:963 #11 0x081080dd in cReplayControl::Stop (this=0xaea42ec0) at menu.c:5165 #12 0x08107e2d in cReplayControl::~cReplayControl (this=0xaea42ec0, __in_chrg=) at menu.c:5131 #13 0x007607f1 in myReplayControl::~myReplayControl() () from /usr/lib/vdr/plugins/libvdr-extrecmenu.so.1.7.22 #14 0x00760842 in myReplayControl::~myReplayControl() () from /usr/lib/vdr/plugins/libvdr-extrecmenu.so.1.7.22 #15 0x081214c0 in cControl::Shutdown () at player.c:106 #16 0x081615fa in main (argc=49, argv=0xbfa68634) at vdr.c:1241 -- -Tor ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr crashes when replaying zero length recording
On 14 March 2012 10:57, Frank Neumann wrote: > Hi Tor, > > well honestly, I don't think it's one of the patches, it seems for me rather > to be again somehow "vdr-plugin-extrecmenu". > The VDR version as of today has been tested since 2 month, to become part for > stable-vdr (first lucid, then natty) and nobody did realize this problem. But > I need to mention, pretty sure nobody did test extrecmenu, it isn't part of > "yavdr-essential". > Could you please try to replay these recordings using the VDRs own > functionality? I simply temporarily removed /usr/lib/vdr/plugins/libvdr-extrecmenu.so.1.7.22 (just negging it in oder.conf didn't work) and restarted vdr-dbg. Here's the crashlog from that run; -- -Tor Crashlog from Wed Mar 14 11:06:41 EST 2012 -- Environment details: TERM=linux EXIT_SIGNAL=ABRT PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin PWD=/ JOB=vdr RESULT=failed SHLVL=1 PROCESS=main UPSTART_INSTANCE= UPSTART_EVENTS=stopped UPSTART_JOB=vdr-exit-other INSTANCE= _=/usr/bin/env Command line: /usr/bin/vdr-dbg --lirc=/var/run/lirc/lircd -v /srv/vdr/video.00 -c /var/lib/vdr -L /usr/lib/vdr/plugins -r /usr/lib/vdr/vdr-recordingaction -s -E /var/cache/vdr/epg.data -u vdr -g /tmp --port 6419 -w 0 -D 1 2 3 -Pxine -r -Plcdproc -Piptv -Ptext2skin -Pmenuorg -Pfemon -Pepgsearch -f /usr/bin/svdrpsend -Pxvdr -t 10 -Pstreamdev-server -Pchannellists -Pdbus2vdr -Pskinenigmang --logodir=/usr/share/vdr-enigmang-icons --epgimages=/var/cache/vdr/epgimages -Plive --port=8008 --ip=0.0.0.0 --epgimages=/var/cache/vdr/epgimages -Prestfulapi --port=8002 --ip=0.0.0.0 --epgimages=/var/cache/vdr/epgimages --channellogos=/usr/share/vdr-channellogos -Pquickepgsearch -Pskinpearlhd --epgimages=/var/cache/vdr/epgimages -Pmarkad -Pepgsearchonly -Pwirbelscan -Pconflictcheckonly -Pdynamite &> /tmp/vdr.log Versions: - vdr (1.7.22/1.7.22) - The Video Disk Recorder xine (0.9.4) - Software based playback using xine lcdproc (0.0.10-jw8) - LCDproc output iptv (0.4.2) - Experience the IPTV text2skin (1.3.2+git) - Loader for text-based skins menuorg (0.4.5) - Reorganizes the main menu femon (1.7.11) - DVB Signal Information Monitor (OSD) epgsearch (1.0.1) - search the EPG for repeats and more xvdr (0.9.5) - VDR-Network-Streaming-Interface (XVDR) Server streamdev-server (0.5.1-git) - VDR Streaming Server channellists (0.0.4) - Manage your channellists dbus2vdr (0.0.2j) - expose methods for controlling vdr via DBus skinenigmang (0.1.1) - EnigmaNG skin live (0.2.0) - Live Interactive VDR Environment restfulapi (0.1.0) - Offers a RESTful-API to retrieve data from VDR quickepgsearch (0.0.1) - Quick search for broadcasts skinpearlhd (0.0.1) - PearlHD Skin markad (0.1.3) - Mark advertisements epgsearchonly (0.0.1) - Direct access to epgsearch's search menu wirbelscan (0.0.7) - DVB and pvrinput channel scan for VDR conflictcheckonly (0.0.1) - Direct access to epgsearch's conflict check menu dynamite (0.0.9a) - attach/detach devices on the fly Backtrace: -- [New Thread 16992] [New Thread 17062] [New Thread 17066] [New Thread 17067] [New Thread 17068] [New Thread 17069] [New Thread 17070] [New Thread 17071] [New Thread 17072] [New Thread 17073] [New Thread 17074] [New Thread 17075] [New Thread 17076] [New Thread 17077] [New Thread 17078] [New Thread 17079] [New Thread 17080] [New Thread 17099] [New Thread 17103] [New Thread 17105] [New Thread 17106] [New Thread 17107] [New Thread 17108] [New Thread 17109] [New Thread 17110] [New Thread 17112] [New Thread 17113] [New Thread 17114] [New Thread 17115] [New Thread 17116] [New Thread 17117] [New Thread 17118] [New Thread 17119] [New Thread 17120] [New Thread 17121] [New Thread 17122] [New Thread 17124] [New Thread 17123] [New Thread 17104] Core was generated by `/usr/bin/vdr-dbg --lirc=/var/run/lirc/lircd -v /srv/vdr/video.00 -c /var/lib/vd'. Program terminated with signal 6, Aborted. #0 0x00b31416 in __kernel_vsyscall () #0 0x00b31416 in __kernel_vsyscall () #1 0x00515e71 in raise () from /lib/i386-linux-gnu/libc.so.6 #2 0x0051934e in abort () from /lib/i386-linux-gnu/libc.so.6 #3 0x0054d7f7 in ?? () from /lib/i386-linux-gnu/libc.so.6 #4 0x00557be1 in ?? () from /lib/i386-linux-gnu/libc.so.6 #5 0x0055950b in ?? () from /lib/i386-linux-gnu/libc.so.6 #6 0x0055c69d in free () from /lib/i386-linux-gnu/libc.so.6 #7 0x001e94d1 in operator delete(void*) () from /usr/lib/i386-linux-gnu/libstdc++.so.6 #8 0x080d23c4 in cDvbPlayer::~cDvbPlayer (this=0xae122058, __in_chrg=) at dvbplayer.c:323 #9 0x080d24c3 in cDvbPlayer::~cDvbPlayer (this=0xae122058, __in_chrg=) at dvbplayer.c:329 #10 0x080d4d7c in cDvbPlayerControl::Stop (this=0xae145440) at dvbplayer.c:963 #11 0x081080dd in cReplayControl::Stop (this=0xae145440) at menu.c:5165 #12 0x08107e2d in cReplayControl::~cReplayControl (this=0xae145440, __in_chrg=) at menu.c:5131 #13 0x08107eb3 in cReplayControl::~cReplayControl (this=0xae145440, __in_chrg=) at menu.c
[vdr] locale issue with --edit
This was driving me mad! I have a NTSC TS-recording with 29.97002997 fps. When I set cut marks via the VDR-OSD and cut the recording, this works fine. But when I cut the same recording with the same cut marks with `vdr --edit`, the cut points are offset by some seconds e.g. the beginning of the cutted recording is about 9 seconds earlier than it should be. Reason: When invoking `vdr --edit` LC_NUMERIC is *not* set to "C" yet when CutRecording() is called. My default locale uses "," as the decimal point, causing the framerate to be parsed as 29.0 instead of 29.97002997. setlocale(LC_NUMERIC, "C") should be called earlier in main(). Tobias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
