VDR developer version 1.5.15 is now available at
ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.5.15.tar.bz2
A 'diff' against the previous developer version is available at
ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.5.14-1.5.15.diff
NOTE: =====
This is the final step towards a stable version 1.6.0. Please report any bugs as soon as possible, so that I can prepare a release candidate next weekend. If nothing unexpected happens, I plan to release version 1.6.0 on March 2.
WARNING: ========
This is a *developer* version. Even though *I* use it in my productive environment, I strongly recommend that you only use it under controlled conditions and for testing and debugging.
The changes since version 1.5.14:
- Updated the Italian OSD texts (thanks to Diego Pierotto). - Added option -i to the pictures plugin's pic2mpg to ignore unknown file types. - Revoked the switch to the "multiproto" driver in order to make a new stable version before making this big switch and forcing all users to install a driver that is not yet in the kernel source. The removed code will reappear in version 1.7.0. Note that you may need to switch back to an older version of your channels.conf file if you have already used version 1.5.14, because it introduced new parameters. - Added the new command line option --userdump to enable core dumps in case VDR is run as root with option -u (thanks to Hans-Werner Hilse). - Speeded up anti-aliased font rendering by caching the blend indexes (based on a suggestion by Martin Wache). - Fixed setting the OSD area in the pictures plugin. - Ignoring "repeat" and "release" keys in the time search entry mode during replay, to avoid inadvertently leaving it in case a key is pressed too long (suggested by Andreas Brugger). - Improved sending all frames to devices that can handle them in fast forward trick speeds, including subtitles (thanks to Timo Eskola). - The section handler is now stopped before the device is destroyed, to avoid accessing file handles after they have become invalid (thanks to Reinhard Nissl for reporting an invalid access when ending VDR, and to Deti Fliegl for a patch that was used to implement StopSectionHandler()). - Fixed setting the date in the channel display of the classic and sttng skins, to avoid unnecessary OSD access (thanks to Marco Schlüßler). - The free disk space is now also displayed in the title of the "Recordings" menu (suggested by Walter Koch). - Changed the message "Upcoming VPS recording!" to "Upcoming recording!" because it applies to non-VPS recordings as well. - Fixed a loss of a timer's 'recording' flag after modifying it via MODT. - Fixed detecting directories in cFileNameList::Load(). - Running the thread that removes deleted recordings at a low priority to (maybe) avoid stuttering replay in case the thread is run during replay. - Limiting the length of the recording name in timers in case VDR is run with --vfat, in order to avoid names that are too long for Windows (suggested by Rolf Ahrenberg). - Using cString::sprintf() instead of asprintf() (thanks to Wolfgang Rohdewald for pointing out a possible problem if the return value is not checked). Plugin authors may want to consider doing the same. For convenience there is now an additional version of cString::sprintf() that accepts a va_list parameter. - When deleting the recording that is currently replayed, the replay is now stopped immediately (thanks to Mikko Matilainen for reporting a possible crash if the Info key is pressed after deleting the currently replayed recording). - Updated the Russian OSD texts (thanks to Oleg Roitburd). - When determining the amount of free disk space, any deleted (but not yet removed) recordings on different file systems (that are mounted under the video directory) are no longer taken into account. - When running out of disk space during a recording, only such deleted or old recordings are removed, that actually are on the video directory file system(s). This prevents VDR from accidentally deleting recordings on other file systems, which would not add any free space to the video directory. - Implemented the cStatus, cDevice and cPlayer functions for setting subtitle tracks in plugins (thanks to Petri Hintukainen). - Added cStatus::TimerChange() to inform plugins about changes to the list of timers (based on a patch from Benedikt Elser). - Added new cStatus functions to the 'status' plugin. - Added missing #include <limits.h> to epg.c and menuitems.h (thanks to Ville Skyttä). - The new function cSkin::SetScrollbar() can be implemented by skins to display a scrollbar in every list menu. The 'classic' and 'sttng' skins have been changed accordingly, as well as the 'skincurses' plugin. - Introduced 'operator const void * ()' in cString to catch cases where operator*() should be used. - Fixed calculating the scrollbar sizes in the skins.
The changes regarding the handling of deleted recordings have not been tested very intensely, yet. Please take a close look at the modified code in
recording.c: AssertFreeDiskSpace() cRecordings::TotalFileSizeMB() tools.c: EntriesOnSameFileSystem() videodir.c: IsOnVideoDirectoryFileSystem()
and report any obvious flaws. It would also be great if somebody could actually run some tests that verify the proper functionality of this new code. Are there, maybe, any other places where IsOnVideoDirectoryFileSystem() should be used?
*When reporting problems, please don't reply to this message!* Create a new thread instead, using a descriptive subject!
Have fun!
Klaus
Compiling the new version on my 64-bit AMD processor produces the warnings below. I think they've probably been there for a while, I don't usually watch VDR compiling...
# g++ -v Using built-in specs. Target: x86_64-mandriva-linux-gnu Configured with: ../configure --prefix=/usr --libexecdir=/usr/lib --with-slibdir=/lib64 --mandir=/usr/share/man --infodir=/usr/share/info --enable-checking=release --enable-languages=c,c++,ada,fortran,objc,obj-c++,java --host=x86_64-mandriva-linux-gnu --with-cpu=generic --with-system-zlib --enable-threads=posix --enable-shared --enable-long-long --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --enable-java-awt=gtk --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --enable-gtk-cairo --disable-libjava-multilib --enable-ssp --disable-libssp Thread model: posix gcc version 4.2.2 20071128 (prerelease) (4.2.2-3.1mdv2008.0)
--------------------------- g++ -g -O2 -Wall -Woverloaded-virtual -Wno-parentheses -c -DVDR_USER="vdr" -DLIRC_DEVICE="/dev/lircd" -DRCU_DEVICE="/dev/ttyS1" -D_GNU_SOURCE -DVIDEODIR="/video/video" -DCONFDIR="/video/video" -DPLUGINDIR="./PLUGINS/lib" -DLOCDIR="./locale" -I/usr/include/freetype2 dvbsubtitle.c dvbsubtitle.c: In member function ‘int cDvbSubtitleConverter::Convert(const uchar*, int)’: dvbsubtitle.c:709: warning: format ‘%lld’ expects type ‘long long int’, but argument 3 has type ‘int64_t’ dvbsubtitle.c: In member function ‘virtual void cDvbSubtitleConverter::Action()’: dvbsubtitle.c:776: warning: format ‘%lld’ expects type ‘long long int’, but argument 3 has type ‘int64_t’ dvbsubtitle.c:776: warning: format ‘%lld’ expects type ‘long long int’, but argument 4 has type ‘int64_t’ dvbsubtitle.c:776: warning: format ‘%lld’ expects type ‘long long int’, but argument 5 has type ‘int64_t’ dvbsubtitle.c: In member function ‘int cDvbSubtitleConverter::ExtractSegment(const uchar*, int, int64_t)’: dvbsubtitle.c:845: warning: format ‘%lld’ expects type ‘long long int’, but argument 5 has type ‘int64_t’
g++ -g -O2 -Wall -Woverloaded-virtual -Wno-parentheses -c -DVDR_USER="vdr" -DLIRC_DEVICE="/dev/lircd" -DRCU_DEVICE="/dev/ttyS1" -D_GNU_SOURCE -DVIDEODIR="/video/video" -DCONFDIR="/video/video" -DPLUGINDIR="./PLUGINS/lib" -DLOCDIR="./locale" -I/usr/include/freetype2 remote.c remote.c: In member function ‘bool cRemote::Put(uint64_t, bool, bool)’: remote.c:124: warning: format ‘%016LX’ expects type ‘long long unsigned int’, but argument 4 has type ‘uint64_t’ remote.c:124: warning: format ‘%016LX’ expects type ‘long long unsigned int’, but argument 4 has type ‘uint64_t’ -------------------------
Dave
On 02/17/08 16:40, Dave P wrote:
Compiling the new version on my 64-bit AMD processor produces the warnings below. I think they've probably been there for a while, I don't usually watch VDR compiling...
# g++ -v Using built-in specs. Target: x86_64-mandriva-linux-gnu Configured with: ../configure --prefix=/usr --libexecdir=/usr/lib --with-slibdir=/lib64 --mandir=/usr/share/man --infodir=/usr/share/info --enable-checking=release --enable-languages=c,c++,ada,fortran,objc,obj-c++,java --host=x86_64-mandriva-linux-gnu --with-cpu=generic --with-system-zlib --enable-threads=posix --enable-shared --enable-long-long --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --enable-java-awt=gtk --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --enable-gtk-cairo --disable-libjava-multilib --enable-ssp --disable-libssp Thread model: posix gcc version 4.2.2 20071128 (prerelease) (4.2.2-3.1mdv2008.0)
g++ -g -O2 -Wall -Woverloaded-virtual -Wno-parentheses -c -DVDR_USER="vdr" -DLIRC_DEVICE="/dev/lircd" -DRCU_DEVICE="/dev/ttyS1" -D_GNU_SOURCE -DVIDEODIR="/video/video" -DCONFDIR="/video/video" -DPLUGINDIR="./PLUGINS/lib" -DLOCDIR="./locale" -I/usr/include/freetype2 dvbsubtitle.c dvbsubtitle.c: In member function ‘int cDvbSubtitleConverter::Convert(const uchar*, int)’: dvbsubtitle.c:709: warning: format ‘%lld’ expects type ‘long long int’, but argument 3 has type ‘int64_t’ dvbsubtitle.c: In member function ‘virtual void cDvbSubtitleConverter::Action()’: dvbsubtitle.c:776: warning: format ‘%lld’ expects type ‘long long int’, but argument 3 has type ‘int64_t’ dvbsubtitle.c:776: warning: format ‘%lld’ expects type ‘long long int’, but argument 4 has type ‘int64_t’ dvbsubtitle.c:776: warning: format ‘%lld’ expects type ‘long long int’, but argument 5 has type ‘int64_t’ dvbsubtitle.c: In member function ‘int cDvbSubtitleConverter::ExtractSegment(const uchar*, int, int64_t)’: dvbsubtitle.c:845: warning: format ‘%lld’ expects type ‘long long int’, but argument 5 has type ‘int64_t’
g++ -g -O2 -Wall -Woverloaded-virtual -Wno-parentheses -c -DVDR_USER="vdr" -DLIRC_DEVICE="/dev/lircd" -DRCU_DEVICE="/dev/ttyS1" -D_GNU_SOURCE -DVIDEODIR="/video/video" -DCONFDIR="/video/video" -DPLUGINDIR="./PLUGINS/lib" -DLOCDIR="./locale" -I/usr/include/freetype2 remote.c remote.c: In member function ‘bool cRemote::Put(uint64_t, bool, bool)’: remote.c:124: warning: format ‘%016LX’ expects type ‘long long unsigned int’, but argument 4 has type ‘uint64_t’ remote.c:124: warning: format ‘%016LX’ expects type ‘long long unsigned int’, but argument 4 has type ‘uint64_t’
Apparently there are macros for this, like PRId64 and such. But i don't like having to write something like
int64_t n = ...; printf("Some number %" PRId64 "\n", n);
Don't know if the gettext mechanisms would be able to handle
tr("Some number %" PRId64 "\n")
I wonder why there ar no proper format specifiers for this. Or are there?
Klaus
On Tuesday 19 Feb 2008, Klaus Schmidinger wrote:
remote.c:124: warning: format "%016LX" expects type "long long unsigned int", but argument 4 has type "uint64_t"
Apparently there are macros for this, like PRId64 and such. But i don't like having to write something like
int64_t n = ...; printf("Some number %" PRId64 "\n", n);
It seems to be the POSIX way...
Don't know if the gettext mechanisms would be able to handle
tr("Some number %" PRId64 "\n")
It would probably be necessary to have multiple translations for the string after macro expansion (negating the whole reason for having the macro in the first place).
Dave P wrote:
On Tuesday 19 Feb 2008, Klaus Schmidinger wrote:
remote.c:124: warning: format "%016LX" expects type "long long unsigned int", but argument 4 has type "uint64_t"
Apparently there are macros for this, like PRId64 and such. But i don't like having to write something like
int64_t n = ...; printf("Some number %" PRId64 "\n", n);
It seems to be the POSIX way...
Don't know if the gettext mechanisms would be able to handle
tr("Some number %" PRId64 "\n")It would probably be necessary to have multiple translations for the string after macro expansion (negating the whole reason for having the macro in the first place).
http://www.gnu.org/software/gettext/manual/html_node/Preparing-Strings.html seems to promise that it works without multiple translations:
Assume you have code like
printf ("The amount is %0" PRId64 "\n", number);
The gettext tools and library have special support for these <inttypes.h> macros. You can therefore simply write
printf (gettext ("The amount is %0" PRId64 "\n"), number);
The PO file will contain the string "The amount is %0<PRId64>\n". The translators will provide a translation containing "%0<PRId64>" as well, and at runtime the gettext function's result will contain the appropriate constant string, "d" or "ld" or "lld".
gettext-0.14 (4 years old) already has this text, so it's probably safe to use by now. (Apparently I have been living under a rock for the last couple of years, I didn't even know about that PRId64 thing - thanks for pointing it out.)
Regards... Michael
Klaus Schmidinger wrote:
Apparently there are macros for this, like PRId64 and such. But i don't like having to write something like
int64_t n = ...; printf("Some number %" PRId64 "\n", n);
Don't know if the gettext mechanisms would be able to handle
tr("Some number %" PRId64 "\n")I wonder why there ar no proper format specifiers for this. Or are there?
The gettext info page says:
A similar case is compile time concatenation of strings. The ISO C 99 include file `<inttypes.h>' contains a macro `PRId64' that can be used as a formatting directive for outputting an `int64_t' integer through `printf'. It expands to a constant string, usually "d" or "ld" or "lld" or something like this, depending on the platform. Assume you have code like
printf ("The amount is %0" PRId64 "\n", number);The `gettext' tools and library have special support for these `<inttypes.h>' macros. You can therefore simply write
printf (gettext ("The amount is %0" PRId64 "\n"), number);The PO file will contain the string "The amount is %0<PRId64>\n". The translators will provide a translation containing "%0<PRId64>" as well, and at runtime the `gettext' function's result will contain the appropriate constant string, "d" or "ld" or "lld".
So translations should still work. The ugliness of those macros remains.
cu Ludwig
On 02/19/08 21:26, Ludwig Nussel wrote:
Klaus Schmidinger wrote:
Apparently there are macros for this, like PRId64 and such. But i don't like having to write something like
int64_t n = ...; printf("Some number %" PRId64 "\n", n);
Don't know if the gettext mechanisms would be able to handle
tr("Some number %" PRId64 "\n")I wonder why there ar no proper format specifiers for this. Or are there?
The gettext info page says:
A similar case is compile time concatenation of strings. The ISO C 99 include file `<inttypes.h>' contains a macro `PRId64' that can be used as a formatting directive for outputting an `int64_t' integer through `printf'. It expands to a constant string, usually "d" or "ld" or "lld" or something like this, depending on the platform. Assume you have code like
printf ("The amount is %0" PRId64 "\n", number);The `gettext' tools and library have special support for these `<inttypes.h>' macros. You can therefore simply write
printf (gettext ("The amount is %0" PRId64 "\n"), number);The PO file will contain the string "The amount is %0<PRId64>\n". The translators will provide a translation containing "%0<PRId64>" as well, and at runtime the `gettext' function's result will contain the appropriate constant string, "d" or "ld" or "lld".
So translations should still work. The ugliness of those macros remains.
I agree. I wonder who came up with this <adjective censored> idea? Why would somebody totally break the printf mechanisms and introduce such ugly macros?
I really hope we can avoid this insanity in VDR...
Klaus
I am no expert, but if they teach STL for C++ why not use that instead which is suppose to be type cast safe, instead of the older printf mechanism. I don't want to start a war on what the best method is. But just wanted to understand. Or would the cost in time be too high to convert everything?
my 2c
Theunis
On 19/02/2008, Klaus Schmidinger Klaus.Schmidinger@cadsoft.de wrote:
On 02/19/08 21:26, Ludwig Nussel wrote:
Klaus Schmidinger wrote:
Apparently there are macros for this, like PRId64 and such. But i don't like having to write something like
int64_t n = ...; printf("Some number %" PRId64 "\n", n);
Don't know if the gettext mechanisms would be able to handle
tr("Some number %" PRId64 "\n")I wonder why there ar no proper format specifiers for this. Or are there?
The gettext info page says:
A similar case is compile time concatenation of strings. The ISO C 99 include file `<inttypes.h>' contains a macro `PRId64' that can be used as a formatting directive for outputting an `int64_t' integer through `printf'. It expands to a constant string, usually "d" or "ld" or "lld" or something like this, depending on the platform. Assume you have code like
printf ("The amount is %0" PRId64 "\n", number);The `gettext' tools and library have special support for these `<inttypes.h>' macros. You can therefore simply write
printf (gettext ("The amount is %0" PRId64 "\n"), number);The PO file will contain the string "The amount is %0<PRId64>\n". The translators will provide a translation containing "%0<PRId64>" as well, and at runtime the `gettext' function's result will contain the appropriate constant string, "d" or "ld" or "lld".
So translations should still work. The ugliness of those macros remains.
I agree. I wonder who came up with this <adjective censored> idea? Why would somebody totally break the printf mechanisms and introduce such ugly macros?
I really hope we can avoid this insanity in VDR...
Klaus
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
On 02/20/08 05:37, Theunis Potgieter wrote:
I am no expert, but if they teach STL for C++ why not use that instead which is suppose to be type cast safe, instead of the older printf mechanism. I don't want to start a war on what the best method is. But just wanted to understand. Or would the cost in time be too high to convert everything?
I prefer the printf() format string way.
Klaus
Klaus Schmidinger wrote:
On 02/19/08 21:26, Ludwig Nussel wrote:
Klaus Schmidinger wrote:
Apparently there are macros for this, like PRId64 and such. But i don't like having to write something like
int64_t n = ...; printf("Some number %" PRId64 "\n", n);
Don't know if the gettext mechanisms would be able to handle
tr("Some number %" PRId64 "\n")I wonder why there ar no proper format specifiers for this. Or are there?
[...] I really hope we can avoid this insanity in VDR...
In this particular case you could change the API to use "long long" instead of "int64_t" since "long long" has eight bytes on the platforms vdr is made for anyways.
Alternatively just ignore the warning. The %LX formats should be changed to %llX though as L is only defined for floating point types.
cu Ludwig
El Sun, 17 Feb 2008 15:46:42 +0100 Klaus Schmidinger Klaus.Schmidinger@cadsoft.de escribió:
Note that you may need to switch back to an older version of your channels.conf file if you have already used version 1.5.14, because it introduced new parameters.
In case there's no older version of channels.conf, is there some simple sed/awk/perl script to remove the extra fields, or is it not strictly necessary? Is it just a 's/M2O0S0//' when you only have dvb-s channels?
Bye
On 02/17/08 21:29, Luca Olivetti wrote:
El Sun, 17 Feb 2008 15:46:42 +0100 Klaus Schmidinger Klaus.Schmidinger@cadsoft.de escribió:
Note that you may need to switch back to an older version of your channels.conf file if you have already used version 1.5.14, because it introduced new parameters.
In case there's no older version of channels.conf, is there some simple sed/awk/perl script to remove the extra fields, or is it not strictly necessary? Is it just a 's/M2O0S0//' when you only have dvb-s channels?
Should be pretty much it.
Klaus
On Mon, 2008-02-18 at 17:57 +0100, Klaus Schmidinger wrote:
On 02/17/08 21:29, Luca Olivetti wrote:
El Sun, 17 Feb 2008 15:46:42 +0100 Klaus Schmidinger Klaus.Schmidinger@cadsoft.de escribió:
Note that you may need to switch back to an older version of your channels.conf file if you have already used version 1.5.14, because it introduced new parameters.
In case there's no older version of channels.conf, is there some simple sed/awk/perl script to remove the extra fields, or is it not strictly necessary? Is it just a 's/M2O0S0//' when you only have dvb-s channels?
Should be pretty much it.
Why not make 1.6.0 ignore this field so it can just work for people who upgrade/downgrade?
Klaus
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
On 02/21/08 14:07, Malcolm Caldwell wrote:
On Mon, 2008-02-18 at 17:57 +0100, Klaus Schmidinger wrote:
On 02/17/08 21:29, Luca Olivetti wrote:
El Sun, 17 Feb 2008 15:46:42 +0100 Klaus Schmidinger Klaus.Schmidinger@cadsoft.de escribió:
Note that you may need to switch back to an older version of your channels.conf file if you have already used version 1.5.14, because it introduced new parameters.
In case there's no older version of channels.conf, is there some simple sed/awk/perl script to remove the extra fields, or is it not strictly necessary? Is it just a 's/M2O0S0//' when you only have dvb-s channels?
Should be pretty much it.
Why not make 1.6.0 ignore this field so it can just work for people who upgrade/downgrade?
I've revoked the entire change to "multiproto" to make a stable 1.6.0 that is based on the current kernel driver version. After that, the multiproto code is going to return in version 1.7.0. I'm not going to make all sorts of "hybrids" ;-).
Klaus
Malcolm Caldwell wrote:
In case there's no older version of channels.conf, is there some simple sed/awk/perl script to remove the extra fields, or is it not strictly necessary? Is it just a 's/M2O0S0//' when you only have dvb-s channels?
Should be pretty much it.
Why not make 1.6.0 ignore this field so it can just work for people who upgrade/downgrade?
... that would be the attached patch. It just ignores the fields added by the temporary 1.5.14 format. When VDR saves the channels.conf next time, the format will be reverted to the 1.5.15 format, dropping the new fields. 1.5.14 and 1.7.x will re-add them anyway.
Cheers,
Udo
--- vdr-1.5.15/channels.c 2008-02-10 16:45:38.000000000 +0100 +++ vdr-1.5.15-patched/channels.c 2008-02-22 19:13:32.000000000 +0100 @@ -624,10 +624,24 @@ return NULL; }
+static const char *DropParseParameter(const char *s) +{ + if (*++s) { + char *p = NULL; + errno = 0; + strtol(s, &p, 10); + if (!errno && p != s) + return p; + } + esyslog("ERROR: invalid value for parameter '%c'", *(s - 1)); + return NULL; +} + bool cChannel::StringToParameters(const char *s) { while (s && *s) { switch (toupper(*s)) { + case 'A': s = DropParseParameter(s); break; case 'B': s = ParseParameter(s, bandwidth, BandwidthValues); break; case 'C': s = ParseParameter(s, coderateH, CoderateValues); break; case 'D': s = ParseParameter(s, coderateL, CoderateValues); break; @@ -636,7 +650,11 @@ case 'I': s = ParseParameter(s, inversion, InversionValues); break; case 'L': polarization = *s++; break; case 'M': s = ParseParameter(s, modulation, ModulationValues); break; + case 'Z': s = DropParseParameter(s); break; + case 'O': s = DropParseParameter(s); break; + case 'P': s = DropParseParameter(s); break; case 'R': polarization = *s++; break; + case 'S': s = DropParseParameter(s); break; case 'T': s = ParseParameter(s, transmission, TransmissionValues); break; case 'V': polarization = *s++; break; case 'Y': s = ParseParameter(s, hierarchy, HierarchyValues); break;
-
Dave P -
Klaus Schmidinger -
Luca Olivetti -
Ludwig Nussel -
Malcolm Caldwell -
michael.mauch＠gmx.de -
Theunis Potgieter -
Udo Richter