Hi all,
I finally managed to upgrade my vdr-1.6.x to vdr-1.7.22 and get the LiveBuffer patch compiled in Gentoo. There was however some problems i bumped into.
The first issue i have is when starting vdr. I get the following plugins to fail during startup:
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
I have compiled vdr, and after this i recompiled all plugins without any errors. The use-flags that are active are these: cutterlimit ddepgentry hardlinkcutter lircsettings mainmenuhooks pinplugin timerinfo wareagleicon yaepg The same use-flags worked fine with vdr 1.6.x
LiveBuffer for vdr-1.7.22 again failed with these use-flags: dvlvidprefer liemikuutio jumpplay setup ttxtsubs
Is there anything that i forgot to enable/disable in my setup?
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?
Regards,
René
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
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é
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é
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.
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!
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é
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
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/00001.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é
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é
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.
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?
Is the forwads/backward feature also part of this problem, or is it just me who has this problem..
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...
To keep my family happy, I was now forced to revert back to 1.6, cause my wife does not like the problem with sound being out of sync.. Also the rewinding/forwading the watched program/recording started to get on her nervs ;-)
René
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.
-
Marc -
René -
Udo Richter