Re: [vdr] problems with playback and plugins with vdr-1.7.22
On 08/01/2012 08:43, René wrote: On 07.01.2012 23:23 , René wrote: The patch compiles now fine, but when activating livebuffer, vdr crashes with the following in the logs: I realized that i forgot to turn back a couple Gentoo-useflags that i had active til now: cutterlimit ddepgentry hardlinkcutter mainmenuhooks pinplugin timerinfo wareagleicon yaepg lircsettings Putting these back seems to have fixed the crash.. Still having trouble with playback/rewind/forwad of Regards, René ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr Yes, it works like this but it's a temporary workaround. I checked what Udo say and this is the real problem, the USE_LIVEBUFFER flag is not in use when the plugins are compiled. I don't know how to propagate this flag with portage. This would be a better solution. Regards, Marc. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] problems with playback and plugins with vdr-1.7.22
On Sat, 7 Jan 2012, René wrote: Then i got an other problem. When watching a recording, and i fastforward of rewind the program, i get to a situation that the timecounter get's stuck to the frame i start from. The film moves, but when i hit play, i end up back to the frame from where i started to rewind/fastforwad. The only way to fix this is to jump with the yellow/green buttons. AFter this i can rewind/fastforwad normally. This again works for a while, but again if it fails to stop to the place i rewind to, i have to reset the rewind-issue with the yellow/green buttons... Is this a known bug in vdr, or is it something that i have messed up in my setup? I was under impression that this is already fixed in xineliboutput 10.12.2011 or newer. BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] problems with playback and plugins with vdr-1.7.22
On 08.01.2012 14:48 , Rolf Ahrenberg wrote: On Sat, 7 Jan 2012, René wrote: Then i got an other problem. When watching a recording, and i fastforward of rewind the program, i get to a situation that the timecounter get's stuck to the frame i start from. The film moves, but when i hit play, i end up back to the frame from where i started to rewind/fastforwad. The only way to fix this is to jump with the yellow/green buttons. AFter this i can rewind/fastforwad normally. This again works for a while, but again if it fails to stop to the place i rewind to, i have to reset the rewind-issue with the yellow/green buttons... Is this a known bug in vdr, or is it something that i have messed up in my setup? I was under impression that this is already fixed in xineliboutput 10.12.2011 or newer. Hi Rofa, I forgot to mention that i'm using dvbsddevice for outputting the signal via my FF-card. I think that my epia mii 12000 does not have enough horsepower (bit-power? :-) for using the onboard video output-connectors.. I actually never tried to use any other way to get a picture out from this board, because i was told that it will not work... René ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] problems with playback and plugins with vdr-1.7.22
On 08/01/2012 13:26, René wrote: On 08.01.2012 10:44 , Marc wrote: Yes, it works like this but it's a temporary workaround. I checked what Udo say and this is the real problem, the USE_LIVEBUFFER flag is not in use when the plugins are compiled. I don't know how to propagate this flag with portage. This would be a better solution. Hi Marc, I have USE_LIVEBUFFER=1 in /etc/make.conf, but this then does not seem to work correctly? The problem is to know how to tell portage to add this flag to gcc. With the others flags, this is done automatically, probably by the scripts launched in the ebuilds. I don't know how to do the same thing for local patches. Is the forwads/backward feature also part of this problem, or is it just me who has this problem.. I don't have this problem, I can't tell. I can use forward/backward on records and livebuffer. Has vdr-1.7 btw more resource-requirements than vdr-1.6? I still run my vdr on an epia mii 12000 board with 1gb memory. The 1.7 version of vdr has much more problem in keeping the palyback in sync. Also live-tv has problems keeping in sync. The sound is very often seconds behind the image... vdr itself take very low resources, it's the rendering witch require some resources. I use a nvidia card so all this part is handled by vdpau and, even in hd, my cpu has almost no load. Regards, Marc. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] problems with playback and plugins with vdr-1.7.22
On 07.01.2012 3:44 , Udo Richter wrote: The cryptic symbol decodes to cTimer::cTimer(bool, bool, cChannel*), found in timers.h, line 46. The actual code is in timers.c, line 28. This function exists in this form since 1.3.38. VDR itself seems to be fine, so your VDR seems to have a different function instead. However, the plugins rely on the original function because they somehow compiled against the original definition in the timers.h. My guess is that one of the patches is optionally modifying this, and the plugins were somehow compiled with different versions of the timers.h, or with different compiler flags that cause some #ifdef to flip. Ok, i'll check if this would would work without any patches.. I doubt that I would be the only one with this issue if it would be the patches.. But again i would'nt surprise me if my system is messed up because of this big jump from 1.6.x to 1.7.22. Til now VDR has been a set and forget installation that just works, and works, and works and wo... :-) Regards, René ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] problems with playback and plugins with vdr-1.7.22
On 07.01.2012 11:59 , René wrote: Ok, i'll check if this would would work without any patches.. I doubt that I would be the only one with this issue if it would be the patches.. But again i would'nt surprise me if my system is messed up because of this big jump from 1.6.x to 1.7.22. Til now VDR has been a set and forget installation that just works, and works, and works and wo... :-) Is there btw anyone who runs vdr 1.7.22 on gentoo? What version of epgsearch, skinenigmang, text2skin, live, burn and streamdev-server are you guys running? René ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] problems with playback and plugins with vdr-1.7.22
On 07/01/2012 10:59, René wrote: On 07.01.2012 3:44 , Udo Richter wrote: The cryptic symbol decodes to cTimer::cTimer(bool, bool, cChannel*), found in timers.h, line 46. The actual code is in timers.c, line 28. This function exists in this form since 1.3.38. VDR itself seems to be fine, so your VDR seems to have a different function instead. However, the plugins rely on the original function because they somehow compiled against the original definition in the timers.h. My guess is that one of the patches is optionally modifying this, and the plugins were somehow compiled with different versions of the timers.h, or with different compiler flags that cause some #ifdef to flip. Ok, i'll check if this would would work without any patches.. I doubt that I would be the only one with this issue if it would be the patches.. But again i would'nt surprise me if my system is messed up because of this big jump from 1.6.x to 1.7.22. Til now VDR has been a set and forget installation that just works, and works, and works and wo... :-) Regards, René ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr The problem come from the livebuffer patch. It redefines cTimer::cTimer to add the length of the already buffered stream so when the instant recording start, it records the buffer too : +#ifdef USE_LIVEBUFFER + cTimer(bool Instant = false, bool Pause = false, cChannel *Channel = NULL, int Forerun = 0); +#else cTimer(bool Instant = false, bool Pause = false, cChannel *Channel = NULL); +#endif /*USE_LIVEBUFFER*/ This feature can be removed easily (it's not really useful), I attach a modified version of the livebuffer patch. Thanks Udo for pointing to the right direction. Regards, Marc. diff -Naur vdr-1.7.22/Makefile vdr-1.7.22-livebuffer/Makefile --- vdr-1.7.22/Makefile 2011-12-04 15:41:00.0 +0100 +++ vdr-1.7.22-livebuffer/Makefile 2011-12-31 11:16:23.0 +0100 @@ -62,6 +62,9 @@ LIBS += $(shell pkg-config --libs fribidi) endif +DEFINES += -DUSE_LIVEBUFFER +OBJS += livebuffer.o + LIRC_DEVICE ?= /var/run/lirc/lircd RCU_DEVICE ?= /dev/ttyS1 diff -Naur vdr-1.7.22/config.c vdr-1.7.22-livebuffer/config.c --- vdr-1.7.22/config.c 2011-12-03 16:21:30.0 +0100 +++ vdr-1.7.22-livebuffer/config.c 2011-12-31 11:16:23.0 +0100 @@ -461,6 +461,10 @@ InitialChannel = ; DeviceBondings = ; InitialVolume = -1; +#ifdef USE_LIVEBUFFER + LiveBufferSize = 30; + LiveBufferMaxFileSize = 100; +#endif /*USE_LIVEBUFFER*/ ChannelsWrap = 0; EmergencyExit = 1; } @@ -655,6 +659,10 @@ else if (!strcasecmp(Name, InitialChannel)) InitialChannel = Value; else if (!strcasecmp(Name, InitialVolume)) InitialVolume = atoi(Value); else if (!strcasecmp(Name, DeviceBondings)) DeviceBondings = Value; +#ifdef USE_LIVEBUFFER + else if (!strcasecmp(Name, LiveBufferSize))LiveBufferSize= atoi(Value); + else if (!strcasecmp(Name, LiveBufferMaxFileSize)) LiveBufferMaxFileSize = atoi(Value); +#endif /*USE_LIVEBUFFER*/ else if (!strcasecmp(Name, ChannelsWrap))ChannelsWrap = atoi(Value); else if (!strcasecmp(Name, EmergencyExit)) EmergencyExit = atoi(Value); else @@ -752,6 +760,9 @@ Store(InitialChannel, InitialChannel); Store(InitialVolume, InitialVolume); Store(DeviceBondings, DeviceBondings); +#ifdef USE_LIVEBUFFER + Store(LiveBufferSize, LiveBufferSize); +#endif /* LIVEBUFFER */ Store(ChannelsWrap, ChannelsWrap); Store(EmergencyExit, EmergencyExit); diff -Naur vdr-1.7.22/config.h vdr-1.7.22-livebuffer/config.h --- vdr-1.7.22/config.h 2011-12-03 15:19:52.0 +0100 +++ vdr-1.7.22-livebuffer/config.h 2011-12-31 11:16:23.0 +0100 @@ -307,6 +307,10 @@ int CurrentVolume; int CurrentDolby; int InitialVolume; +#ifdef USE_LIVEBUFFER + int LiveBufferSize; + int LiveBufferMaxFileSize; +#endif /*USE_LIVEBUFFER*/ int ChannelsWrap; int EmergencyExit; int __EndData__; diff -Naur vdr-1.7.22/device.c vdr-1.7.22-livebuffer/device.c --- vdr-1.7.22/device.c 2011-10-16 16:36:43.0 +0200 +++ vdr-1.7.22-livebuffer/device.c 2011-12-31 11:16:23.0 +0100 @@ -18,6 +18,10 @@ #include receiver.h #include status.h #include transfer.h +#ifdef USE_LIVEBUFFER +#include menu.h +#include interface.h +#endif /*USE_LIVEBUFFER*/ // --- cLiveSubtitle - @@ -663,6 +667,14 @@ return false; case scrNoTransfer: Skins.Message(mtError, tr(Can't start Transfer Mode!)); return false; +#ifdef USE_LIVEBUFFER +case srcStillWritingLiveBuffer: + if(Interface-Confirm(tr(Still writing timeshift data to recording. Abort?))) + cRecordControls::CancelWritingBuffer(); + else +
Re: [vdr] problems with playback and plugins with vdr-1.7.22
On 07.01.2012 17:27 , Marc wrote: On 07/01/2012 10:59, René wrote: On 07.01.2012 3:44 , Udo Richter wrote: The problem come from the livebuffer patch. It redefines cTimer::cTimer to add the length of the already buffered stream so when the instant recording start, it records the buffer too : +#ifdef USE_LIVEBUFFER + cTimer(bool Instant = false, bool Pause = false, cChannel *Channel = NULL, int Forerun = 0); +#else cTimer(bool Instant = false, bool Pause = false, cChannel *Channel = NULL); +#endif /*USE_LIVEBUFFER*/ This feature can be removed easily (it's not really useful), I attach a modified version of the livebuffer patch. Thanks Udo for pointing to the right direction. Great! Just re-compiling, and soon a restart of vdr :-) Can't wait :-) Thanks guys! ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] problems with playback and plugins with vdr-1.7.22
On 07.01.2012 2:17 , René wrote: Then i got an other problem. When watching a recording, and i fastforward of rewind the program, i get to a situation that the timecounter get's stuck to the frame i start from. The film moves, but when i hit play, i end up back to the frame from where i started to rewind/fastforwad. The only way to fix this is to jump with the yellow/green buttons. AFter this i can rewind/fastforwad normally. This again works for a while, but again if it fails to stop to the place i rewind to, i have to reset the rewind-issue with the yellow/green buttons... Is this a known bug in vdr, or is it something that i have messed up in my setup? Has anyone had time to compare their experiences with this? I just noticed that the problem is mostly when rewinding... René ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] problems with playback and plugins with vdr-1.7.22
Am 07.01.2012 16:27, schrieb Marc: The problem come from the livebuffer patch. It redefines cTimer::cTimer to add the length of the already buffered stream so when the instant recording start, it records the buffer too : +#ifdef USE_LIVEBUFFER + cTimer(bool Instant = false, bool Pause = false, cChannel *Channel = NULL, int Forerun = 0); +#else cTimer(bool Instant = false, bool Pause = false, cChannel *Channel = NULL); +#endif /*USE_LIVEBUFFER*/ Looks like thats it. However, beside the actual problem, there also seems to be a serious problem with compiler flags, or otherwise this should have worked. More precisely, VDR itself was compiled with USE_LIVEBUFFER, while at least some plugins were compiled without USE_LIVEBUFFER. This should be fixed too, as there may be more serious issues when headers get interpreted differently by VDR and plugins. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] problems with playback and plugins with vdr-1.7.22
On 07.01.2012 17:27 , Marc wrote: The problem come from the livebuffer patch. It redefines cTimer::cTimer to add the length of the already buffered stream so when the instant recording start, it records the buffer too : +#ifdef USE_LIVEBUFFER + cTimer(bool Instant = false, bool Pause = false, cChannel *Channel = NULL, int Forerun = 0); +#else cTimer(bool Instant = false, bool Pause = false, cChannel *Channel = NULL); +#endif /*USE_LIVEBUFFER*/ This feature can be removed easily (it's not really useful), I attach a modified version of the livebuffer patch. Thanks Udo for pointing to the right direction. Hi Marc, The patch compiles now fine, but when activating livebuffer, vdr crashes with the following in the logs: Jan 7 23:13:54 vdr kernel: vdr[27487]: segfault at 0 ip b73c5ab1 sp bf86f5ac error 4 in libc-2.13.so[b734a000+167000] Jan 7 23:13:54 vdr vdr: [27487] Enter timeshift at 17917 / 17918 Jan 7 23:13:54 vdr vdr: [27487] replay /video0/LiveBuffer Jan 7 23:13:54 vdr vdr: [27487] playing '/video0/LiveBuffer/1.ts' Jan 7 23:13:54 vdr vdr: [27487] resuming replay at index 17917 (0:11:56.18) Jan 7 23:13:54 vdr lircd-0.8.7[2859]: removed client Jan 7 23:13:55 vdr vdrwatchdog[28245]: restarting VDR Now it's still vdrburn that fails to start with Jan 7 23:14:00 vdr vdr: [28417] ERROR: /usr/lib/vdr/plugins/libvdr-burn.so.1.7.22: undefined symbol: _ZN8vdr_burn13chain_archiveC1ERNS_3jobE Any idea why this happens? Is there btw a final 2.0 ebuild for vdrburn (http://projects.vdr-developer.org/news/155) available somewhere? I would love to get the beta5 updated... Regards, René ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] problems with playback and plugins with vdr-1.7.22
On 07.01.2012 23:23 , René wrote: The patch compiles now fine, but when activating livebuffer, vdr crashes with the following in the logs: I realized that i forgot to turn back a couple Gentoo-useflags that i had active til now: cutterlimit ddepgentry hardlinkcutter mainmenuhooks pinplugin timerinfo wareagleicon yaepg lircsettings Putting these back seems to have fixed the crash.. Still having trouble with playback/rewind/forwad of Regards, René ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] problems with playback and plugins with vdr-1.7.22
Am 07.01.2012 01:17, schrieb René: ERROR: loading plugin libvdr-epgsearch.so.1.7.22: undefined symbol: _ZN6cTimerC1EbbP8cChannel ERROR: loading plugin libvdr-skinenigmang.so.1.7.22: undefined symbol: _ZN6cTimerC1EbbP8cChannel ERROR: loading plugin libvdr-text2skin.so.1.7.22: undefined symbol: _ZN6cTimerC1EbbP8cChannel ERROR: loading plugin libvdr-burn.so.1.7.22: undefined symbol: _ZN8vdr_burn13chain_archiveC1ERNS_3jobE ERROR: loading plugin libvdr-streamdev-server.so.1.7.22: undefined symbol: _ZN6cTimerC1EbbP8cChannel The cryptic symbol decodes to cTimer::cTimer(bool, bool, cChannel*), found in timers.h, line 46. The actual code is in timers.c, line 28. This function exists in this form since 1.3.38. VDR itself seems to be fine, so your VDR seems to have a different function instead. However, the plugins rely on the original function because they somehow compiled against the original definition in the timers.h. My guess is that one of the patches is optionally modifying this, and the plugins were somehow compiled with different versions of the timers.h, or with different compiler flags that cause some #ifdef to flip. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr