[ANNOUNCE] VDR Version 2.6.5 freigegeben - VDR Portal (2024)

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=snapshot;h=refs/tags/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 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.

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

Guten Rutsch und Merci vielmals

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

guten rutsch und ein frohes neues jahr

beinhart

Ich es mal für yaVDR paketiert: https://launchpad.net/~seahawk…+archive/ubuntu/vdr-2.6.5

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.

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

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

Zitat von 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?

Zitat von 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)

Alles anzeigen

'man cp' liefert bei mir (openSUSE 15.3)

 -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.

Zitat von 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.

Zitat von 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?

Zitat von 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.

#62572 - cp --no-clobber behavior has changed - GNU bug report logs

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:

@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.

Zitat von 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.

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...