ZitatAlles anzeigenVDR version 2.0.6 is now available at
ftp://ftp.tvdr.de/vdr/vdr-2.0.6.tar.bz2
A 'diff' against the previous version is available at
ftp://ftp.tvdr.de/vdr/Developer/vdr-2.0.5-2.0.6.diff
MD5 checksums:
f6916524c302f3209fd0af507ab97387 vdr-2.0.6.tar.bz2
a190a9b3a114cbe7b49e6b5687ea0576 vdr-2.0.5-2.0.6.diff
This version fixes a few minor bugs that came up after the release of
version 2.0.5.
The changes since version 2.0.5:
- Updated 'sources.conf' (thanks to Antti Hartikainen).
- cFont::CreateFont() now returns a dummy font in case there are no fonts installed.
This prevents a crash with the LCARS skin on a system that has no fonts.
- Fixed detecting frame borders in MPEG-2 streams that have "bottom fields" or varying
GOP structures (reported by Christian Paulick, with help from Helmut Auer).
- Fixed a wrong alignment in cCiDateTime::SendDateTime().
- Now checking whether the primary device actually has a decoder before retuning the
current channel after a change in its parameters. This fixes broken recordings on
the primary device on "headless" systems.
- Increased MIN_TS_PACKETS_FOR_FRAME_DETECTOR to 100 and introduced counting the number
of actual video TS packets in cTsPayload in order to be able to record channels that
sometimes need even more than 10 TS packets for detecting frame borders (reported by
Eike Sauer and Oliver Endriss).
- Fixed sorting recordings by time in the Recordings menu if "Setup/OSD/Recording
directories" is set to "no".
- Fixed clearing non-editable members in the channel editor (thanks to Rolf Ahrenberg).
- Fixed flickering if subtitles are active while the OSD demo is running.
- Fixed a possible crash in the OSD demo (reported by Christopher Reimer).
- Fixed learning keyboard remote control codes (thanks to Lars Hanisch).
- Fixed the replay progress display for very long recordings.
- Improved PAT/PMT scanning to speed up initial tuning to encrypted channels on
transponders with many PAT entries (reported by Mariusz Bialonczyk).
- Fixed detecting broken video data streams when recording.
- Fixed handling frame detection buffer length (reported by Eike Sauer).
- Fixed keeping the current position in the Recordings menu if a recording was
deleted in a sub folder.
- Fixed handling transfer mode on full featured DVB cards for encrypted channels
that have no audio pid (reported by Christian Winkler).
- Fixed a possible endless loop in cH264Parser::GetGolombUe(), which caused recordings
on some HD channels to get stuck and resulted in buffer overflows.
- Fixed handling PAT packets when detecting frames, so that they can be properly
taken into account when regenerating the index of a recording.
- Fixed adding new source types in case they are already registered (reported by Rolf
Ahrenberg).
- Fixed drawing the live indicator in the LCARS skin in case there are no devices.
- The SDT is now only parsed *after* the NIT has been read, and it explicitly uses
the source value derived from the NIT. This should prevent new channels from being
created with the wrong source.
- Now initializing the isOnVideoDirectoryFileSystem member of cRecording when
scanning the video directory, so that it won't cause a delay when opening the menu
on a system with a large number of recordings.
- The APIVERSION has been increased to 2.0.6 due to the changes to pat.h, sdt.h and
the functional modification to cFont::CreateFont().
Have fun!
Klaus
[vdr] [ANNOUNCE] VDR version 2.0.6 released
- Dirk
- Geschlossen
-
-
-
Danke für die neue Version.
Zitat von Klaus- The APIVERSION has been increased to 2.0.6 due to the changes to pat.h, sdt.h and
the functional modification to cFont::CreateFont().Ohh Ohh. Wenn mir das mal keinen Ärger bereitet. Ich befürchte Konflikte mit den pkgrels. Naja nichts, was sich nicht umgehen und fixen lässt.
-
Danke für die neue Version.
Ohh Ohh. Wenn mir das mal keinen Ärger bereitet. Ich befürchte Konflikte mit den pkgrels. Naja nichts, was sich nicht umgehen und fixen lässt.
Das verstehe ich jetzt nicht. Genau für solche Fälle wurde doch die APIVERSION mal eingeführt.
Wenn das nicht gewünscht ist, dann können wir die auch jederzeit herzlich gerne wieder abschaffen. ich hätte da überhaupt nichts dagegen, denn ich war damals schon kein Fan ihrer Einführung...Klaus
-
Nein. So schlimm wie erwartet war das gar nicht.
In Arch Linux paketiere ich sowohl 2.1.x als auch 2.0.x. Es war nur eine kleine Herausforderung beide Repositories konsistent zu halten.
Die Paketdateinamen haben nämlich keine Unterscheidung auser die pkgrelWenn also in VDR4Arch-Stable vdr-aaa-1.0-1-x86_64.pkg.tar.xz (gegen 2.0.x kompiliert) liegt liegt in VDR4Arch-Next vdr-aaa-1.0-2-x86_64.pkg.tar.xz (gegen 2.1.x kompiliert)
Ich musste jetzt nur sicherstellen, dass in Next alle pkgrels mindestens 1 höher sind als die in Stable.Das habe ich jetzt auch fertig. War weniger Aufwand, als ursprünglich befürchtet.
-
Bei Debian/Ubuntu ist das kein Problem, alle Pakete bekommen eine Abhängigkeit vom virtuellen vdr-abi-Paket. Somit kann man kein Plugin installieren, das gegen einen anderen vdr gebaut wurde (wenn der Maintainer für die Pflege der abi-version sorgt, hab ich auch nicht immer auf der Reihe).
Ich würde es also schön finden, wenn die drin bliebe.Lars.
-
Nein die APIVERSION sollte schon bleiben. Diese Abhängigkeit zur API habe ich auch. Das Problem liegt woanders. Ich möchte das Paketsystem von Arch Linux jetzt aber nicht ausbreiten.
Es ist gelöst und alle sind zufrieden
-
[,,,] Wenn das nicht gewünscht ist, dann können wir die auch jederzeit herzlich gerne wieder abschaffen. ...
Und am besten das neue Buildsystem auch gleich mit entsorgen. -
Und am besten das neue Buildsystem auch gleich mit entsorgen.
Wird das nicht langsam langweilig?
Jetzt mitmachen!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!