VDR developer version 1.7.34 is now available at
ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.34.tar.bz2
A 'diff' against the previous version is available at
ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.33-1.7.34.diff
and a helper patch for plugin Makefiles can be found at
ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.33-pluginmakefile.diff
MD5 checksums:
55d9aba62563efe39ee040e987f7023c vdr-1.7.34.tar.bz2 019ba806b263f7054dbd0da8956ea73b vdr-1.7.33-1.7.34.diff 6c2b8efe5eead6822f006bc867ccb324 vdr-1.7.33-pluginmakefile.diff
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.
IMPORTANT: ==========
This version comes with revised versions of the Makefiles for VDR itself and all of its standard plugins. As a result of this, existing plugins will no longer build with this version of VDR, unless their Makefiles are properly adapted. To do so, please follow the instructions given below. There is also a generic patch (see below) that might help you update your plugin's Makefile. If you do want to build this version of VDR with plugins that don't have their Makefiles adapted yet, you can simply copy the Makefile, Make.global and Make.config (if applicable) files from a previous version of VDR into this source and use them. Note, though, that you cannot mix old and new Makefiles. All Makefiles for VDR and all plugins must be either old or new! PLEASE GIVE THE PLUGIN DEVELOPERS SOME TIME TO ADAPT THEIR MAKEFILES ACCORDINGLY. AFTER ALL, IT'S CHRISTMAS, SO THEY PROBABLY HAVE BETTER THINGS TO DO THAN SIT AT THEIR COMPUTERS ;-).
The changes since version 1.7.33:
- Changed the type of the TimerMatch parameter in cSkinDisplayMenu::SetItemEvent() from 'int' to 'eTimerEvent' (reported by Christoph Haubrich). - Updated the Estonian OSD texts (thanks to Arthur Konovalov). - Fixed cOsd::GetBitmap() to always return NULL if a non-exising area is requested. - Added several missing "`ls $^`" in the calls to xgettext in plugin Makefiles and the "newplugin" script. - Fixed setting the --package-name and --package-version options in the calls to xgettext in several plugin Makefiles. - Added "-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE" to the DEFINES in the Makefile (somehow got lost from Make.config.template in version 1.7.13). - Removed some redundancy in the Makefile/Make.global/Make.config mechanism (suggested by Christopher Reimer). The file Make.global is no longer used, and plugin Makefiles don't include the file Make.config any more. Instead they now retrieve all necessary information through calls to pkg-config. - The plugin Makefiles now have a separate 'install' target (suggested by Christopher Reimer). In order to still allow the normal building of VDR (with all plugins in its ./PLUGINS/src subdirectory, the plugin libraries in ./PLUGINS/lib and the i18n files in ./locale) the VDR Makefile checks the settings of LIBDIR and LOCDIR when building the plugins from within the VDR source directory. If these macros have their default values, then the 'install' targets of the plugins' Makefiles are called. Otherwise the 'all' targets are called and the plugins are merely built, and will have to be installed by a call to 'make install-plugins'. This now also allows a user to copy a plugin source to any directory, change into that directory and do 'make' and 'make install' to have the plugin installed to wherever the local installation of VDR expects them. - Plugin Makefiles now use DESTDIR and the 'install' program (thanks to Christopher Reimer). - Due to the changes to the plugin Makefiles, existing plugins will not build with this version of VDR any more. You can either use the new 'newplugin' script to generate a dummy plugin directory and use the Makefile from there (adapting it to your particular plugin), or apply the patch from ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.33-pluginmakefile.diff to your Makefile to make the necessary changes (see comments in that file for details). - Added the new menu categories mcChannelEdit, mcTimerEdit, mcScheduleNow, mcScheduleNext, mcRecordingInfo, mcPluginSetup, mcSetupOsd, mcSetupEpg, mcSetupDvb, mcSetupLnb, mcSetupCam, mcSetupRecord, mcSetupReplay, mcSetupMisc and mcSetupPlugins. - Updated the Italian OSD texts (thanks to Diego Pierotto). - Fixed replay stuttering close to the end of an ongoing recording (reported by Andreas Regel). - Fixed cIndexFile::GetNextIFrame() to properly handle the case where the very last frame is an I-frame (which normally shouldn't occur). - Fixed replaying ongoing recordings from other VDR instances.
Merry Christmas! Have fun!
Klaus
Hi,
Am 24.12.2012 10:39, schrieb Klaus Schmidinger:
- Removed some redundancy in the Makefile/Make.global/Make.config
mechanism (suggested by Christopher Reimer). The file Make.global is no longer used, and plugin Makefiles don't include the file Make.config any more. Instead they now retrieve all necessary information through calls to pkg-config.
I think it is not a good idea to have no longer a central config file which all parties (plugins and VDR itself) include in their Makefiles.
I'd like to invite you for a discussion about reintroducing a common make configuration file for VDR-1.7.35 in a separate thread named
[DISCUSSION REQUEST] reintroduce a common make configuration file in VDR-1.7.35
Just hold your breath for a few seconds, until that thread appears in the mailing list ;-)
Bye.
Am 24.12.2012 10:39, schrieb Klaus Schmidinger:
- The plugin Makefiles now have a separate 'install' target (suggested by Christopher Reimer). In order to still allow the normal building of VDR (with all plugins in its ./PLUGINS/src subdirectory, the plugin libraries in ./PLUGINS/lib and the i18n files in ./locale) the VDR Makefile checks the settings of LIBDIR and LOCDIR when building the plugins from within the VDR source directory. If these macros have their default values, then the 'install' targets of the plugins' Makefiles are called. Otherwise the 'all' targets are called and the plugins are merely built, and will have to be installed by a call to 'make install-plugins'. This now also allows a user to copy a plugin source to any directory, change into that directory and do 'make' and 'make install' to have the plugin installed to wherever the local installation of VDR expects them.
This has a major downside: LIBDIR and LOCDIR have two different meanings: First, the install target for make install, second, the default search path for VDR as long as --lib and --localedir is not specified. There's no way to handle them different.
So either I have a build that expects ./PLUGINS/lib to exist, or I *have* to use make install, that currently creates a total mess. (xineliboutput even tries to write outside of DESTDIR, and luckily fails to write directly to /lib/.)
I'm now (after 6 hours) at the point that I'll probably have to write an own lib and locale collector script that collects what has been in ./locale and ./PLUGINS/lib before, avoiding all the Makefiles, picking the right folders and files (there's no common way to find the .so file in the src folder), renaming them, etc. And I'm starting to think whether staying at VDR-1.7.33 wouldn't be the better solution. (or returning to 1.7.31 where editing recordings doesn't take forever.)
Cheers,
Udo
On 26.12.2012 22:28, Udo Richter wrote:
...(or returning to 1.7.31 where editing recordings doesn't take forever.)
If you want to use your "hardlink cutter" with recent versions of VDR, you could simply patch out the calls to DanglingPacketStripper.Process(), GetPendingPackets() and ptsFixer.Fix() in cCuttingThread::ProcessSequence(). There will be no fixing of timestamps and continuity counters then, but I guess you don't need that, anyway...
Klaus
Am 27.12.2012 14:43, schrieb Klaus Schmidinger:
If you want to use your "hardlink cutter" with recent versions of VDR, you could simply patch out the calls to DanglingPacketStripper.Process(), GetPendingPackets() and ptsFixer.Fix() in cCuttingThread::ProcessSequence(). There will be no fixing of timestamps and continuity counters then, but I guess you don't need that, anyway...
Its probably a bit more tricky than that, as the exact definition of editing marks has changed. (eg. two marks at same place, including the ending GOP, etc.) It needs a proper rewrite from scratch to get at least the old style back, and my time is way to limited.
A pragmatic quick-hack I've thought of was to set up a recording command that launches an old VDR version's command line editing call. It also handles editing marks the old style though.
Cheers,
Udo
On 27.12.2012 18:48, Udo Richter wrote:
Am 27.12.2012 14:43, schrieb Klaus Schmidinger:
If you want to use your "hardlink cutter" with recent versions of VDR, you could simply patch out the calls to DanglingPacketStripper.Process(), GetPendingPackets() and ptsFixer.Fix() in cCuttingThread::ProcessSequence(). There will be no fixing of timestamps and continuity counters then, but I guess you don't need that, anyway...
Its probably a bit more tricky than that, as the exact definition of editing marks has changed. (eg. two marks at same place, including the ending GOP, etc.) It needs a proper rewrite from scratch to get at least the old style back, and my time is way to limited.
I don't see why you would have to even care about this modified handling of marks. This is all taken care for in cCuttingThread::Action(), and cCuttingThread::ProcessSequence() only has to make sure the data from BeginIndex to EndIndex-1 goes into the edited version. Just take a short look at the new code. I'm sure you'll see how the fromMarks handling is now completely separated from the actual data handling.
A pragmatic quick-hack I've thought of was to set up a recording command that launches an old VDR version's command line editing call. It also handles editing marks the old style though.
Whatever suits you best. I was just trying to give some pointers.
Klaus
-
Klaus Schmidinger -
Reinhard Nissl -
Udo Richter