[skindesigner] Segfault bei schnellem Scrollen durch Aufnahmen wenn HDD noch nicht aufgewacht ist


  • Das schaue ich mir als Nächstes mal an.

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

  • Beim Üben im Umgang mit esyslog habe ich in epg.c mal paar Meldungen eingebaut:



    Der bt wirft jetzt Folgendes raus:


    Das syslog spricht jetzt bis zum Crash Folgendes:



    Auffällig ist der Wert numComponents der völlig aus der Reihe tanzt.

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

  • Sag ich doch, da liegt was im Argen ...

    Bau doch mal meine Meldungen ein

    Mache ich als Nächstes.

    Es laufen bloß gerade paar Aufnahmen.

    Da spiele ich lieber nicht am System.

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


  • Ich habe beide Meldungen eingebaut.

    Bei einem Test, ohne tvscraper, der zum Absturz führte, sind diese Meldungen nicht im syslog aufgetreten.

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

  • Hi,


    mit dem aktuelle tvscraper 1.1.5 sollte es keinen Absturz mehr geben.

    Falls, doch, poste hier bitte den bt.


    ~ 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 habe in skindesigner die problematischen Funktionen deaktiviert und noch einmal mit tvscraper getestet.

    Damit kein Absturz jedoch auch keine der eingebauten Meldungen...


    Danke MarkusE


    Ich werde Versuchen, den Code zu verstehen und dem Problem mit dem skindesigner auf die Spur zu kommen...

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

    The post was edited 1 time, last by heifisch ().

  • heifisch ,


    kannst Du bitte mal den beigefügten Patch für skindesigner bei Dir einspielen und schauen, ob es dann noch an der gleichen Stelle abstürzt.

    Durch den Patch wird die Funktion "RecordingIsHD()" etwas umgebaut, so das hier während des Aufrufes von "cComponents" ein LOCK_RECORDINGS_READ gehalten wird. Somit sollte zumindest die betroffene Recording während der Wartezeit nicht mehr verschwinden. Vielleicht bringt uns das ja etwas weiter oder bringt eine bessere Fehlermeldung.


    Die anderen Abfragen sind von dem Patch nicht betroffen.


    Grüße

    kamel5


  • Mache ich, dauert nur ein wenig.


    Bezüglich der <optimized out> Meldungen im bt wollte ich mal wissen was da stehen würde und habe gemäß dem mal die Optimierungs-Flags von -O2 auf -O0 gesetzt.

    Damit konnte ich aber den Absturz nicht reproduzieren.


    Dabei ist mir aufgefallen, dass die Flags in meinem System nicht so gesetzt waren, wie ich es eigentlich wollte.

    Ich baue gerade mein System neu mit folgenden Flags:

    Code
    1. -march=native -O2 -pipe -ftree-vectorize -fomit-frame-pointer


    Ich hoffe, dass ich im Anschluss den Absturz reproduzieren kann um dann zu testen, ob Dein Patch hilft das Problem zu beseitigen.

    Im Notfall muss ich die relevanten Sachen mit den alten Flags noch mal bauen...


    Ich melde mich wenn ich neue Erkenntnisse habe.


    Vielen Dank und Gruß

    Heiko

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

  • Ich melde mich wenn ich neue Erkenntnisse habe.

    Wenn Du das dann testest, kannst Du bitte mal noch folgendes prüfen:

    Wenn im Aufzeichnungsmenü eine Aufnahme markiert ist und die Platte nicht läuft, mal mit der blauen Taste die Info-Seite aufrufen. Gibt es dann auch einen Absturz? Dabei werden die gleichen Funktionen benutzt.


    Grüße

    kamel5

    VDR 2.6.1: ASUS Prime X470-PRO, Ryzen 7 2700, 64GB, 6TB HD, GT1030, Fedora 36 Kernel 6.0 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

  • Wenn Du das dann testest, kannst Du bitte mal noch folgendes prüfen:

    Wenn im Aufzeichnungsmenü eine Aufnahme markiert ist und die Platte nicht läuft, mal mit der blauen Taste die Info-Seite aufrufen. Gibt es dann auch einen Absturz? Dabei werden die gleichen Funktionen benutzt.


    Erstmal hierzu:

    Nach der Kompilier-Orgie konnte ich die Abstürze wieder mit der beschrieben Vorgehensweise reproduzieren.

    - Platte in Standby,

    - Taste rot für Aufnahmemenü und Taste ok um in das Verzeichnis zu kommen an das die HDD gemountet ist,

    - Taste Down gedrückt halten,


    Der Absturz kommt nicht immer und wenn, dann bei verschiedenen Aufnahmen.

    Manchmal nach mehreren Versuchen, kann ich auch durch die gesamte Liste scrollen ohne Absturz.

    Dann muss ich den VDR neu starten oder rebooten.


    Beim Test mit der blauen Taste konnte ich keinen Absturz provozieren.

    Das heißt aber nicht, dass er auf diesem Weg nicht auftreten könnte.

    Hier entsteht ja nicht so viel "Stress" wie beim Scrollen durch die Aufnahme-Liste.


    Lediglich das OSD wird komplett schwarz bis die Platte hoch gelaufen ist und es wird die Info-Seite korrekt angezeigt.

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


  • Mit diesem Patch gibt es keinen Absturz mehr bei der Funktion "RecordingIsHD()".

    Wie erwartet, jedoch in der Funktion "RecordingIsUHD().


    bt:


    Also scheint der Patch das Problem zumindest in der Funktion "RecordingIsHD()" zu lösen.

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

  • Also scheint der Patch das Problem zumindest in der Funktion "RecordingIsHD()" zu lösen.

    Sehr schön.

    Ich habe mir die VDR-Sourcen nochmal angeschaut, und eine mir besser gefallende Lösung gefunden, und noch einige Optimierungen gemacht.

    Damit sollte "RecordingIsHD()" und "RecordingIsUHD()" (ist jetzt zusammengefaßt) wieder gehen.

    "RecordingIsRadio()" habe ich erst einmal auskommentiert, das schaue ich mir später noch an.

    Anbei der neue Patch. Es wäre schön, wenn Du den auch noch Testen und eine Weile beobachten könntest.


    Edit:

    Lediglich das OSD wird komplett schwarz bis die Platte hoch gelaufen ist

    Das wäre das von mir erwartete Verhalten.


    Grüße

    kamel5

  • Sieht gut aus!

    Ich habe jetzt einige Routinen durchgeführt, die vor dem Patch zu einem Absturz führten, jedoch konnte ich damit keinen Absturz mehr provozieren.


    Ich behalte das weiter im Auge.


    Vielen Dank für die schnelle Lösung!


    Gruß

    Heiko

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

  • Ich habe alle 3 Funktionen (RecordingIsHD(), RecordingIsUHD() und RecordingIsRadio()) die anfällig für diesen Absturz waren, zusammengefasst und überarbeitet. Damit sollte alles wieder entsprechend im Skin angezeigt werden.


    Die Änderung habe ich vorerst hier im develop Branch commited:

    gitlab.com/kamel5/skindesigner


    Bitte testen. Wenn sich keine Auffälligkeiten ergeben, werde ich das dann im Oktober in den master Branch übernehmen.


    Grüße

    kamel5

    VDR 2.6.1: ASUS Prime X470-PRO, Ryzen 7 2700, 64GB, 6TB HD, GT1030, Fedora 36 Kernel 6.0 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

  • Die Änderung habe ich vorerst hier im develop Branch commited:

    gitlab.com/kamel5/skindesigner


    Bitte testen. Wenn sich keine Auffälligkeiten ergeben, werde ich das dann im Oktober in den master Branch übernehmen.


    Läuft schon seit gestern Abend...


    Vielen Dank noch mal!


    edit:

    Ich sehe gerade,Du hast noch was dran gemacht?

    Das würde ich heute Abend noch einmal aktualisieren...

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

  • Danke fürs Testen.

    Ich sehe gerade,Du hast noch was dran gemacht?

    Da habe ich nur noch einen Kommentar eingefügt, damit man später noch nachvollziehen kann, warum der LOCK hier länger gehalten wird.

    Da musst Du also nicht unbedingt neu kompilieren.


    Grüße

    kamel5

    VDR 2.6.1: ASUS Prime X470-PRO, Ryzen 7 2700, 64GB, 6TB HD, GT1030, Fedora 36 Kernel 6.0 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

  • Hi,


    Ich bin ja glücklich, dass ihr den Fehler korrigieren konntet. :)

    Auch wenn ich es nicht verstehe. :(

    Wenn VDR die c++ Objekte löscht, hätte es (mit meinem Patch) dafür eigentlich Einträge im Log geben müssen.

    Und wenn VDR die c++ Objeckte nicht löscht, dann ist das Sperren eigentlich nicht notwendig.

    Na ja, vieleicht habe ich ja etwas übersehen, oder VDR löscht die c++ Objekte an einer anderen Stelle ...


    ~ 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 bin ja glücklich, dass ihr den Fehler korrigieren konntet. :)

    Auch wenn ich es nicht verstehe. :(

    Wenn VDR die c++ Objekte löscht, hätte es (mit meinem Patch) dafür eigentlich Einträge im Log geben müssen.

    Und wenn VDR die c++ Objeckte nicht löscht, dann ist das Sperren eigentlich nicht notwendig.

    Na ja, vieleicht habe ich ja etwas übersehen, oder VDR löscht die c++ Objekte an einer anderen Stelle ...


    Soll ich da noch einmal in die Spur gehen?

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

  • Wenn VDR die c++ Objekte löscht, hätte es (mit meinem Patch) dafür eigentlich Einträge im Log geben müssen.

    Den Patch habe ich bei mir auch mal benutzt und auch Einträge gesehen, allerdings erst nach längerer Zeit, da sollte die Platte schon längst hochgefahren sein. Das kann also nicht wirklich die Ursache sein.

    Na ja, vieleicht habe ich ja etwas übersehen, oder VDR löscht die c++ Objekte an einer anderen Stelle ...

    Vielleicht gibt es aber auch noch einen Bug in der ganzen Kette...


    Ja, befriedigend ist die Situation nicht.

    Seltsam ist, das es nur in der Aufzeichnungsliste aufgetreten ist und nicht in der Detailansicht, obwohl dort die selben Funktionen benutzt wurden. Der Unterschied liegt darin, das, in der Detailansicht, nur eine einzige Aufnahme benutzt wird, und in der Liste mehrere Aufnahmen ohne Wartezeit quasi parallel "aktiv" sind. Den eigentlich hätte, nach dem ersten Tastendruck, auch hier der VDR warten müssen, bis die HDD hochgefahren ist.

    Timing Problem???

    Ich denke, das der zusätzliche LOCK hier die richtige Lösung ist, den dann wird auch die Reihenfolge trotz Wartezeit sichergestellt.

    Soll ich da noch einmal in die Spur gehen?

    Du könntest mal probieren, ob der VDR mit Patch jetzt nach dem ersten Tastendruck wartet, bis die Platte hochgefahren ist.

    Alles Andere wäre für mich im Moment Fleißarbeit.:)


    Grüße

    kamel5

    VDR 2.6.1: ASUS Prime X470-PRO, Ryzen 7 2700, 64GB, 6TB HD, GT1030, Fedora 36 Kernel 6.0 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5