VDR maintenance patch 1.4.0-2 is now available at
ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.4.0-2.diff
This is a 'diff' against the official version 1.4.0 plus all previous 1.4.0-X maintenance patches.
Small fixes to the officially released VDR versions will be first made available as "maintenance patches" in the Developer directory, so that they can be reviewed and tested before a new official release is published.
So please apply the patches
ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.4.0-1.diff ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.4.0-2.diff
in the given sequence to the original VDR version 1.4.0 and report whether it works (or if it causes any new problems).
There are several places in the code where I would actually have had to change some interfaces, but didn't do so in order to keep the API version constant, so that existing plugins don't need to be recompiled. However, this also keeps me from including Stefan Huelswitts fixes to the 'libsi' code. So the question is: is it worth keeping the API version constant, or should I just go ahead and bump it up, and drop all the '#if APIVERSNUM...' stuff and include Stefan's fixes?
The changes since version 1.4.0-1:
- Removed leftover LSMOD=... line from 'runvdr'. - Modified the Makefile to copy additional libraries a plugin might provide (suggested by Wayne Keer). See PLUGINS.html for details. - Fixed handling Transfer Mode when replaying Dolby Digital audio and the option '-a' was given (based on a patch from Werner Fink). To avoid having to increment the API version, several #if checks have been introduced around this. These will be removed once the API version actually needs to be incremented. - Fixed deleting the 'skinDescriptions' in cMenuSetupOSD::~cMenuSetupOSD() (thanks to Tobias Grimm). - Fixed calculating the start time of repeated timers with "first day" (thanks to Udo Richter). - Now setting a timer's cached start time to 0 after a call to Skip() (thanks to Udo Richter). - Fixed handling the running status of EPG events in case the "Schedule" menu is currently open (i.e. a write lock on the schedules data can't be achieved). - Fixed handling VPS timers in case the EPG event hasn't been 'seen' in a while. - Fixed calculating the cache size in cUnbufferedFile::Read() (thanks to Artur Skawina). - Removed -fPIC from VDR's and libsi's Makefile (suggested by Prakash Punnoor). - Modifed the device selection to better handle timer conflicts (reported by Christian Wieninger). - Avoiding a compiler warning in libsi's TypeLoop::operator[]. - Now processing the "frequency list descriptor" (based on a patch from Anssi Hannula). - Improved the repeat function for LIRC remote controls (thanks to Joerg Riechardt). - Fixed moving channels, which sometimes stopped the current replay session (reported by Mirko Dölle). - Fixed deleting channels in case the current channel's number changes (reported by Mirko Dölle).
Have fun!
Klaus
On 28 May 2006 Klaus Schmidinger Klaus.Schmidinger@cadsoft.de wrote:
So the question is: is it worth keeping the API version constant, or should I just go ahead and bump it up, and drop all the '#if APIVERSNUM...' stuff and include Stefan's fixes?
While I see the idea behind the APIVERSION, it's quite inefficient IMO.
First point is, that although we have many plugins there are still loads of patches for the VDR core available. Nearly all of them change headerfiles (and thus the API) without changing APIVERSION. So we have different APIs with same APIVERSION, preteding binary compatibility which isn't always there.
Second is, that there is only one API version for very different types of APIs e.g. plugin API, channel API, libsi API. This leads to the problem you face now: it's impossible to do development (may be beside some trivial bug fixes) without changing any header file. If you try to keep the API unchanged, it will stop development. *)
I think it's generaly a bad idea to hold back any bug fix, improvement or development only to keep an API number constant.
Recompiling the plugins is only a 'make plugins' away from 'make' and I guess time for that is negligible.
Just my two cents.
Regards.
*) Situation would improve if we had different API versions for different APIs, but we won't be able to code this to the filename. This could be overcome, by having all plugins to include a static struct this used APIs and their version. VDR could check this at runtime.
Stefan Huelswitt wrote:
On 28 May 2006 Klaus Schmidinger Klaus.Schmidinger@cadsoft.de wrote:
So the question is: is it worth keeping the API version constant, or should I just go ahead and bump it up, and drop all the '#if APIVERSNUM...' stuff and include Stefan's fixes?
While I see the idea behind the APIVERSION, it's quite inefficient IMO.
First point is, that although we have many plugins there are still loads of patches for the VDR core available. Nearly all of them change headerfiles (and thus the API) without changing APIVERSION. So we have different APIs with same APIVERSION, preteding binary compatibility which isn't always there.
Second is, that there is only one API version for very different types of APIs e.g. plugin API, channel API, libsi API. This leads to the problem you face now: it's impossible to do development (may be beside some trivial bug fixes) without changing any header file. If you try to keep the API unchanged, it will stop development. *)
I think it's generaly a bad idea to hold back any bug fix, improvement or development only to keep an API number constant.
Recompiling the plugins is only a 'make plugins' away from 'make' and I guess time for that is negligible.
Well, that was my opinion all the time, but still there were always people complaining about having to recompile all plugins with every new version of VDR. Hence the attempt to ease this pain with the introduction of APIVERSION.
*) Situation would improve if we had different API versions for different APIs, but we won't be able to code this to the filename. This could be overcome, by having all plugins to include a static struct this used APIs and their version. VDR could check this at runtime.
That would be total overkill. I guess I shouldn't have introduced APIVERSION in the first place, since, as you stated, it just takes a 'make plugins'. Oh well, so I'll bump up the API version, drop all the '#if APIVERSNUM...' stuff and include Stefan's 'libsi' fixes (which, BTW, don't touch anything the core VDR would actually use).
Klaus
On Sun, 2006-05-28 at 16:12 +0200, Klaus Schmidinger wrote:
That would be total overkill. I guess I shouldn't have introduced APIVERSION in the first place, since, as you stated, it just takes a 'make plugins'. Oh well, so I'll bump up the API version, drop all the '#if APIVERSNUM...' stuff and include Stefan's 'libsi' fixes
My .02€: please keep APIVERSION, but please also don't be afraid to bump it whenever needed. No need to introduce #if madness. APIVERSION is a convenience and shouldn't prevent real fixes or enhancements from entering the codebase.
Ville Skyttä schrieb:
On Sun, 2006-05-28 at 16:12 +0200, Klaus Schmidinger wrote:
That would be total overkill. I guess I shouldn't have introduced APIVERSION in the first place, since, as you stated, it just takes a 'make plugins'. Oh well, so I'll bump up the API version, drop all the '#if APIVERSNUM...' stuff and include Stefan's 'libsi' fixes
My .02€: please keep APIVERSION, but please also don't be afraid to bump it whenever needed. No need to introduce #if madness. APIVERSION is a convenience and shouldn't prevent real fixes or enhancements from entering the codebase.
Yep agree with this. :) +1 ;)
Ville Skyttä schrieb:
On Sun, 2006-05-28 at 16:12 +0200, Klaus Schmidinger wrote:
That would be total overkill. I guess I shouldn't have introduced APIVERSION in the first place, since, as you stated, it just takes a 'make plugins'. Oh well, so I'll bump up the API version, drop all the '#if APIVERSNUM...' stuff and include Stefan's 'libsi' fixes
My .02â¬: please keep APIVERSION, but please also don't be afraid to bump it whenever needed. No need to introduce #if madness. APIVERSION is a convenience and shouldn't prevent real fixes or enhancements from entering the codebase.
Yep agree with this. :) +1 ;)
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
As soon as APIVERSION avoids fixes or useful improvments (i.e. director plugin :-)) it should be dropped. As already mentioned before there are so many patches which chamge the api, that the APIVERSION is not a very reliable way to avoid the need of recompiling plugins. Anyway is it a big mess to recompile the plugins? This additinal step while compiling a new vdr version should not take too long.
Helmut Auer wrote:
Just try to compile 220 Plugins on a Celeron 600 ;) Anyway for my distri I always do a recompile ( > 1 hour )
Thats why I've moved the build environment to my 3200+ desktop machine, and then just copy the binaries to the VDR machine. ;)
(and, really, how many of these 220 do you actually use?)
I think the main advantage of APIVERSION is not for selfmade VDR, but for binary distributions. Distributions usually have a fixed small set of patches and can avoid lots of new packages if APIVERSION didn't change.
Cheers,
Udo
On Mon, 2006-05-29 at 16:51 +0200, Udo Richter wrote:
I think the main advantage of APIVERSION is not for selfmade VDR, but for binary distributions. Distributions usually have a fixed small set of patches and can avoid lots of new packages if APIVERSION didn't change.
Exactly. And note that in addition to building lots of packages (maintainer modifies X plugin packages, and builds them for Y architectures, Z distro versions), users need to download them, and every package upgrade is a potential problem/extra work spot for end users regarding config files (although if the packages are well made, this is not a big problem). APIVERSION helps reducing work for maintainers and end users, and avoids unnecessary downloads.
Ville Skyttä wrote:
this is not a big problem). APIVERSION helps reducing work for maintainers and end users, and avoids unnecessary downloads.
As a maintainer of Debian packages with my own package repository, I fully agree. Please keep APIVERSION and whenever there is a need to change the interface, just increase it.
Tobias
Most VDR users I know use only a small handful of plugins. Someone using 10+ plugins on a slow cpu is the minority.
On 5/29/06, Helmut Auer vdr@helmutauer.de wrote:
Hi
Anyway is it a big mess to recompile the plugins? This additinal step while compiling a new vdr version should not take too long.
Just try to compile 220 Plugins on a Celeron 600 ;) Anyway for my distri I always do a recompile ( > 1 hour )
-- Helmut Auer, helmut@helmutauer.de
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
- Modified the Makefile to copy additional libraries a plugin might provide
The change above fixes installation of the libraries, but I think some cleanup still needs to be added to the Makefile.
--snip--
--- vdr-1.4.0/Makefile.orig 2006-05-14 08:29:39.000000000 -0700 +++ vdr-1.4.0/Makefile 2006-05-14 08:30:36.000000000 -0700 @@ -191,7 +191,7 @@
clean-plugins: @for i in `ls $(PLUGINDIR)/src | grep -v '[^a-z0-9]'`; do $(MAKE) -C "$(PLUGINDIR)/src/$$i" clean; done - @-rm -f $(PLUGINDIR)/lib/libvdr-*.so.$(APIVERSION) + @-rm -f $(PLUGINDIR)/lib/*.so.$(APIVERSION)
# Install the files:
--snip--
Best Regards.
-
Helmut Auer -
Klaus Schmidinger -
Matthias Haas -
s.huelswitt＠gmx.de -
Steffen Barszus -
Stone -
Tobias Grimm -
Udo Richter -
VDR User -
Ville Skyttä