VDR developer version 1.3.49 is now available at
ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.3.49.tar.bz2
A 'diff' against the previous version is available at
ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.3.48-49.diff
Well, it's an unusual time for a new developer version of VDR, but since there have been a few last minute fixes, and I really want to make version 1.4.0 happen this sunday, I'm releasing this hopefully last release candidate today.
Please take a thorough look at the changes - especially the ones to the actual program code files - to help avoid any stupid last minute bugs.
If there are no more serious bugs, this will become the final version 1.4.0 this sunday :-)
The changes since version 1.3.48:
- Fixed initializing 'noapiv' in the Makefile (reported by Ronny Kornexl). - Fixed extracting APIVERSION to work with older versions of 'sed' (reported by Oliver Endriss; thanks also to Udo Richter for a shorter version of the 'sed' expression). - Fixed broken APIVERSION extraction line in 'newplugin' (thanks to Oliver Endriss). - Fixed entering '0' in a cMenuEditIntItem (reported by Mirko Dölle). - Updated the Italian OSD texts (thanks to Nino Gerbino). - Added a note about adding 'INCLUDES += -I$(DVBDIR)/include' to an existing Make.config (problem reported by Markus Ehrnsperger). - Fixed handling the cPluginManager::Active() result when pressing the "Power" key (reported by Werner Färber). - Added a hint about commenting out the line '#define USE_FADVISE' in tools.c in case of problems with replaying in fast forward mode if the video directory is mounted via a Samba share (reported by Andy Grobb). - Changed the "Really restart?" prompt in the call to cPluginManager::Active() in menu.c to "restart anyway?" (suggested by Rolf Ahrenberg). - Removed the obsolete "'1' for encrypted radio channels" part from the description of the VPID in vdr.5 (reported by Alexander Hans). - Fixed tuning to the channel of a VPS timer if the device is the actual device.
Have fun!
Klaus
Am 28.04.2006 um 15:50 schrieb Klaus Schmidinger:
The changes since version 1.3.48:
I have the following problem: If a timer is running and i press power off on the remote, VDR shows "eine Aufzeichnung läuft, trotzdem ausschalten?". VDR Shuts down no matter if i press a key or not... Can you verify this?
Ciao, Dominique
Dominique Simon wrote:
Yes, there's still a logical bug in it...
The 1.3.49 code shuts down if the recording shut down is confirmed *OR* if the plugin shut down is confirmed. Unfortunately, if no plugin has activity, this counts as confirmed, so VDR will shut down no matter if recording shut down was confirmed or not.
The attached patch reverses the logic a bit, and shuts down if recordings *AND* plugins confirm. UserShutdown is set up first, so that any non-confirm can leave with 'break'. If all tests pass, ForceShutdown is set too.
I've tested all variants I can think of, and it seems to work. More testing is of course welcome, so we can mark this one fixed before Sunday.
Btw: There's a slight change in behavior since 1.3.46: Before, a simple shut down without confirms did not set ForceShutdown=true, since then, ForceShutdown is set true even if no confirmation was necessary. cPluginManager::Active does not differentiate between confirmed, denied and 'no activity'. The new way is slightly more aggressive, but seems more consistent and I don't think that it has bigger negative side effects.
(1.3.49 can shut down while cutting, 1.3.46 can shut down while cutting only if also a recording is running, and shutdown is confirmed.)
Cheers,
Udo
--- vdr-1.3.49-orig/vdr.c 2006-04-28 15:23:55.000000000 +0200 +++ vdr-1.3.49/vdr.c 2006-04-29 03:20:25.876919696 +0200 @@ -976,14 +971,15 @@ Skins.Message(mtError, tr("Can't shutdown - option '-s' not given!")); break; } - if (cRecordControls::Active()) { - if (Interface->Confirm(tr("Recording - shut down anyway?"))) - ForceShutdown = true; - } - if (!cPluginManager::Active(tr("shut down anyway?"))) - ForceShutdown = true; LastActivity = 1; // not 0, see below! UserShutdown = true; + if (cRecordControls::Active()) { + if (!Interface->Confirm(tr("Recording - shut down anyway?"))) + break; + } + if (cPluginManager::Active(tr("shut down anyway?"))) + break; + ForceShutdown = true; break; default: break; }
Am 29.04.2006 um 04:14 schrieb Udo Richter:
Thanks, your patch brings back the usul behavior. I used to hit the poweroff key when a recording is running and i leave the house for example, VDR used to shut down then when the timer stopped. This does not work anymore, even with your patch. Any idea how to bring this back?
Ciao, Dominique
Udo Richter wrote:
Thanks, looks good to me.
Since I personally don't use the shutdown feature, it's all the more important that you folks test this extensively.
While adding your patch I realized that the code formatting of the 'case kPower:' was somewhat off, too, so I shifted it to the left. The final patch now looks as attached.
I guess it's ok if I don't release another new version, it should be easy enough to apply this patch and test it thoroughly.
So we still have a GO for version 1.4.0 on Sunday :-)
Klaus
Small update to the Polish translation.
-- Jaroslaw Swierczynski swiergot@gmail.com www.archlinux.org | www.juvepoland.com
Klaus Schmidinger wrote:
VDR developer version 1.3.49 is now available at
If there are no more serious bugs, this will become the final version 1.4.0 this sunday :-)
looking through local changes, i think this is the only one obviously-correct enough -- i got +/- wrong when calculating the size; should be mostly harmless anyway (was just calling fadvise with too large area).
diff -urNp vdr-1.3.49.org/tools.c vdr-1.3.49.min/tools.c --- vdr-1.3.49.org/tools.c 2006-04-21 15:12:47.000000000 +0000 +++ vdr-1.3.49.min/tools.c 2006-04-29 09:10:26.000000000 +0000 @@ -1179,7 +1179,7 @@ ssize_t cUnbufferedFile::Read(void *Data } else if (cachedend > ahead && cachedend - curpos > READCHUNK * 2) { // current position has moved back enough, shrink head window. - FadviseDrop(curpos + READCHUNK, cachedend - curpos + READCHUNK); + FadviseDrop(curpos + READCHUNK, cachedend - (curpos + READCHUNK)); cachedend = curpos + READCHUNK; } }
i don't think this really fixes any real problems, just a correctness issue :) Basically the code was trying to free a bit too much data, when playing or jumping backwards -- i doubt it matters in RL. It probably doesn't even matter when replaying an ongoing recording near the end (the only case i can think of where it actually could make noticeable difference, by forcing the new data to disk). As i said it's mostly harmless, just wanted to mention it once i got a current vdr running and before i forget about it. Certainly it doesn't deserve to hold up 1.4.0 by itself.
artur
Hi,
attached patch fixes that vdr (the executable and the static lib libpsi) get compiled with fPIC. Only shared libs need PIC, thus add this flag only when building plug-ins. Furthermore I added -g and -Wall to CFLAGS, as well, because of reasons of symmetry.
Please apply.
diff -urd vdr-1.3.49/libsi/Makefile vdr-1.3.49.n/libsi/Makefile --- vdr-1.3.49/libsi/Makefile 2005-05-29 13:47:12.000000000 +0200 +++ vdr-1.3.49.n/libsi/Makefile 2006-04-29 12:13:59.000000000 +0200 @@ -6,7 +6,7 @@ ### The C++ compiler and options:
CXX ?= g++ -CXXFLAGS ?= -fPIC -O2 -g -Wall -Woverloaded-virtual +CXXFLAGS ?= -O2 -g -Wall -Woverloaded-virtual AR = ar ARFLAGS = ru RANLIB = ranlib diff -urd vdr-1.3.49/Make.config.template vdr-1.3.49.n/Make.config.template --- vdr-1.3.49/Make.config.template 2006-04-15 14:28:03.000000000 +0200 +++ vdr-1.3.49.n/Make.config.template 2006-04-29 12:32:33.000000000 +0200 @@ -14,7 +14,7 @@ CFLAGS = -O2
CXX = g++ -CXXFLAGS = -fPIC -g -O2 -Wall -Woverloaded-virtual +CXXFLAGS = -g -O2 -Wall -Woverloaded-virtual
### The directory environment:
diff -urd vdr-1.3.49/Makefile vdr-1.3.49.n/Makefile --- vdr-1.3.49/Makefile 2006-04-24 19:18:06.000000000 +0200 +++ vdr-1.3.49.n/Makefile 2006-04-29 12:33:23.000000000 +0200 @@ -9,10 +9,10 @@ .DELETE_ON_ERROR:
CC ?= gcc -CFLAGS ?= -O2 +CFLAGS ?= -g -O2 -Wall
CXX ?= g++ -CXXFLAGS ?= -fPIC -g -O2 -Wall -Woverloaded-virtual +CXXFLAGS ?= -g -O2 -Wall -Woverloaded-virtual
LSIDIR = ./libsi MANDIR = /usr/local/man @@ -175,6 +175,8 @@ # Plugins:
plugins: include-dir + CFLAGS="-fPIC $(CFLAGS)" + CXXFLAGS="-fPIC $(CXXFLAGS)" @failed="";\ noapiv="";\ for i in `ls $(PLUGINDIR)/src | grep -v '[^a-z0-9]'`; do\
Cheers,
Am Samstag April 29 2006 12:38 schrieb Prakash Punnoor:
Updated patch: I forgot to add -g -Wall to Make.conf.template...
diff -urd vdr-1.3.49/libsi/Makefile vdr-1.3.49.n/libsi/Makefile --- vdr-1.3.49/libsi/Makefile 2005-05-29 13:47:12.000000000 +0200 +++ vdr-1.3.49.n/libsi/Makefile 2006-04-29 12:13:59.000000000 +0200 @@ -6,7 +6,7 @@ ### The C++ compiler and options:
CXX ?= g++ -CXXFLAGS ?= -fPIC -O2 -g -Wall -Woverloaded-virtual +CXXFLAGS ?= -O2 -g -Wall -Woverloaded-virtual AR = ar ARFLAGS = ru RANLIB = ranlib diff -urd vdr-1.3.49/Make.config.template vdr-1.3.49.n/Make.config.template --- vdr-1.3.49/Make.config.template 2006-04-15 14:28:03.000000000 +0200 +++ vdr-1.3.49.n/Make.config.template 2006-04-29 12:41:21.000000000 +0200 @@ -11,10 +11,10 @@ ### The C compiler and options:
CC = gcc -CFLAGS = -O2 +CFLAGS = -g -O2 -Wall
CXX = g++ -CXXFLAGS = -fPIC -g -O2 -Wall -Woverloaded-virtual +CXXFLAGS = -g -O2 -Wall -Woverloaded-virtual
### The directory environment:
diff -urd vdr-1.3.49/Makefile vdr-1.3.49.n/Makefile --- vdr-1.3.49/Makefile 2006-04-24 19:18:06.000000000 +0200 +++ vdr-1.3.49.n/Makefile 2006-04-29 12:33:23.000000000 +0200 @@ -9,10 +9,10 @@ .DELETE_ON_ERROR:
CC ?= gcc -CFLAGS ?= -O2 +CFLAGS ?= -g -O2 -Wall
CXX ?= g++ -CXXFLAGS ?= -fPIC -g -O2 -Wall -Woverloaded-virtual +CXXFLAGS ?= -g -O2 -Wall -Woverloaded-virtual
LSIDIR = ./libsi MANDIR = /usr/local/man @@ -175,6 +175,8 @@ # Plugins:
plugins: include-dir + CFLAGS="-fPIC $(CFLAGS)" + CXXFLAGS="-fPIC $(CXXFLAGS)" @failed="";\ noapiv="";\ for i in `ls $(PLUGINDIR)/src | grep -v '[^a-z0-9]'`; do\
Am Samstag April 29 2006 13:57 schrieb Klaus Schmidinger:
Don't know. Should be posted to the list.
Well, I don't think compiling too much code as PIC will cause problems (apart from (minor) possible performance lost), nevertheless it is unneeded.
Prakash Punnoor wrote:
Did anybody else receive that posting? If so, can you please forward a copy to me?
Is that "compile time" or "runtime" performance?
Apparently PIC is only available on special processors, especially *not* Intel, so I can't test this myself.
Let's wait with this until after version 1.4.
Klaus
On Sat, Apr 29, 2006 at 03:37:17PM +0200, Klaus Schmidinger wrote:
I bounced my copy of it to you. It was only partially archived (no text content):
http://www.linuxtv.org/pipermail/vdr/2006-April/009133.html
Marko
Hi,
On Sat, 29 Apr 2006 15:37:17 +0200 Klaus Schmidinger Klaus.Schmidinger@cadsoft.de wrote:
Did anybody else receive that posting? If so, can you please forward a copy to me?
I've attached it as it's smaller than other peoples' signatures :-)
Should be kind of "execution time", not exactly "runtime". It just adds a few memory remappings on application startup by updating an address lookup table. This may cause some additional memory lookups at runtime, too. Albeit I'm interested in real numbers, I'm pretty sure it won't affect performance too much.
Apparently PIC is only available on special processors, especially *not* Intel, so I can't test this myself.
Hm, it should be available on intel.
Let's wait with this until after version 1.4.
There are good reasons for doing it this way, yes.
-hwh
Am Samstag April 29 2006 15:50 schrieb Hans-Werner Hilse:
Well that patch - as I stated in the updated post - missing one minor thing. Sorry for the confusion...
Not exactly. You have to distinguish: If you have the choice to load non-PIC or PIC shared libs (eg on x86):
PIC generally loads faster, as you don't need text relocations performed AFAIK. But PIC is generally slower on execution due to losing the ebx register (on x86) and gcc being pedantically dumb to not free it up when it could be used even in PIC mode. (There could also be security risks with non-PIC shared libs, IIRC.)
On x86-64 for example you have no choice: *shared* libs need to be PIC.
On the other hand *executables* and *static libs* (well it is a wrong term actually, they are just a little bit more than a conglomeration of object files) generally *don't* need to be PIC. But this is what current VDR Makefile does - thus (possibly) wasting performance.
I hope this clears it up. :-)
Am Samstag April 29 2006 15:37 schrieb Klaus Schmidinger:
You don't need it. There wasn't anything more written than in the second updated post. ;-)
Runtime - you lose one register. In fact it would perhaps be nice to offer "optimizing" flags, as well (perhaps in the template, comented out or alike), which don't put in debug symbols (no -g) and also pass -fomit-frame-pointer (making one more register available, at least on x86).
Apparently PIC is only available on special processors, especially *not* Intel, so I can't test this myself.
??? PIC = position independent code. You already *are* compiling everything PIC - which is not needed. Only for shared libs it is [well x86 can live with non-PIC, but x86_64 cannot for example], as I pointed out. You could also check the gcc manual on fPIC.
So my patch shouldn't break anything *additional*. But your Makefile as such is not very portable, as the gcc man states PIC is not everywhere available. For more portability one needs to check whether -fPIC is supported on the platform/arch and then activate where needed. Therefore eg. things like libtool exists...
But of course you can postpone the patch, as it is not critical.
Prakash Punnoor wrote:
I'm sure there is enough high level stuff you can optimize in vdr before you need to worry about registers or compiler flags. IMO thinking about whether -fPIC hurts the vdr executable is waste of time. The trend goes to position independent exectuables anyways btw.
It compiles on all SUSE supported architectures. Whether it works, I don't know. It doesn't matter anyways, I seriously doubt anyone is going to plug a dvb card into a s390 to use vdr with it :-)
cu Ludwig
I demand that Klaus Schmidinger may or may not have written...
[snip]
Apparently PIC is only available on special processors, especially *not* Intel, [...]
False. You need -fPIC for libraries on ARM, which means that you need it on XScale - and that's an Intel processor...
Darren Salt wrote:
I looked up the -fPIC option in "Using and Porting GNU CC", version 2.95, where it says on page 110:
"This option makes a difference on the m68k, m88k, and the Sparc."
Well, that manual is a little old, so maybe that information is outdated...
Klaus
On Sonntag 30 April 2006 10:50, Klaus Schmidinger wrote:
the same hint is still included in the manpage of "gcc (GCC) 4.0.2"
-fPIC If supported for the target machine, emit position-independent code, suitable for dynamic linking and avoiding any limit on the size of the global offset table. This option makes a difference on the m68k, PowerPC and SPARC. Position-independent code requires special support, and therefore works only on certain machines.
i my idea is likewise that it doesn't care on Intel systems.
Greets Jörg Wendel
On Sunday 30 April 2006 11:06, Jörg Wendel wrote:
PIC does(!) make a change on Intel systems, too.
PIC = Position Independant Code That means the compiler will not assamble absolute jumps but create a table with addresses to use indirect address lookup.
For a better description have a look at: http://www.gentoo.org/proj/en/hardened/pic-guide.xml and http://www.gentoo.org/proj/en/hardened/pic-internals.xml
Greetings Matthias
Klaus Schmidinger wrote:
"This option makes a difference on the m68k, m88k, and the Sparc."
Well, that manual is a little old, so maybe that information is outdated...
It seems to be a little bit outdated. amd64 and ia64 require -fPIC for shared libs too. That's why the Debian policy requires all shared libs to be compiled with -fPIC. There are only a few architectures, that support shared non-relocatable code. That's i386 and maybe anonther one. All other architecures require -fPIC.
Tobias
Prakash Punnoor wrote:
Meanwhile I've received the original mail. Apparently it was stuck at arcor-online.net:
Received: from mail-in-09.arcor-online.net (mail-in-09.arcor-online.net [151.189.21.49]) by raven.cadsoft.de (8.13.3/8.13.3) with ESMTP id k3TJx0wh016969 for Klaus.Schmidinger@cadsoft.de; Sat, 29 Apr 2006 21:59:00 +0200 Received: from mail-in-07-z2.arcor-online.net (mail-in-07-z2.arcor-online.net [151.189.8.19]) by mail-in-09.arcor-online.net (Postfix) with ESMTP id 459B9267B83; Sat, 29 Apr 2006 12:38:40 +0200 (CEST)
Presumably the problem was that you CC'd me...
From: Prakash Punnoor prakash@punnoor.de To: vdr@linuxtv.org Subject: Re: [vdr] [ANNOUNCE] VDR developer version 1.3.49 Date: Sat, 29 Apr 2006 12:38:42 +0200 Cc: Klaus Schmidinger Klaus.Schmidinger@cadsoft.de
...so the mailing list software didn't send me a copy. Please don't CC me - I am subscribed to the list ;-)
Klaus
I annunce an update channelscan and sysinfo plugin,
channelscan changelog:
2006-04-30: Version 0.1.0 - Update APIVERSION Makefile - Minor release change because it's ready for vdr-1.4 (test with vdr-1.4.49)
sysinfo changelog:
2006-04-30: Version 0.1.0 - Update APIVERSION Makefile - Minor release change because it's ready for vdr-1.4 (test with vdr-1.4.49)
It's a ready from download at: www.kikko77.altervista.org
tinconn@virgilio.it wrote:
I annunce an update channelscan and sysinfo plugin,
It seems that channelscan does not know how to select correct diseqc-port. It only works if diseqc-switch is allready somehow switched to correct satellite. Sort of chicken-egg syndrome.
On Sat, Apr 29, 2006 at 12:46:34PM +0200, Prakash Punnoor wrote:
Hello,
is there a way to set the FLAGS for vdr/libsi/plugins separetly in Make.config ?
Thank,
Klaus Schmidinger wrote:
When checking VDR with valgrind, I found a small memory leak. The attached patch should fix it.
Regards,
Tobias
--- vdr-1.3.49.orig/eit.c +++ vdr-1.3.49/eit.c @@ -104,7 +104,10 @@ cComponents *Components = NULL; for (SI::Loop::Iterator it2; (d = SiEitEvent.eventDescriptors.getNext(it2)); ) { if (ExternalData && d->getDescriptorTag() != SI::ComponentDescriptorTag) + { + delete d; continue; + } switch (d->getDescriptorTag()) { case SI::ExtendedEventDescriptorTag: { SI::ExtendedEventDescriptor *eed = (SI::ExtendedEventDescriptor *)d;
Klaus Schmidinger wrote:
Thanks - applied for version 1.4.0.
I'm afraid I've found another minor memory leak. Valgrind would really be worth it's money, if it wouldn't be free :-)
When playing back a recording, the file handle gets closed, but not the cUnbufferedFile object. I'm not sure why a distinction is made between recording and not recording when closing the file, so I just use CloseVideoFile() in both cases, which correctly frees the object. Hope this is correct. See attached patch.
Regards,
Tobias
--- vdr-1.3.49.orig/recording.c +++ vdr-1.3.49/recording.c @@ -1436,7 +1436,7 @@ void cFileName::Close(void) { if (file) { - if ((record && CloseVideoFile(file) < 0) || (!record && file->Close() < 0)) + if (CloseVideoFile(file)) LOG_ERROR_STR(fileName); file = NULL; }
Tobias Grimm wrote:
The CloseVideoFile() function is the counterpart to the OpenVideoFile() function, which takes care of handling distributed video directories etc. Before the introduction of cUnbufferedFile the code in cFileName::Close() was ok, but now it would appear that your change is actually the right thing to do.
Applied for version 1.4.0.
Klaus
-
Artur Skawina -
C.Y.M -
Darren Salt -
Dominique Simon -
Gregoire Favre -
Hans-Werner Hilse -
Jaroslaw Swierczynski -
Jörg Wendel -
Klaus Schmidinger -
Lauri Tischler -
Ludwig Nussel -
Marko Mäkelä -
Matthias Schwarzott -
Prakash Punnoor -
tinconn＠virgilio.it -
Tobias Grimm -
Udo Richter