[ANNOUNCE] VDR Version 2.6.6 freigegeben

  • Zu Frage 1, muss ich erst wieder downgraden.


    Zu Frage 2:

    Ohne Live gibt es kein Segfault aber:



    Ein funktionierender MOVR sieht so aus:

    Code
    vdr ~ # svdrpsend MOVR 3275 TEST2
    220 vdr SVDRP VideoDiskRecorder 2.6.6; Mon Jan 29 14:49:03 2024; UTF-8
    250 Recording "%Big Buck Bunny" moved to "TEST2"
    221 vdr closing connection

    Gentoo Linux ~ VDR 2.6.6 ~ DD Octopus NET V2 S2 Max - SAT>IP ~ LENOVO ThinkServer TS200V ~ Intel(R) Core(TM) i5 CPU680@3.60GHz ~ 16GB RAM ~ NVIDIA T400

  • Im git von live ist ein Update. Bitte testen.


    Läuft. :thumbup:


    Beim Verschieben kommt eine Fehlermeldung.

    Beim Löschen wird der Eintrag aus der Liste entfernt.


    Danke!

    Gentoo Linux ~ VDR 2.6.6 ~ DD Octopus NET V2 S2 Max - SAT>IP ~ LENOVO ThinkServer TS200V ~ Intel(R) Core(TM) i5 CPU680@3.60GHz ~ 16GB RAM ~ NVIDIA T400

  • Welche Fehlermeldung gibt es denn da ?

    Ich musste jetzt erstmal zwischen einer Wagenladung von Warnings suchen aber der erste Fehler ist tatsächlich der, der in diesem Issue genannt wird:

    build failure with libplacebo 6.338 · Issue #72 · jojo61/vdr-plugin-softhdcuvid
    softhdcuvid.cpp: In member function ‘void cMenuSetupSoft::Create()’: softhdcuvid.cpp:1156:27: error: ‘pl_named_filters’ was not declared in this scope 1156 |…
    github.com

    Also an der Stelle kein Problem direkt mit VDR 2.6.6 sondern mit libplacebo.

  • Mit der letzten Version von softhdcuvid hat sich das Problem erübrigt. Jetzt ist im AUR wieder alles auf dem Stand von VDR 2.6.5.


    Davon abgesehen das sich wohl irgendwie ein Fehler mit VNSI eingeschlichen hat.

    Vielleicht kann da ja jemand unterstützen.

  • Vielen Dank an Klaus für die neue Version. Ganz enthusiastisch habe ich sie zusammen mit allen von mir genutzten Plugins gleich installiert. Wie immer habe ich vorher mit "make clean" den VDR und alle Plugins zurückgesetzt und anschließend alles sauber "von Scratch" aufgebaut.


    Beim Einschalten bzw. Reboot des Rechners funktioniert alles wunderbar. Doch wenn ich einen VDR-Neustart ausführe (z.B. per "/etc/init.d/vdr restart"), hängt sich der VDR irgendwann beim Einlesen der Aufzeichnungen auf. Mit 2.6.5 passiert das – bei ansonsten gleicher Konfiguration und denselben Plugins – nicht.


    Hat jemand ähnliche Beobachtungen gemacht bzw. eine Idee, woran das liegen könnte?


    Vielen Dank und beste Grüße

    Stefan

    Hardware: Antec NSK2480, Asus P8B75-M LX, Intel Core i5-3570T, 4 GB RAM, NVIDIA GT610, TT-Premium S2-6400, 128 GB SSD, 14 TB HDD, Pioneer BDR-207EBK
    Software: Ubuntu 20.04 LTS mit Kernel 5.15 und VDR 2.6.6 (mit offiziellen und eigenen Patches)
    Plugins: devstatus, dvbhddevice, dvd, dvdswitch, epgsearch, extrecmenu, recsearch, femon, live, markad, mlist, osdteletext, remote, screenshot, skinenigmang, skinnopacity, streamdev, systeminfo, undelete, xineliboutput
    Addons: VDR Convert 0.1.0 (angepasst)

  • Bei mir funktioniert der Restart auf zwei Rechnern problemlos, ich vermute es liegt an Deinem Start-Script.


    vdr-User-# 755 to_h264 chk_r vdr-transcode github

  • Ich habe festgestellt, dass das Einlesen der Aufnahmen von NFS in 2.6.6 sogar besser klappt als vorher - kann Zufall sein, aber trotzdem.

  • > Ich habe festgestellt, dass das Einlesen der Aufnahmen von NFS in 2.6.6 sogar besser klappt als vorher

    Ist auch mein Eindruck. Ich vermute, es liegt an

    Klaus Schmidinger's git trees - vdr.git/commitdiff


    Ist aber bei mir schwer messbar, weil das Einlesen immer unterschiedlich lang dauert.


    ~ Markus

    Client1: ASUS P5QC, Dual Core 3G, Cine S2, Ext. Board von TBE, Xubuntu 20.04, VDR 2.6x

    Client2: RPI3

    Server: RPI4, Sundtek SkyTV Dual 2x

  • shofmann ,

    Kannst Du uns Infos liefern, die bei der Fehlersuche helfen?

    crasht VDR? Dann bräuchten wir den Backtrace.


    Oder reagiert VDR einfach nicht mehr?


    ~ Markus

    Client1: ASUS P5QC, Dual Core 3G, Cine S2, Ext. Board von TBE, Xubuntu 20.04, VDR 2.6x

    Client2: RPI3

    Server: RPI4, Sundtek SkyTV Dual 2x

  • ich vermute es liegt an Deinem Start-Script.

    Das Skript läuft seit Jahren unverändert ohne Probleme. Warum sollte es also gerade jetzt Probleme verursachen? Und mehr als den VDR starten kann es letztlich ja auch nicht.


    Wenn das Programm beim zweiten Mal abstürzt, hätte ich eher eine andere Vermutung: Das Einlesen der Aufzeichnungen dauert beim ersten Mal recht lange, weil Linux alle Dateien von der Platte einlesen muss (erster Zugriff). Beim Neustart sind viele Daten aber im scon Cache und das Einlesen geht viel schneller. Eventuell also eine Race condition?


    MarkusE: Was genau verstehst du unter dem "Backtrace" (syslog?) bzw. wie kann ich diesen gegebenenfalls erzeugen?


    Danke und Grüße

    Stefan

    Hardware: Antec NSK2480, Asus P8B75-M LX, Intel Core i5-3570T, 4 GB RAM, NVIDIA GT610, TT-Premium S2-6400, 128 GB SSD, 14 TB HDD, Pioneer BDR-207EBK
    Software: Ubuntu 20.04 LTS mit Kernel 5.15 und VDR 2.6.6 (mit offiziellen und eigenen Patches)
    Plugins: devstatus, dvbhddevice, dvd, dvdswitch, epgsearch, extrecmenu, recsearch, femon, live, markad, mlist, osdteletext, remote, screenshot, skinenigmang, skinnopacity, streamdev, systeminfo, undelete, xineliboutput
    Addons: VDR Convert 0.1.0 (angepasst)

  • Irgendetwas stimmt mit 2.6.6 nicht.


    Unterschiedliche Plugins crashen mit 2.6.6 mehr oder weniger unerklärlich.


    Gerade eben ein backtrace von einem Plugin namens 'epg2vdr', das bei der Verarbeitung von strings crasht.

    Dann die Probleme im vnsi-server Plugin.

    Angeblich control und remote.


    Irgendeine Änderung in 2.6.6 ist faul, glaube ich.

  • shofmann ,

    Kannst Du uns Infos liefern, die bei der Fehlersuche helfen? Syslog?


    • crasht VDR (mit core dump)?
    • reagiert VDR einfach nicht mehr?


    ~ Markus


    P.S.: backtrace erzeugen ist leider sehr system/distri-Abhängig. Da kann ich keine allgemeine Anleitung geben

    Client1: ASUS P5QC, Dual Core 3G, Cine S2, Ext. Board von TBE, Xubuntu 20.04, VDR 2.6x

    Client2: RPI3

    Server: RPI4, Sundtek SkyTV Dual 2x

  • Ich stolpere in den backtraces (von anderen Usern) öfter über zwei Auffälligkeiten.


    cOsdMenu::ProcessKey

    und

    class cString::<foobar>


    Hat jemand mehr Input/Ideen?

  • MarkusE, anbei erst einmal ein Extrakt aus dem syslog mit den jeweils letzten drei Einträgen vor dem Crash, der praktisch immer nach Einträgen von SkinNopacity erfolgt ist:

    Davor findet sich nichts Interessantes, nur jeweils ellenlange Abfolgen von Zugriffen des Skins auf diverse Logo-Dateien.


    Nach euren letzten Posts scheint sich die Vermutung zu erhärten, dass die Crashes mit der String-Move-Erweiterung zusammenhängen könnten... bei mir eben innerhalb von Nopacity.


    Hat schon mal jemand den dazugehörigen Commit probehalber revertiert, und hat das geholfen?


    Danke & Grüße

    Stefan



    PS: Ich bin leider kein ausgesprochener C++-Guru und habe deshalb mal ein wenig gegoogelt. Wenn ich die folgende Aussage richtig verstanden habe:

    Quote

    Rvalue references support the implementation of move semantics, which can significantly increase the performance of your applications. Move semantics enables you to write code that transfers resources (such as dynamically allocated memory) from one object to another. Move semantics works because it enables transfer of resources from temporary objects: ones that can't be referenced elsewhere in the program.

    ...dürfen keine doppelten Bezüge auf das zu verschiebende Objekt bestehen. Kann das im Kontext des VDR und seiner Plugins denn sichergestellt werden, und könnte das für die Crashes ursächlich sein?


    Oder bin ich mit meinem Gedanken auf einer völlig falschen Spur?

    Hardware: Antec NSK2480, Asus P8B75-M LX, Intel Core i5-3570T, 4 GB RAM, NVIDIA GT610, TT-Premium S2-6400, 128 GB SSD, 14 TB HDD, Pioneer BDR-207EBK
    Software: Ubuntu 20.04 LTS mit Kernel 5.15 und VDR 2.6.6 (mit offiziellen und eigenen Patches)
    Plugins: devstatus, dvbhddevice, dvd, dvdswitch, epgsearch, extrecmenu, recsearch, femon, live, markad, mlist, osdteletext, remote, screenshot, skinenigmang, skinnopacity, streamdev, systeminfo, undelete, xineliboutput
    Addons: VDR Convert 0.1.0 (angepasst)

    Edited 2 times, last by shofmann ().

  • > Feb 4 19:02:42 htpc runvdr: VDR crashed

    In meiner syslog steht da z.B. "Feb 9 12:33:07 rpi4s systemd[1]: Started Process Core Dump (PID 1465162/UID 0).".


    Ist vermutlich das gleiche, ich denke, es kommt zu einem core dump. Dann bräuchten wir den backtrace.


    Und ja, in VDR 2.6.6. ist eine Performanceverbesserung. Wenn das in Plugins zu raceconditions/Fehlern führt, solltet ihr die Fehler in den Plugins fixen. Selbst wenn wir VDR wieder langsamer machen, solche Fehler kommen wieder: Anderer/besserer compiler, schnellerer Rechner, ...


    Kannst Du herausfinden, an welchem Plugin es liegt?

    Tritt der Fehler auch ohne nopacity auf?


    ~ Markus

    Client1: ASUS P5QC, Dual Core 3G, Cine S2, Ext. Board von TBE, Xubuntu 20.04, VDR 2.6x

    Client2: RPI3

    Server: RPI4, Sundtek SkyTV Dual 2x

  • Ich versuche es mal einzugrenzen. Heute werde ich es aber wohl nicht mehr schaffen...

    Hardware: Antec NSK2480, Asus P8B75-M LX, Intel Core i5-3570T, 4 GB RAM, NVIDIA GT610, TT-Premium S2-6400, 128 GB SSD, 14 TB HDD, Pioneer BDR-207EBK
    Software: Ubuntu 20.04 LTS mit Kernel 5.15 und VDR 2.6.6 (mit offiziellen und eigenen Patches)
    Plugins: devstatus, dvbhddevice, dvd, dvdswitch, epgsearch, extrecmenu, recsearch, femon, live, markad, mlist, osdteletext, remote, screenshot, skinenigmang, skinnopacity, streamdev, systeminfo, undelete, xineliboutput
    Addons: VDR Convert 0.1.0 (angepasst)

  • meine zwei Backtraces sind ja im anderen Fred

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!