[ANNOUNCE] VDR Version 2.6.5 freigegeben

    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

    kls Ich schick ihn dir per Mail.

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

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Danke 7 Gefällt mir 1

    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)

    Einmal editiert, zuletzt von nobanzai ()

    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?

    Wahrscheinlich wird vom Skin die plugin API Version angezeigt

    VDR1: ACT-620, Asus P8B75-M LX, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

    VDR2: Odroid N2+ mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    VDR3: Tanix TX3 mit CoreELEC und Ubuntu in chroot, WinTV DualHD

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

    Gruß MartinKG

    Fedora37 kernel-6.1.6-200.fc37.x86_64 Gnome Desktop vdr 2.6.1 mit vdr-softhddevice plugin.

    ViewSonic VX3276 HDMI-1 <------------> HDMI NVidia Geforce-gt-1030

    ViewSonic VX3276 HDMI-2 <------------> HDMI Technotrend S2-6400

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

    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.

    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:


    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.

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

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden