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

  • Hallo.


    ich habe hier einen reproduzierbaren Segfault mit Skindesigner wenn man mit dauerhaft gedrückter "down"-Taste durch die Aufnahmen scrollt wenn die HDD noch nicht aufgewacht ist.

    Mit LCARS konnte ich dieses Verhalten nicht beobachten.

    bt:


    Gruß und Danke

    Heiko

    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

  • Hallo,

    wenn die HDD noch nicht aufgewacht ist.

    Das ist schon seltsam, eigentlich sollte kein HDD-Zugriff nötig sein für die Anzeige der Aufzeichnungsliste.


    Aus dem Backtrace kann ich im Moment nichts Problematisches ableiten, pbrb hast Du eventuell eine Idee dazu, oder auch jemand Anderes...


    heifisch , noch einige Fragen:

    - welche skindesigner-Version und welchen Skin nutzt Du?

    - hast Du Animationen im Skin an, dann diese bitte ausschalten (alle Zeiten auf 0 stellen) und testen, ob es dann auch auftritt.


    Im Moment habe ich also keine schnelle Lösung, und richtig Zeit habe ich auch erst wieder ab Oktober.

    Dann müsste ich mal sehen, ob ich das hier reproduzierbar machen kann.


    Grüße

    kamel5

    VDR 2.6.6: ASUS Prime X470-PRO, Ryzen 7 5700X, 64GB, 6TB HD, GT1030, Fedora 39 Kernel 6.8 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

  • Hallo kamel5.


    Danke erst mal für die schnelle Antwort.

    heifisch , noch einige Fragen:

    - welche skindesigner-Version und welchen Skin nutzt Du?

    - hast Du Animationen im Skin an, dann diese bitte ausschalten (alle Zeiten auf 0 stellen) und testen, ob es dann auch auftritt


    Zur Version:

    Code
    commit 79a95914f0cc2789238f5fc3e96a9a61201bc0e0 (HEAD -> master, tag: 1.2.18, origin/master, origin/develop, origin/HEAD)
    Author: kamel5 <vdr.kamel5 (at) gmx (dot) net>
    Date:   Wed Feb 9 13:55:34 2022 +0100
    
        Version 1.2.18


    Der Skin ist estuary4vdr.


    Das mit den Animationen muss ich mir noch genau ansehen, wenn ich am Gerät bin

    Die aktuellen Einstellungen sind diese, falls Du die meintest?



    Reproduzieren konnte ich es, indem ich die Platte mit hdparm -y /dev/*** in den Schlaf gelegt habe und im Anschluss mit der Taste "rot" auf Aufnahmen und mit gedrückt gehaltener "down"-Taste durch die Aufnahmen gescrollt habe. Wenn die Platte nicht schläft, konnte ich bei den wenigen Versuchen mit gleicher Vorgehensweise, den Segfault nicht provozieren.


    Gruß

    Heiko

    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

  • Die Einstellungen habe ich noch nicht geändert!

    Aber, jetzt habe ich doch noch mal alle Symbole und Sourcen da und der bt ist noch etwas aussagekräftiger:



    Da macht spielt wohl tvscraper noch mit rein...

    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

  • Mit Einfahr- und Überblendzeit 0 bekomme ich aber wieder einen Segfault wie oben:

    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

  • Suche doch mal im Syslog nach:


    tvscraper: ERROR: csRecording::csRecording


    und poste diese Zeile, wenn sie im Syslog auftaucht.


    ~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

  • Code
    Aug 31 18:16:23 vdr vdr[2913]: [3880] tvscraper: ERROR: csRecording::csRecording !recording->Info()->GetEvent()

    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

  • recording->Info()->GetEvent() == NULL.


    Hätte nicht gedacht, dass das passieren kann.

    Habe mal in den Code von VDR / recording.c geschaut, und der constructor von cRecordingInfo legt immer ein neues Event an, falls keines übergeben wird. Oder habe ich da etwas übersehen?


    Ich werde das in tvscraper abfangen, das kann aber zu allen möglichen (anderen) seltsamen Fehlern führen ...


    Edit: da wurde doch nicht etwa erst ein

    delete recording

    aufgerufen, und danach dieses recording Objekt noch verwendet?

    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

  • Edit: da wurde doch nicht etwa erst ein

    delete recording

    aufgerufen, und danach dieses recording Objekt noch verwendet?


    Ich hatte den VDR vor den Tests frisch gestartet.

    Heute Nachmittag hatte ich eine Aufnahme gelöscht die ich mit den Spielereien versaut hatte.

    Aber laut log sollte diese schon gelöscht worden sein.


    Code
    Aug 31 14:02:25 vdr vdr[2912]: [3410] removing /video/Die_Olsenbande_und_ihr_großer_Coup
    Aug 31 14:02:25 vdr vdr[2912]: [3410] remove deleted recordings thread ended (pid=2912, tid=3410)

    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

  • Hallo Heiko,


    Verstehe ich nicht.

    • Die HD mit den Aufnahmen "schläft" noch
    • Du startest VDR
    • Die HD mit den Aufnahmen "schläft" immer noch
    • Du scrollst durch die Aufnahmen

    Moment: Woher hat der VDR die Aufnahmen, wenn die HD mit den Aufnahmen noch "schläft"?

    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

    • Die HD mit den Aufnahmen "schläft" noch
    • Du startest VDR
    • Die HD mit den Aufnahmen "schläft" immer noch
    • Du scrollst durch die Aufnahmen

    Moment: Woher hat der VDR die Aufnahmen, wenn die HD mit den Aufnahmen noch "schläft"?

    Nein, so natürlich nicht...

    Wenn VDR gestartet wird läuft die Platte natürlich, damit er die Aufnahmen einlesen kann.


    Die Segfaults beim Scrollen durch die Aufnahmen sind mir schon früher passiert.

    Mir ist nur der mögliche Zusammenhang mit der schlafenden Platte jetzt erst aufgefallen.


    Also bei mir ist /video eine SSD wo erst mal alle Aufnahmen landen.

    Auf /video/videos habe ich die HDD gemountet die sich in der Regel nach 10min Inaktivität schlafen legt.

    Dies wird mit hdparm -S 120 /dev/... geregelt.


    Um den Fehler zu reproduzieren, habe ich die Platte nach dem Start des VDR und nachdem er die Aufnahmen eingelesen hat mit hdparm -y /dev/... schlafen gelegt oder gewartet bis die 10 Minuten um sind und die Platte sich von alleine schlafen legt.


    Dann erst habe ich durch die Aufnahme-Liste gescrollt.

    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

  • Was macht VDR, wenn er ein cRecording recording hat. Und dann versucht, auf dieses recording auf der Platte zuzugreifen. Und dann scheitert, weil die Platte schläft ...

    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

  • Was macht VDR, wenn er ein cRecording recording hat. Und dann versucht, auf dieses recording auf der Platte zuzugreifen. Und dann scheitert, weil die Platte schläft ...


    Da fehlt mir das Verständnis um diese Frage zu beantworten.


    Aber wenn ich eine Aufnahme von der HDD ansehe und die Aufnahme so lange pausiere bis die Platte eingeschlafen ist, dann die Aufnahme weiter schaue, spielt es noch (wahrscheinlich) den Puffer ab, hält kurz an bis die Platte wieder aufgewacht ist und spielt die Aufnahme dann weiter ab.


    Beantwortet das Deine Frage?

    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

  • Ich habe leider keine Erfahrung mit dem lesen des bt und noch weniger mit C /C++, aber versuche mal die relevanten Teile zusammen zu suchen.

    Zumindest für den 1. Absturz von hier. So wie ich es verstehe, geht es um die Erkennung, ob die Aufnahme HD ist. Dazu wird auf die info-Datei zugegriffen.


    Knallt es, weil cComponents::GetComponent NULL zurück gibt?

    Code
    #0  0x000056141b74761c in cComponents::GetComponent(int, unsigned char, unsigned char) (this=this@entry=0x56141d60dfc0, Index=Index@entry=0, Stream=Stream@entry=9 '\t', Type=Type@entry=0 '\000') at epg.c:100
            i = 0
    #1  0x00007f5ea4ce781c in RecordingIsHD(cEvent const*, tChannelID) (event=event@entry=0x56141d60e720, channelID=...) at coreengine/viewelement.c:604
            Component = <optimized out>
            Components = 0x56141d60dfc0
            isHD = false
            type = -1

    skindesigner coreengine/viewelement.c:



    VDR epg.c:

    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

  • Knallt es, weil cComponents::GetComponent NULL zurück gibt?

    Eigentlich nicht, denn NULL wird bei allen Abfrage abgefangen.


    Das Ganze ist schon recht undurchsichtig. Ich müsste mir dazu mal ein Testsystem aufsetzen, das die HD-Abschaltung nachstellt, das geht leider mit meinem aktuellen System nicht. Dazu komme ich aber frühestens im Oktober nach meinem Urlaub.


    Wenn Du selber kompilieren kannst, könntest Du mal folgendes probieren, in skindesigner coreengine/viewelement.c:

    Code
    bool RecordingIsHD(const cEvent* event, const tChannelID channelID) {
        // detect HD from 'info'
        bool isHD = false;
        int type = -1;
        return isHD;           <--- das einfügen

    dann wird dieser Teil gar nicht benutzt, und schauen ob es dann auch abstürtzt.


    Grüße

    kamel5

    VDR 2.6.6: ASUS Prime X470-PRO, Ryzen 7 5700X, 64GB, 6TB HD, GT1030, Fedora 39 Kernel 6.8 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

  • Hallo kamel5.

    Wenn Du selber kompilieren kannst, könntest Du mal folgendes probieren, in skindesigner coreengine/viewelement.c:

    Code
    bool RecordingIsHD(const cEvent* event, const tChannelID channelID) {
        // detect HD from 'info'
        bool isHD = false;
        int type = -1;
        return isHD;           <--- das einfügen

    dann wird dieser Teil gar nicht benutzt, und schauen ob es dann auch abstürtzt.

    Klar kompilieren, patchen, editieren... alles kein Problem.

    Nur das Verstehen... :/


    Also das Teste ich mal und werde berichten.


    Gruß und Danke und schönen Urlaub

    Heiko

    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

  • Hi,


    Es spricht natürlich nichts gegen diesen Patch, du wirst den Fehler damit aber nicht finden.

    Im tvscraper git ist auch eine Korrektur, die dazu führt, dass tvscraper nicht mehr abstürzt. Ist aber auch nicht der eigentliche Fehler.


    Du kannst mal im syslog nach "ERROR:" suchen, ev. findest Du da etwas relevantes.

    Du kannst VDR patchen: in recordings.c

    Code
    for (cRecording *Recording = recordings->First(); Recording; ) {
             cRecording *r = Recording;
             Recording = recordings->Next(Recording);
             if (access(r->FileName(), F_OK) != 0)
                recordings->Del(r);
             }

    Hier vor

    Code
    recordings->Del(r);

    Die Ausgabe einer Meldung im syslog einbauen. Z.B.:

    Code
    esyslog("Delete recording %s", r->Name() );

    Und dann im syslog nach "Delete recording" suchen.

    Ev. dann noch in tools.c, in

    vor "delete Object" ein

    Code
    esyslog("Delete garbage collector object");

    ~ 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

  • Es spricht natürlich nichts gegen diesen Patch, du wirst den Fehler damit aber nicht finden.

    Ist schon klar. Interessant wäre halt, ob der Fehler dann immer noch auftritt, dann wüsste man zumindest, ob es damit zu tun hat.


    Grüße

    kamel5

    VDR 2.6.6: ASUS Prime X470-PRO, Ryzen 7 5700X, 64GB, 6TB HD, GT1030, Fedora 39 Kernel 6.8 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

  • Wenn Du selber kompilieren kannst, könntest Du mal folgendes probieren, in skindesigner coreengine/viewelement.c:

    Code
    bool RecordingIsHD(const cEvent* event, const tChannelID channelID) {
        // detect HD from 'info'
        bool isHD = false;
        int type = -1;
        return isHD;           <--- das einfügen

    dann wird dieser Teil gar nicht benutzt, und schauen ob es dann auch abstürtzt.


    Dann fliegt er beim IsUHD-Test auf die Nase...



    Also da noch mal das selbe Spiel... und er fliegt beim isRadio auf die Nase...



    Nachdem ich isRadio auch deaktiviert habe, keinen Absturz mehr.

    Beim Scrollen dreht die Platte wieder hoch aber keine Probleme.


    Bei diesen Tests habe ich tvscraper als Plugin nicht geladen.


    Also kann man schon sagen, das diese Abstürze mit diesen Checks irgend wie zusammenhängen.

    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

Jetzt mitmachen!

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