[vdr] vdr-1.7.41: what's new way to run vdr out of it's sourcedir?
Hi, vdr doesn't copy plugins to PLUGINS/lib. Is there a way to get the old behaviour back? First look I couldn't find nothing in vdr's HISTORY file. Regards Halim ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.7.41: what's new way to run vdr out of it's sourcedir?
Hi, Am 17.03.2013 09:20, schrieb Halim Sahin: Hi, vdr doesn't copy plugins to PLUGINS/lib. Is there a way to get the old behaviour back? First look I couldn't find nothing in vdr's HISTORY file. I think make LCLBLD=1 should do it. Lars. Regards Halim ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.7.41: what's new way to run vdr out of it's sourcedir?
On 17.03.2013 09:20, Halim Sahin wrote: Hi, vdr doesn't copy plugins to PLUGINS/lib. Is there a way to get the old behaviour back? First look I couldn't find nothing in vdr's HISTORY file. From the INSTALL file: Configuration files: There are several configuration files that hold information about channels, remote control keys, timers etc. By default these files are spread around the system according to the FHS (File system Hierarchy Standard). If you prefer to have VDR built to run locally under the VDR source tree, you can copy the file Make.config.template to Make.config and set the parameter LCLBLD=1. If you also want to have all data files under one single directory, set ONEDIR=1 in Make.config. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] vdr-menuorg 0.5.0
Hi, Am 16.03.2013 18:41, schrieb Tobi: I wanted to completely drop this plugin, but it seems, some folks really like it. Yes! :) Maybe Klaus can add this feature in 2.1+. I hope so, too. I've basically only updated the Makefile and the patch for VDR 1.7.40. While upgrading our yavdr-package I found a patch in our repository: --- a/src/MenuOrgPlugin.cpp +++ b/src/MenuOrgPlugin.cpp @@ -45,6 +45,7 @@ // VDR OBJECTS TO EXIST OR PRODUCE ANY OUTPUT! _subMenuProvider = NULL; +_menuConfigurationRepository = NULL; } MenuOrgPlugin::~MenuOrgPlugin() Seems to be important, but I don't know the reason anymore, why I added it... Can you have a look on it? Thanks, Lars. As always: Any help is welcome! Development site: http://projects.vdr-developer.org/projects/plg-menuorg Downloads: http://projects.vdr-developer.org/projects/plg-menuorg/files Git-Web: http://projects.vdr-developer.org/git/vdr-plugin-menuorg.git/ Anonymous Git-access : git://projects.vdr-developer.org/vdr-plugin-menuorg.git This is intended to be a community maintained project! Any help and patches are always welcome! Please report bugs, ideas or feature requests to the project site (no registration required for this!). If you want to contribute patches, new features or whatever, post an issue or patch to the projects issue tracker or request to join the project. I would happily add everyone as a project member, who would like to contribute to the project! Tobias ___ 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] locale problem with 1.7.41
Hi jouni, Post you locale without grep. Did you change any VDR_CHARSET_OVERRIDE value in startup script ? Cheers, Bernard. 2013/3/17 Jouni Karvo jouni.ka...@iki.fi hi, I updated from 1.7.32 to 1.7.41. It seems fine, but for some reason vdr does not find locales any more: locale -a | wc 537 5375097 locale -a | grep fi fi_FI fi_FI@euro fi_FI.iso88591 fi_FI.iso885915@euro fi_FI.utf8 fil_PH fil_PH.utf8 finnish and the syslog: Mar 17 09:50:31 vdr vdr: [5112] found 0 locales in /usr/local/share/locale Mar 17 09:50:31 vdr vdr: [5112] no locale for language code 'deu,ger' Mar 17 09:50:31 vdr vdr: [5112] no locale for language code 'slv,slo' Mar 17 09:50:31 vdr vdr: [5112] no locale for language code 'ita' Mar 17 09:50:31 vdr vdr: [5112] no locale for language code 'dut,nla,nld' Mar 17 09:50:31 vdr vdr: [5112] no locale for language code 'prt' Mar 17 09:50:31 vdr vdr: [5112] no locale for language code 'fra,fre' Mar 17 09:50:31 vdr vdr: [5112] no locale for language code 'nor' Mar 17 09:50:31 vdr vdr: [5112] no locale for language code 'fin,suo' Mar 17 09:50:31 vdr vdr: [5112] no locale for language code 'pol' Mar 17 09:50:31 vdr vdr: [5112] no locale for language code 'esl,spa' Mar 17 09:50:31 vdr vdr: [5112] no locale for language code 'ell,gre' Mar 17 09:50:31 vdr vdr: [5112] no locale for language code 'sve,swe' Mar 17 09:50:31 vdr vdr: [5112] no locale for language code 'rom,rum' Mar 17 09:50:31 vdr vdr: [5112] no locale for language code 'hun' Mar 17 09:50:31 vdr vdr: [5112] no locale for language code 'cat,cln' Mar 17 09:50:31 vdr vdr: [5112] no locale for language code 'rus' Mar 17 09:50:31 vdr vdr: [5112] no locale for language code 'srb,srp,scr,scc' Mar 17 09:50:31 vdr vdr: [5112] no locale for language code 'hrv' Mar 17 09:50:31 vdr vdr: [5112] no locale for language code 'est' Mar 17 09:50:31 vdr vdr: [5112] no locale for language code 'dan' Mar 17 09:50:31 vdr vdr: [5112] no locale for language code 'cze,ces' Mar 17 09:50:31 vdr vdr: [5112] no locale for language code 'tur' Mar 17 09:50:31 vdr vdr: [5112] no locale for language code 'ukr' Mar 17 09:50:31 vdr vdr: [5112] no locale for language code 'ara' Mar 17 09:50:31 vdr vdr: [5112] unknown locale: 'fi_FI' I am running debian wheezy I also tried setting a different locale directory (that has more locales in it), but it does not change anything: Mar 17 09:58:09 vdr vdr: [4795] found 0 locales in /usr/share/locale Mar 17 09:58:09 vdr vdr: [4795] no locale for language code 'deu,ger' Mar 17 09:58:09 vdr vdr: [4795] no locale for language code 'slv,slo' Mar 17 09:58:09 vdr vdr: [4795] no locale for language code 'ita' Mar 17 09:58:09 vdr vdr: [4795] no locale for language code 'dut,nla,nld' Mar 17 09:58:09 vdr vdr: [4795] no locale for language code 'prt' Mar 17 09:58:09 vdr vdr: [4795] no locale for language code 'fra,fre' Mar 17 09:58:09 vdr vdr: [4795] no locale for language code 'nor' Mar 17 09:58:09 vdr vdr: [4795] no locale for language code 'fin,suo' Mar 17 09:58:09 vdr vdr: [4795] no locale for language code 'pol' Mar 17 09:58:09 vdr vdr: [4795] no locale for language code 'esl,spa' Mar 17 09:58:09 vdr vdr: [4795] no locale for language code 'ell,gre' Mar 17 09:58:09 vdr vdr: [4795] no locale for language code 'sve,swe' Mar 17 09:58:09 vdr vdr: [4795] no locale for language code 'rom,rum' Mar 17 09:58:09 vdr vdr: [4795] no locale for language code 'hun' Mar 17 09:58:09 vdr vdr: [4795] no locale for language code 'cat,cln' Mar 17 09:58:09 vdr vdr: [4795] no locale for language code 'rus' Mar 17 09:58:09 vdr vdr: [4795] no locale for language code 'srb,srp,scr,scc' Mar 17 09:58:09 vdr vdr: [4795] no locale for language code 'hrv' Mar 17 09:58:09 vdr vdr: [4795] no locale for language code 'est' Mar 17 09:58:09 vdr vdr: [4795] no locale for language code 'dan' Mar 17 09:58:09 vdr vdr: [4795] no locale for language code 'cze,ces' Mar 17 09:58:09 vdr vdr: [4795] no locale for language code 'tur' Mar 17 09:58:09 vdr vdr: [4795] no locale for language code 'ukr' Mar 17 09:58:09 vdr vdr: [4795] no locale for language code 'ara' Mar 17 09:58:09 vdr vdr: [4795] unknown locale: 'fi_FI' yours, Jouni __**_ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-**bin/mailman/listinfo/vdrhttp://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] locale problem with 1.7.41
Hi, I see locale problems as well. I've used LCLBLD and no locales were installed in ./locale after make run. I typed make i18n which helped. Regards Halim ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] vdr-menuorg 0.5.0
Hi, Found an error in the Makefile. The LIBS are missing, patch attached. Regards, Lars. Am 16.03.2013 18:41, schrieb Tobi: I wanted to completely drop this plugin, but it seems, some folks really like it. Maybe Klaus can add this feature in 2.1+. I've basically only updated the Makefile and the patch for VDR 1.7.40. As always: Any help is welcome! Development site: http://projects.vdr-developer.org/projects/plg-menuorg Downloads: http://projects.vdr-developer.org/projects/plg-menuorg/files Git-Web: http://projects.vdr-developer.org/git/vdr-plugin-menuorg.git/ Anonymous Git-access : git://projects.vdr-developer.org/vdr-plugin-menuorg.git This is intended to be a community maintained project! Any help and patches are always welcome! Please report bugs, ideas or feature requests to the project site (no registration required for this!). If you want to contribute patches, new features or whatever, post an issue or patch to the projects issue tracker or request to join the project. I would happily add everyone as a project member, who would like to contribute to the project! Tobias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr --- a/Makefile +++ b/Makefile @@ -45,6 +45,9 @@ INCLUDES += `pkg-config libxml++-2.6 --cflags` INCLUDES += `pkg-config glibmm-2.4 --cflags` +LIBS += `pkg-config libxml++-2.6 --libs` +LIBS += `pkg-config glibmm-2.4 --libs` + DEFINES += -DPLUGIN_NAME_I18N='$(PLUGIN)' ### The source files (add further files here): @@ -102,7 +105,7 @@ ### Targets: $(SOFILE): $(OBJS) - $(CXX) $(CPPFLAGS) $(CXXFLAGS) $(LDFLAGS) -shared $(OBJS) -o $@ + $(CXX) $(CPPFLAGS) $(CXXFLAGS) $(LDFLAGS) -shared $(OBJS) $(LIBS) -o $@ install-lib: $(SOFILE) install -D $^ $(DESTDIR)$(LIBDIR)/$^.$(APIVERSION) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] locale problem with 1.7.41
On 17.03.2013 10:57, Halim Sahin wrote: Hi, I see locale problems as well. I've used LCLBLD and no locales were installed in ./locale after make run. I typed make i18n which helped. I just verified that a plain 'make' does generate the ./locale directory with all locales when using LCLBLD. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Makefile variable names LCLBLD and PLGCFG
Hello, Should probably have spoken earlier, but is there any particular reason for the ugly and hard to read Makefile variable names LCLBLD and PLGCFG? I suppose they're short for LOCALBUILD and PLUGINCONFIG, but why do they have to be short for anything, it's not like we're running out of space for their names anywhere, is it? Besides, I don't think LCLBLD describes what its effects are very well, INPLACE would sounds better to me. The ship may already have sailed for plgcfg in vdr.pc as it's being used by many plugin Makefiles already, but I believe the attached patches should be safe for 2.0.0. From 67899a6591b4eb80198a457ae6cd1a75f11fbd7b Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ville=20Skytt=C3=A4?= ville.sky...@iki.fi Date: Sun, 17 Mar 2013 13:38:45 +0200 Subject: [PATCH 1/2] Rename LCLBLD to INPLACE. --- INSTALL | 2 +- Make.config.template | 4 ++-- Makefile | 2 +- UPDATE-2.0.0 | 2 +- 4 files changed, 5 insertions(+), 5 deletions(-) diff --git a/INSTALL b/INSTALL index dd0c999..8ad72ed 100644 --- a/INSTALL +++ b/INSTALL @@ -385,7 +385,7 @@ channels, remote control keys, timers etc. By default these files are spread around the system according to the FHS (File system Hierarchy Standard). If you prefer to have VDR built to run locally under the VDR source tree, you can copy the file Make.config.template to Make.config and set the parameter -LCLBLD=1. If you also want to have all data files under one single directory, +INPLACE=1. If you also want to have all data files under one single directory, set ONEDIR=1 in Make.config. For starters just copy all *.conf files from the VDR directory into your diff --git a/Make.config.template b/Make.config.template index 2bc0a8f..40cfefe 100644 --- a/Make.config.template +++ b/Make.config.template @@ -42,8 +42,8 @@ endif # Overrides for preset/legacy configurations: -# Use 'make LCLBLD=1' to build locale and plugin files under the source directory: -ifdef LCLBLD +# Use 'make INPLACE=1' to build locale and plugin files under the source directory: +ifdef INPLACE LOCDIR = $(CWD)/locale PLUGINDIR= $(CWD)/PLUGINS ifndef PLUGIN # don't overwrite for plugins with old makefiles diff --git a/Makefile b/Makefile index d24d08f..91506e2 100644 --- a/Makefile +++ b/Makefile @@ -219,7 +219,7 @@ plugins: include-dir vdr.pc # New Makefile\ INCLUDES=-I$(CWD)/include\ $(MAKE) --no-print-directory -C $(PLUGINDIR)/src/$$i VDRDIR=$(CWD) || failed=$$failed $$i;\ - if [ -n $(LCLBLD) ] ; then\ + if [ -n $(INPLACE) ] ; then\ (cd $(PLUGINDIR)/src/$$i; for l in `find -name 'libvdr-*.so' -o -name 'lib$$i-*.so'`; do install $$l $(LIBDIR)/`basename $$l`.$(APIVERSION); done);\ if [ -d $(PLUGINDIR)/src/$$i/po ]; then\ for l in `ls $(PLUGINDIR)/src/$$i/po/*.mo`; do\ diff --git a/UPDATE-2.0.0 b/UPDATE-2.0.0 index c24fcb0..6f9144f 100644 --- a/UPDATE-2.0.0 +++ b/UPDATE-2.0.0 @@ -461,7 +461,7 @@ Misc: - By default VDR is now built according to the FHS (File system Hierarchy Standard), and a plain make in the VDR source directory just builds everything, but doesn't copy it to ./PLUGINS/lib and ./locale any more. You can use a Make.config file - (copied from Make.config.template) and set the parameter LCLBLD=1 to have everything + (copied from Make.config.template) and set the parameter INPLACE=1 to have everything built and installed under the VDR source tree (as was the default in previous versions). If you already have your own Make.config file, you may want to copy the new Make.config.template and adapt it to your needs. If you don't want VDR's data -- 1.7.11.7 From 79a900a9995c1d401543e2804027cc019b5f7375 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ville=20Skytt=C3=A4?= ville.sky...@iki.fi Date: Sun, 17 Mar 2013 13:43:40 +0200 Subject: [PATCH 2/2] Rename PLGCFG to PLUGINCONFIG. --- Make.config.template | 2 +- Makefile | 2 +- PLUGINS/src/dvbhddevice/Makefile | 4 ++-- PLUGINS/src/dvbsddevice/Makefile | 4 ++-- PLUGINS/src/epgtableid0/Makefile | 4 ++-- PLUGINS/src/hello/Makefile | 4 ++-- PLUGINS/src/osddemo/Makefile | 4 ++-- PLUGINS/src/pictures/Makefile| 4 ++-- PLUGINS/src/rcu/Makefile | 4 ++-- PLUGINS/src/servicedemo/Makefile | 4 ++-- PLUGINS/src/skincurses/Makefile | 4 ++-- PLUGINS/src/status/Makefile | 4 ++-- PLUGINS/src/svdrpdemo/Makefile | 4 ++-- newplugin| 4 ++-- 14 files changed, 26 insertions(+), 26 deletions(-) diff --git a/Make.config.template b/Make.config.template index 40cfefe..8a04fd7 100644 --- a/Make.config.template +++ b/Make.config.template @@ -62,7 +62,7 @@ endif # Use this if you want to have a central place where you configure compile time # parameters for plugins: -#PLGCFG = $(CONFDIR)/plugins.mk +#PLUGINCONFIG = $(CONFDIR)/plugins.mk ### The remote control: diff --git a/Makefile b/Makefile index 91506e2..a881b03 100644 ---
Re: [vdr] Makefile variable names LCLBLD and PLGCFG
On 17.03.2013 12:46, Ville Skyttä wrote: Hello, Should probably have spoken earlier, but is there any particular reason for the ugly and hard to read Makefile variable names LCLBLD and PLGCFG? I suppose they're short for LOCALBUILD and PLUGINCONFIG, but why do they have to be short for anything, it's not like we're running out of space for their names anywhere, is it? Besides, I don't think LCLBLD describes what its effects are very well, INPLACE would sounds better to me. The ship may already have sailed for plgcfg in vdr.pc as it's being used by many plugin Makefiles already, but I believe the attached patches should be safe for 2.0.0. I'm afraid it's too late for that. Sorry for the time you wasted - you should have asked first. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.7.41: what's new way to run vdr out of it's sourcedir?
Am 17.03.2013 09:51, schrieb Lars Hanisch: Am 17.03.2013 09:20, schrieb Halim Sahin: vdr doesn't copy plugins to PLUGINS/lib. Is there a way to get the old behaviour back? I think make LCLBLD=1 should do it. Mostly, but YMMV. Some plugins may not support it. From my builds yesterday, the most recent xineliboutput Makefile seems stuck between the versions, not copying 'the old way' to ../../../PLUGINS/lib any more, and not adhering 'the new way' LCLBLD request to do it. Also, in case ./PLUGINS/lib is not the final destination, you'll loose the ability to set default search paths for all the libs, so you have to specify them on command line. The alternative, doing an make install DESTDIR=/tmp/foo/ and picking files from there may fail because of too many broken plugin Makefiles. (at least the last time I've tried) Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] locale problem with 1.7.41
17.03.2013 12:37, Klaus Schmidinger kirjoitti: On 17.03.2013 10:57, Halim Sahin wrote: Hi, I see locale problems as well. I've used LCLBLD and no locales were installed in ./locale after make run. I typed make i18n which helped. I just verified that a plain 'make' does generate the ./locale directory with all locales when using LCLBLD. hi, thanks for the answer - I got it working. It was my confusion in building the program with the new LCLBLD and ONEDIR options. Unfortunately I have no idea on how to improve the instructions on the INSTALL file to avoid such confusion for others. yours, Jouni ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Makefile variable names LCLBLD and PLGCFG
On 2013-03-17 14:00, Klaus Schmidinger wrote: I'm afraid it's too late for that. HWLLBDCLLBTHVTRWY ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Makefile variable names LCLBLD and PLGCFG
On 03/17/13 13:00, Klaus Schmidinger wrote: On 17.03.2013 12:46, Ville Skyttä wrote: Hello, Should probably have spoken earlier, but is there any particular reason for the ugly and hard to read Makefile variable names LCLBLD and PLGCFG? I suppose they're short for LOCALBUILD and PLUGINCONFIG, but why do they have to be short for anything, it's not like we're running out of space for their names anywhere, is it? Besides, I don't think LCLBLD describes what its effects are very well, INPLACE would sounds better to me. The ship may already have sailed for plgcfg in vdr.pc as it's being used by many plugin Makefiles already, but I believe the attached patches should be safe for 2.0.0. I'm afraid it's too late for that. I do not understand why it should be too late. 2.0 is not out yet. But if they really cannot have readable names, at least I would not provide a default, but let the makefile issue a message that they must be set (as I suggested in the other thread). Carsten. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Makefile variable names LCLBLD and PLGCFG
On 17.03.2013 18:00, Carsten Koch wrote: On 03/17/13 13:00, Klaus Schmidinger wrote: On 17.03.2013 12:46, Ville Skyttä wrote: Hello, Should probably have spoken earlier, but is there any particular reason for the ugly and hard to read Makefile variable names LCLBLD and PLGCFG? I suppose they're short for LOCALBUILD and PLUGINCONFIG, but why do they have to be short for anything, it's not like we're running out of space for their names anywhere, is it? Besides, I don't think LCLBLD describes what its effects are very well, INPLACE would sounds better to me. The ship may already have sailed for plgcfg in vdr.pc as it's being used by many plugin Makefiles already, but I believe the attached patches should be safe for 2.0.0. I'm afraid it's too late for that. I do not understand why it should be too late. 2.0 is not out yet. But we're in the final testing phase. Besides, Ville's patch also touched the Makefiles of plugins - and plugin authors and distribution managers react very intense when they have to modify their files ;-). But if they really cannot have readable names, at least I would not provide a default, but let the makefile issue a message that they must be set (as I suggested in the other thread). Sorry, no more changes for version 2.0. Just bugfixes, if anything is really broken. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] vdr-menuorg 0.5.0
On 17.03.2013 11:32, Lars Hanisch wrote: Found an error in the Makefile. The LIBS are missing, patch attached. Thx! Looks like I was in a hurry :-) Fixed in 0.5.1! Tobias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR 1.7 FreeBSD segfault when cutting recordings
In article 20130316082610.gj23...@t60.brauer.lan you write: On Fri, Mar 15, 2013 at 10:54:04AM +0100, Gerhard Brauer wrote: I never have any problem during other actions with the remote VDR (recording, viewing, place cutting marks,...) _exept_ when i start the cutting procedere itself with the keyboard shortcut 2. Most times ( 95%) the remote vdr segfaults immidiatly. The file structure is still created (%foobar ff.). In the few times when it not segfaults then the cutting is done well without problems. Hello again, I've learned that i could also start the cutting process on the vdr server itself, without a frontend. With this i also (and 100% reproducable) got the segfault of the vdr. I start without a running vdr: s01# vdr -u vdr --edit=/video/Die_Marx_Brothers_im_Kaufhaus/2012-10-29.01.48.50.99.rec/ and also with a still running vdr and call the --edit with another instance: vdr -u vdr -i 1 --edit=/video/Die_Marx_Brothers_im_Kaufhaus/2012-10-29.01.48.50.99.rec/ From both tries i make backtraces with gdb, both differs only in thread numbering etc. So i attach the one with -i 1 instance, along with the vdr logfile output. Maybe one of you see a clearer picture why this segfaults happen here. I attach logfile sequence and backtrace output together. Regards and TIA Gerhard --M/SuVGWktc5uNpra Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=log+backtrace.txt Content-Transfer-Encoding: quoted-printable [Here i restarted the vdr on the server] Mar 16 08:30:09 s01 vdr: [50361344] VDR version 1.7.29 started Mar 16 08:30:09 s01 vdr: [50361344] switched to user 'vdr' Mar 16 08:30:09 s01 vdr: [50361344] running as daemon (tid=3D50361344) Mar 16 08:30:09 s01 vdr: [50361344] codeset is 'UTF-8' - known Mar 16 08:30:09 s01 vdr: [50361344] found 28 locales in /usr/local/share/lo= cale Mar 16 08:30:09 s01 vdr: [50361344] loading plugin: /usr/local/lib/vdr/libv= dr-xineliboutput.so.1.7.29 Mar 16 08:30:09 s01 vdr: [50361344] loading /usr/local/etc/vdr/setup.conf Mar 16 08:30:09 s01 vdr: [50361344] loading /usr/local/etc/vdr/sources.conf Mar 16 08:30:09 s01 vdr: [50361344] loading /usr/local/etc/vdr/diseqc.conf Mar 16 08:30:09 s01 vdr: [50361344] loading /usr/local/etc/vdr/scr.conf Mar 16 08:30:09 s01 vdr: [50361344] loading /usr/local/etc/vdr/channels.conf Mar 16 08:30:09 s01 vdr: [50361344] loading /usr/local/etc/vdr/timers.conf Mar 16 08:30:09 s01 vdr: [50361344] loading /usr/local/etc/vdr/svdrphosts.c= onf Mar 16 08:30:09 s01 vdr: [50361344] loading /usr/local/etc/vdr/remote.conf Mar 16 08:30:09 s01 vdr: [50361344] loading /usr/local/etc/vdr/keymacros.co= nf Mar 16 08:30:09 s01 vdr: [50363392] video directory scanner thread started = (pid=3D15494, tid=3D50363392) Mar 16 08:30:09 s01 vdr: [50361344] registered source parameters for 'A - A= TSC' Mar 16 08:30:09 s01 vdr: [50365440] epg data reader thread started (pid=3D1= 5494, tid=3D50365440) Mar 16 08:30:09 s01 vdr: [50364416] video directory scanner thread started = (pid=3D15494, tid=3D50364416) Mar 16 08:30:09 s01 vdr: [50361344] registered source parameters for 'C - D= VB-C' Mar 16 08:30:09 s01 vdr: [50361344] registered source parameters for 'S - D= VB-S' Mar 16 08:30:09 s01 vdr: [50361344] registered source parameters for 'T - D= VB-T' Mar 16 08:30:09 s01 vdr: [50361344] probing /dev/dvb/adapter0/frontend0 Mar 16 08:30:09 s01 vdr: [50365440] reading EPG data from /video/epg.data Mar 16 08:30:09 s01 vdr: [50361344] creating cDvbDevice Mar 16 08:30:09 s01 vdr: [50361344] new device number 1 Mar 16 08:30:09 s01 vdr: [50361344] frontend 0/0 provides DVB-T with QPSK,Q= AM16,QAM64 (DiBcom 7000PC) Mar 16 08:30:09 s01 vdr: [50361344] found 1 DVB device Mar 16 08:30:09 s01 vdr: [50366464] tuner on frontend 0/0 thread started (p= id=3D15494, tid=3D50366464) Mar 16 08:30:09 s01 vdr: [50361344] initializing plugin: xineliboutput (1.0= =2E90-cvs): X11/xine-lib Ausgabe-Plugin Mar 16 08:30:09 s01 vdr: [50366464] cTimeMs: using monotonic clock (resolut= ion is 70 ns) Mar 16 08:30:09 s01 vdr: [50367488] section handler thread started (pid=3D1= 5494, tid=3D50367488) Mar 16 08:30:09 s01 vdr: [50361344] new device number 64 Mar 16 08:30:09 s01 vdr: [50361344] setting primary device to 2 Mar 16 08:30:09 s01 vdr: [50364416] video directory scanner thread ended (p= id=3D15494, tid=3D50364416) Mar 16 08:30:10 s01 vdr: [50361344] assuming manual start of VDR Mar 16 08:30:10 s01 vdr: [50361344] SVDRP listening on port 6419 Mar 16 08:30:10 s01 vdr: [50361344] setting current skin to lcars Mar 16 08:30:10 s01 vdr: [50361344] loading /usr/local/etc/vdr/themes/lcars= -default.theme Mar 16 08:30:10 s01 vdr: [50361344] starting plugin: xineliboutput Mar 16 08:30:10 s01 vdr: [50365440] epg data reader thread ended (pid=3D154= 94, tid=3D50365440) Mar 16 08:30:10 s01 vdr: [50370560] Remote decoder/display server (cXinelib= Server) thread started (pid=3D15494, tid=3D50370560) Mar 16 08:30:10 s01 vdr: [discovery] discovery_init:
Re: [vdr] VDR 1.7 FreeBSD segfault when cutting recordings
On 17.03.2013 21:52, Juergen Lock wrote:
...
Ok I looked at cutter.c again and now I think I found the cause:
Linux must default to bigger thread stacks than FreeBSD, FreeBSD's
default seems to be 2 MB on amd64 and MAXFRAMESIZE is almost 1 MB...
Try the patch below, you can put it in files/patch-z-cutter.c
in the port dir. (the thread.c part is FreeBSD port specific, it
caused a different crash with --edit.)
HTH, :)
Juergen
--- cutter.c.orig
+++ cutter.c
@@ -83,7 +83,18 @@ void cCuttingThread::Action(void)
int LastIFrame = 0;
toMarks.Add(0);
toMarks.Save();
+#ifdef __FreeBSD__
+ // XXX save thread stack space
+ uchar *buffer = MALLOC(uchar, MAXFRAMESIZE);
+ uchar *buffer2 = MALLOC(uchar, MAXFRAMESIZE);
+ if (buffer == NULL || buffer2 == NULL) {
+free(buffer);
+error = malloc;
+return;
+}
+#else
uchar buffer[MAXFRAMESIZE], buffer2[MAXFRAMESIZE];
+#endif
int Length2;
bool CheckForSeamlessStream = false;
bool LastMark = false;
@@ -216,6 +227,10 @@ void cCuttingThread::Action(void)
}
}
Recordings.TouchUpdate();
+#ifdef __FreeBSD__
+ free(buffer);
+ free(buffer2);
+#endif
}
else
esyslog(no editing marks found!);
I assume this patch is against an older version of VDR, because in the
current developer version this looks different. However, there are still
places where two buffers with a size of MAXFRAMESIZE are allocated on the
stack. So I guess I will change these to be allocated on the heap for
version 2.0.
Klaus
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR 1.7 FreeBSD segfault when cutting recordings
In article 514637fa.5080...@tvdr.de you write:
On 17.03.2013 21:52, Juergen Lock wrote:
...
Ok I looked at cutter.c again and now I think I found the cause:
Linux must default to bigger thread stacks than FreeBSD, FreeBSD's
default seems to be 2 MB on amd64 and MAXFRAMESIZE is almost 1 MB...
Try the patch below, you can put it in files/patch-z-cutter.c
in the port dir. (the thread.c part is FreeBSD port specific, it
caused a different crash with --edit.)
HTH, :)
Juergen
--- cutter.c.orig
+++ cutter.c
@@ -83,7 +83,18 @@ void cCuttingThread::Action(void)
int LastIFrame = 0;
toMarks.Add(0);
toMarks.Save();
+#ifdef __FreeBSD__
+ // XXX save thread stack space
+ uchar *buffer = MALLOC(uchar, MAXFRAMESIZE);
+ uchar *buffer2 = MALLOC(uchar, MAXFRAMESIZE);
+ if (buffer == NULL || buffer2 == NULL) {
+free(buffer);
+error = malloc;
+return;
+}
+#else
uchar buffer[MAXFRAMESIZE], buffer2[MAXFRAMESIZE];
+#endif
int Length2;
bool CheckForSeamlessStream = false;
bool LastMark = false;
@@ -216,6 +227,10 @@ void cCuttingThread::Action(void)
}
}
Recordings.TouchUpdate();
+#ifdef __FreeBSD__
+ free(buffer);
+ free(buffer2);
+#endif
}
else
esyslog(no editing marks found!);
I assume this patch is against an older version of VDR, because in the
current developer version this looks different. However, there are still
places where two buffers with a size of MAXFRAMESIZE are allocated on the
stack. So I guess I will change these to be allocated on the heap for
version 2.0.
Ah yes, I'm still at 1.7.29, sorry I should have said...
Thanx! :)
Juergen
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
