vdr-patch-lnbsharing - VDR LNB Sharing patch

Age	Commit message (Collapse)	Author
2007-06-10	Version 1.5.3vdr-1.5.3	Klaus Schmidinger
	- Fixed some spelling errors in 'newplugin' (thanks to Ville Skyttä). - Fixed a busy loop in fast forward if the next video data file is missing (thanks to Reinhard Nissl). - Fixed handling frequencies in NitFilter::Process() (thanks to Anssi Hannula). - Fixed a race condition with signal handlers at program exit (thanks to Udo Richter). - Non-primary devices in Transfer mode are now also used for recording (thanks to Anssi Hannula). - Fixed handling ChannelUp/Down keys if there is currently a replay running (thanks to Marco Schlüßler). - The new SVDRP command REMO can be used to turn VDR's remote control off and on in case other programs need to be controlled (based on patches from Krzysztof Parma and Helmut Auer). - Increased the maximum number of CA system ids to cope with the AlphaCrypt CAM's version 3.11 firmware. - Fixed getting the code setting from the locale (thanks to Matthias Schwarzott). - Implemented support for Freetype fonts (based on a patch from Alexander Riedel). The font names and sizes can be adjusted in the "Setup/OSD" menu. Note that VDR now requires freetype fonts to be installed in /usr/share/fonts/truetype. - If the OSD device in use has at least 8bpp bitmap depth and this is also used by the current skin, Freetype fonts are displayed "anti-aliased". The new setup parameter "OSD/Anti-alias" can be used to turn this off. - The new function cOsd::SetAntiAliasGranularity() can be used to help the OSD in managing the available color palette entries when doing anti-aliasing. Skins that use 8bpp bitmaps can call this function with the maximum number of colors used, and the maximum number of color combinations. The OSD will then evenly split the available palette entries between the various colors combinations, so that fonts can be "anti-aliased". By default a total of 10 colors and 10 combinations is assumed. - The pixel fonts have been completely removed from the VDR source. - VDR is now "UTF-8 aware". It handles strings according to the character encoding used on the user's system. All internationalization strings and incoming SI data are converted to the system encoding. - Plugins that handle strings need to be aware that on systems with UTF-8 encoding a "character symbol" may consist of more than a single byte in memory. The functions and macros named Utf8...() can be used to handle strings without needing to care about the underlying character encoding (see tools.h for details). - Even though the weekdays of repeating timers are presented to the user as UTF-8 characters in the OSD, the timers.conf file and the SVDRP timer commands still use single byte characters ("MTWTFSS") to make sure this information is handled correctly between systems with different character encodings. - Added a missing i18n string for "CAM" in the Turkish OSD texts. - Improved editing strings that are too long to fit into the editable area. - Changes to the OSD settings in the "Setup/OSD" menu now immediately take effect when the "Ok" key is pressed.
2007-04-22	Version 1.5.2vdr-1.5.2	Klaus Schmidinger
	- Updated the Finnish OSD texts (thanks to Rolf Ahrenberg). - Fixed handling user activity for shutdown, which I had messed when adopting Udo's original patch (thanks to Udo Richter). - Added Turkish language texts (thanks to Oktay Yolgeçen). - Added missing rules for generating iso8859-13 font to Makefile. - 'libsi' now converts the incoming strings into the system's character set according to the DVB standard. The system's character set is determined from the LANG environment variable. If no recognizable setting can be found, no conversion will take place. Note that currently only the strings received from the SI data stream are converted, there have not been any changes regarding displaying UTF-8 characters on the OSD, yet - this will follow in one of the next steps. With this conversion, it should now be safe to run VDR on a UTF-8 file system, because all incoming characters are converted to UTF-8. This will most likely result in wrong characters being displayed on the OSD (because there UTF-8 is not known, yet), but the file names should be ok (haven't tested this myself, though, because I don't do UTF-8 - so please be very careful when testing!). There's one piece of bad news here: the German pay-tv broadcaster Premiere apparently encodes all EPG strings as ISO8859-1, but fails to correctly mark these strings as such. Therefore 'libsi' (following the DVB standard) considers the strings to be encoded in the default ISO6937 and converts them to whatever the system's character set is. This, of course, results in wrong umlauts. On its old transponder, the ProSieben/SAT.1 channels also had their EPG data wrongly encoded, but apparently on the new transponder they started broadcasting on this month, they got it right.