Re: [vdr] [PATCH] Gather necessary options for build in Make.global and include it.
Am 28.01.2010 22:52, schrieb Ville Skyttä: On Thursday 28 January 2010, Paul Menzel wrote: Therefore include strictly necessary options in `Make.global` and include this in all the Makefiles before `Make.config`. If these options are strictly necessary, shouldn't the leading - be dropped from all -include $(VDRDIR)/Make.global lines? In this case, yes, but many cross-version plugins will need to be more flexible here, either by doing a messy VDR version check, or by simply just using -inlcude anyway. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR plugin options
Am 25.01.2010 00:19, schrieb Adrian C.:
Now I want a variable or array at the top of the script so I could
easily add, remove and comment plugins... rewriting the above example:
vdrplug=(-Pfemon
-Psoftdevice -vo xv:full -ao alsa:mixer:pcm=default
)
$vdrbin -L $vdrlib ${vdrpl...@]}
The correct way to place every array element as one parameter, without
doing any additional whitespace separation, is this:
$vdrbin -L $vdrlib ${vdrpl...@]}
In contrast, ${vdrplug[*]} merges all to one parameter, ${vdrpl...@]}
does another whitespace separation run.
runvdr extreme also uses a bash array for building the command line.
Cheers,
Udo
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [PATCH] Gather necessary options for build in Make.global and include it.
Am Samstag, den 30.01.2010, 11:57 +0100 schrieb Udo Richter: Am 28.01.2010 22:52, schrieb Ville Skyttä: On Thursday 28 January 2010, Paul Menzel wrote: Therefore include strictly necessary options in `Make.global` and include this in all the Makefiles before `Make.config`. If these options are strictly necessary, shouldn't the leading - be dropped from all -include $(VDRDIR)/Make.global lines? In this case, yes, but many cross-version plugins will need to be more flexible here, either by doing a messy VDR version check, or by simply just using -inlcude anyway. Sorry, I do not know if I understood you correctly. Do you mean that some other plugins (which are not shipped with VDR, i. e. the patch does not need to be changed in that regard) need to use `-include $(VDRDIR)/Make.global` instead of `include $(VDRDIR)/Make.global`? Do the authors of those plugins generally know about that kind of stuff or does this have to be documented somewhere? Thanks, Paul signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] PCR pid
On 24.01.2010 18:37, Petri Hintukainen wrote: Klaus Schmidinger wrote: I was under the impression that the WMP was one of those players that have problems if there is no PCR, but apparently it plays just fine... When I used vlc with streamdev (few years ago), vlc refused to play http streams without PCR. But I don't know if recent versions still require PCR. I have now tested with VLC and apparently it does refuse to play a stream without PCR - although according to http://www.videolan.org/developers/vls/doc/developer/vls-devel/c327.htm it obviously could (see section Using or not PCRs). In version 1.7.12 VDR will record the PCR data in case it uses a different PID than the video. With that, VLC can replay such recordings. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [PATCH] Gather necessary options for build in Make.global and include it.
Am 30.01.2010 12:12, schrieb Paul Menzel: Sorry, I do not know if I understood you correctly. Do you mean that some other plugins (which are not shipped with VDR, i. e. the patch does not need to be changed in that regard) need to use `-include $(VDRDIR)/Make.global` instead of `include $(VDRDIR)/Make.global`? Do the authors of those plugins generally know about that kind of stuff or does this have to be documented somewhere? Plugins shipped with VDR usually only need to work with this version of VDR, they (and the newplugin script) don't provide backwards compatibility. Plugin authors that want to support a wider range of VDR versions with one release will usually need to adapt their behavior to the VDR version they compile with. In this case, they will have to add -fPIC and the FILE_OFFSET stuff for older versions of VDR, and only include Make.global for the upcoming VDR versions. However, this is not a concern for VDR or for this patch. Its ok for VDR to look ahead, and not to carry endless compatibility hacks with it. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR plugin options
On Sat, Jan 30, 2010 at 3:07 AM, Udo Richter udo_rich...@gmx.de wrote:
The correct way to place every array element as one parameter, without
doing any additional whitespace separation, is this:
$vdrbin -L $vdrlib ${vdrpl...@]}
In contrast, ${vdrplug[*]} merges all to one parameter, ${vdrpl...@]}
does another whitespace separation run.
runvdr extreme also uses a bash array for building the command line.
What makes that correct? Just sounds like a different (and more
complicated, ..I guess) way to accomplish the same end result, but no
more correct then using double/single quotes.
I'm no bash expert but STRING=$STRING -P'asdf arg' works equally as
well as ARRAY=( ${arr...@]} new item ) in my experience. What am
I missing?
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [PATCH] Gather necessary options for build in Make.global and include it.
On Sat, Jan 30, 2010 at 4:21 AM, Udo Richter udo_rich...@gmx.de wrote: However, this is not a concern for VDR or for this patch. Its ok for VDR to look ahead, and not to carry endless compatibility hacks with it. I couldn't agree more. I cant stand when something is bloated down with that, just because some users out there refuse to update their system. I understand 'if its not broke, dont fix it', but that doesnt mean be an anchor weighing everything down. If you choose to stay in the dark ages, then suffer the consequences. ;) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR plugin options
Am 30.01.2010 19:23, schrieb VDR User:
On Sat, Jan 30, 2010 at 3:07 AM, Udo Richter udo_rich...@gmx.de wrote:
The correct way to place every array element as one parameter, without
doing any additional whitespace separation, is this:
$vdrbin -L $vdrlib ${vdrpl...@]}
In contrast, ${vdrplug[*]} merges all to one parameter, ${vdrpl...@]}
does another whitespace separation run.
What makes that correct? Just sounds like a different (and more
complicated, ..I guess) way to accomplish the same end result, but no
more correct then using double/single quotes.
Correct in the sense of using arrays to build up a command line, not in
a sense of The One And Only Solution (tm).
I'm no bash expert but STRING=$STRING -P'asdf arg' works equally as
well as ARRAY=( ${arr...@]} new item ) in my experience. What am
I missing?
Well, not much, except that I would do it this way:
PLUGINS[${#PLUGINS[*]}]=-Psoftdevice -vo xv:full -ao
alsa:mixer:pcm=default
For a more complex (and a bit constructed) case:
PLUGINS=$PLUGINS -P\hello --aaa=\\\A B C
or
PLUGINS=$PLUGINS -P'hello --aaa=\A B C\'
or
PLUGINS[${#PLUGINS[*]}]=-Phello --aaa=\A B C\
or
PLUGINS[${#PLUGINS[*]}]=-Phello --aaa='A B C'
Arrays have the advantage that they spare one level of quoting, don't
need eval, and are a bit more 'ordered', but on the other hand are
bash-only, and cannot be exported to sub-shells.
(runvdr extreme has a quoting function, so you do it with even less
quoting like this: AddPlugin hello --aaa=A B C)
Cheers,
Udo
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.7.11 (+ vdr-xine) segfaults
hi, Reinhard Nissl kirjoitti: Please report the logged error message. Actually, your patch immediately segfaulted. But I can see some problem: The include files from the distro tell me: k...@vdr:/usr/include$ grep __NR_gettid */* asm/unistd_32.h:#define __NR_gettid224 asm/unistd_64.h:#define __NR_gettid186 asm/unistd_64.h:__SYSCALL(__NR_gettid, sys_gettid) bits/syscall.h:#define SYS_gettid __NR_gettid but the kernel includes tell: k...@vdr:/usr/src/linux/include$ grep __NR_gettid */* asm-generic/unistd.h:#define __NR_gettid 178 asm-generic/unistd.h:__SYSCALL(__NR_gettid, sys_gettid) So it seems the syscall numbers have changed at some point. I am afraid if the libc is now broken due to this. This has not happened to me before, so I don't actually know what would be the good thing to do. But forcing the syscall number to 178 does not actually fix the thread numbers in the log file. yours, Jouni ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
