[ANNOUNCE] VDR Version 2.6.5 freigegeben

kls · December 30, 2023 at 3:32 PM

Allen VDR-Benutzern einen guten Rutsch ins neue Jahr!

VDR version 2.6.5 is now available at the official VDR GIT archive

git://git.tvdr.de

You can also get the latest stable version with

git clone --branch stable/2.6 git://git.tvdr.de/vdr.git

or as a tar archive with

http://git.tvdr.de/?p=vdr.git;a=s…s/2.6.5;sf=tbz2

The changes since version 2.6.4:

- Fixed broken video data streams on systems without output device when switching live

channel to a different transponder while recording (reported by Markus Ehrnsperger).

- The frame width, height, scan type and apect ratio of a recording are now stored in

the 'info' file under the 'F' tag (thanks to Christoph Haubrich).

- Added the function cRecordingInfo::FrameParams(), which can be used to get a nicely

formatted string with all the available frame data.

- The recording info of the default skins now shows the frame parameters of the

recording at the end of the description (if such information is available).

Homepage: http://www.tvdr.de

Facebook: https://www.facebook.com/VideoDiskRecorder

Have fun!

Klaus

jojo61 · December 30, 2023 at 3:40 PM

Schade das du die Skalierfunktionen für das OSD nicht mitgenommen hast.

kls · December 30, 2023 at 3:53 PM

jojo61 Sorry, hatte ich übersehen.

Solche Patches solltet ihr mir am besten immer direkt per Email schicken, denn ich schaue nur spärlich ins VDR-Portal rein und merke mir nicht immer alles, was da an Patches diskutiert wird.

rell · December 30, 2023 at 4:12 PM

kls Ich schick ihn dir per Mail.

MarkusE · December 30, 2023 at 7:59 PM

Ich habe auch noch 3 Patches geschickt ...

highrgb · December 31, 2023 at 9:50 AM

Danke für die Version, läuft auf dem Wohnzimmerrechner!

Guten Rutsch und Merci vielmals

beinhart · December 31, 2023 at 9:55 AM

ein grosses dankeschoen von mir. laeuft bereits auf dem server seit gestern abend

guten rutsch und ein frohes neues jahr

beinhart

seahawk1986 · January 1, 2024 at 1:34 PM

Ich es mal für yaVDR paketiert: https://launchpad.net/~seahawk1986-h…buntu/vdr-2.6.5

nobanzai · January 2, 2024 at 7:27 PM

Das Makefile funktioniert bei mir leider schon seit Anfang der 2.6er Versionen für den install nicht.

In Zeile 303 geht der "cp -pn" schief, wenn es die .conf Files schon gibt.

Das ist ein openSUSE Tumbleweed, das bereits die neuen coreutils-9.4-2.2.x86_64 enthält.

Bei denen gilt, dass der cp -n mit Feler zurück kommt für den Fall, dass die Zieldatei schon existiert - und das ist ja ab dem 2. Install immer der Fall.

kls: Kannst du das im Makefile anpassen?

Evtl.

Code

@cp --preserve --update=none *.conf $(DESTDIR)$(CONFDIR)

msv · January 2, 2024 at 11:41 PM

Ich habe in der neuen version im Menu als Überschrift immer noch die alte Versionsnummer stehen(2.6.3). Nur in der Überschrift auf der Seite "Einstellungen" wird die neue Versionsnummer 2.6.5 angezeigt. Fehlt da noch was?

Alles andere läuft gut nach dem Update.

mfg

msv

nobanzai · January 2, 2024 at 11:57 PM

Quote from msv

Ich habe in der neuen version im Menu als Überschrift immer noch die alte Versionsnummer stehen(2.6.3). Nur in der Überschrift auf der Seite "Einstellungen" wird die neue Versionsnummer 2.6.5 angezeigt. Fehlt da noch was?

Bei mit steht da überall 2.6.5

Evtl. ein Problem mit einem Skin?

Dr. Seltsam · January 3, 2024 at 12:21 AM

Wahrscheinlich wird vom Skin die plugin API Version angezeigt

MartinKG · January 3, 2024 at 1:51 PM

Wird eigentlich ein Rebuild für die Plugins benötigt, hat sich die APIVERSION geändert?

kfb77 · January 3, 2024 at 1:57 PM

Ja, ist jetzt 2.6.5, siehe hier

kls · January 4, 2024 at 2:42 PM

Quote from nobanzai
Das Makefile funktioniert bei mir leider schon seit Anfang der 2.6er Versionen für den install nicht.
In Zeile 303 geht der "cp -pn" schief, wenn es die .conf Files schon gibt.
Das ist ein openSUSE Tumbleweed, das bereits die neuen coreutils-9.4-2.2.x86_64 enthält.
Bei denen gilt, dass der cp -n mit Feler zurück kommt für den Fall, dass die Zieldatei schon existiert - und das ist ja ab dem 2. Install immer der Fall.
kls: Kannst du das im Makefile anpassen?
Evtl.
Code
@cp --preserve --update=none *.conf $(DESTDIR)$(CONFDIR)
Display More

'man cp' liefert bei mir (openSUSE 15.3)

Code

       -u, --update
              copy only when the SOURCE file is newer than the  destination  file  or
              when the destination file is missing

Von einem "=none" steht da nichts. Ausserdem würde damit (zumindest gemäß dieser man-page) ein bestehendes (vom User verändertes) Config-File ja überschrieben, wenn eine neue VDR-Version ein neueres mitbringt.

nobanzai · January 4, 2024 at 3:43 PM

Quote from kls
'man cp' liefert bei mir (openSUSE 15.3)
Code
       -u, --update
              copy only when the SOURCE file is newer than the  destination  file  or
              when the destination file is missing
Von einem "=none" steht da nichts. Ausserdem würde damit (zumindest gemäß dieser man-page) ein bestehendes (vom User verändertes) Config-File ja überschrieben, wenn eine neue VDR-Version ein neueres mitbringt.

Das --update=none kommt auch erst mit den neueren coreutils.

Und nein, damit würde nix überschrieben. Das Verhalten wäre 1:1 wie beim alten -n.

kls · January 4, 2024 at 4:38 PM

Quote from nobanzai

Das --update=none kommt auch erst mit den neueren coreutils.
Und nein, damit würde nix überschrieben. Das Verhalten wäre 1:1 wie beim alten -n.

Das hieße dann wohl, dass es mit älteren Versionen nicht funktionieren würde?

M-Reimer · January 4, 2024 at 4:46 PM

Quote from nobanzai

Das --update=none kommt auch erst mit den neueren coreutils.
Und nein, damit würde nix überschrieben. Das Verhalten wäre 1:1 wie beim alten -n.

Ich musste jetzt auch erstmal ne Weile suchen aber ja: "--update=none" ist wohl extra eingeführt worden um das Verhalten von "-n" wieder zu bekommen.

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=62572

Ich hab's ausprobiert und das Kopieren an sich läuft sauber. "cp" macht also noch was man von ihm erwartet. Um hier jetzt nicht potentiell inkompatible Änderungen zu machen (eigentlich scheint nur der Exit-Code jetzt ein anderer zu sein) würde ich persönlich folgendes einbauen:

Code

@cp -pn *.conf $(DESTDIR)$(CONFDIR) || true

Ich habe gerade keine Testplattform dafür, aber ich könnte mir vorstellen das bei einem älteren coreutils das "--update=none" dann mit Fehler quittiert wird.

nobanzai · January 4, 2024 at 5:48 PM

Quote from M-Reimer
[...]
Ich hab's ausprobiert und das Kopieren an sich läuft sauber. "cp" macht also noch was man von ihm erwartet. Um hier jetzt nicht potentiell inkompatible Änderungen zu machen (eigentlich scheint nur der Exit-Code jetzt ein anderer zu sein) würde ich persönlich folgendes einbauen:
Code
@cp -pn *.conf $(DESTDIR)$(CONFDIR) || true
Ich habe gerade keine Testplattform dafür, aber ich könnte mir vorstellen das bei einem älteren coreutils das "--update=none" dann mit Fehler quittiert wird.

Ja, das ist eine gute Idee mit dem "true".

+1

Und ja, das --update=none gibt Fehler mit älteren coreutils.

kls · January 4, 2024 at 10:01 PM

Den '@' davorzusetzen ist wohl die beste Lösung.

Den Return-Wert eines Befehls, den es schon seit Ewigkeiten gibt, zu ändern und damit potentiell massenhaft Scripte kaputtzumachen auf eine Weise, die vielleicht sogar lange unbemerkt bleibt, zeugt von erheblicher Chuzpe. Ich hoffe mal, das fliegt ihnen gehörig um die Ohren...

[ANNOUNCE] VDR Version 2.6.5 freigegeben

Participate now!

Users Viewing This Thread