Posts by heifisch

    - Wenn man eine Aufnahme löscht, dann eine Weile wartet bis VDR die Aufnahme wirklich gelöscht hat, gibt es beim Aktualisieren des Browserfenstern oben eine Fehlermeldung "FEHLER: Kann die Aufnahme nicht finden oder keine Aufnahmen vorhanden." Die restlichen Aufnahmen werden aber angezeigt. Es scheinen die Aufnahmen nicht korrekt aktualisiert zu werden. Das bleibt dann solange stehen, bis man einmal Aufnahmen verläßt und neu aufruft.


    Habe ich auch ab und zu gesehen.

    Konnte aber noch kein Muster erkennen, wann das auftritt.


    - Wenn man versucht eine Aufnahme im Mediaplayer abzuspielen (wie auch beim Anzeigen von Events), wird versucht, den Browser-internen Player zu nutzen, das funktioniert aber auch mit Firefox nicht so richtig -> "No video with supported format and MIME type found". Hier wäre es vielleicht besser, einen externen Mediaplayer, wie VLC, benutzbar zu machen.


    Aufnahmen spiele ich grundsätzlich im VLC ab.

    Das Firefox Add-on "Open in VLC™ media player" hilft gut dabei.


    - Alles was mit Aufnahmen zu tun hat, dauert doch recht lange (mehrere Sek.), hat sicher auch was mit der Menge der Aufnahmen zu tun, aber selbst, wenn ich eine bestimmte Aufnahme löschen, bearbeiten oder anzeigen will, dauert es. Die anderen Menüpunkte sind da deutlich schneller.


    Mit nicht ganz so frischer Hardware, hier ein Thinkpad W500 mit "Intel(R) Core(TM)2 Duo CPU T9600 @ 2.80GHz" muss man bisschen Geduld haben.


    Hier hatte MarkusE darüber schon mal was geschrieben...

    Hallo kamel5 .

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

    Code
    1. bool RecordingIsHD(const cEvent* event, const tChannelID channelID) {
    2. // detect HD from 'info'
    3. bool isHD = false;
    4. int type = -1;
    5. 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

    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
    1. #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
    2. i = 0
    3. #1 0x00007f5ea4ce781c in RecordingIsHD(cEvent const*, tChannelID) (event=event@entry=0x56141d60e720, channelID=...) at coreengine/viewelement.c:604
    4. Component = <optimized out>
    5. Components = 0x56141d60dfc0
    6. isHD = false
    7. type = -1

    skindesigner coreengine/viewelement.c:



    VDR epg.c:

    Sofern Dein Tablet mit Android läuft, hast Du Dir mal VDR-Manager angesehen. Das Bedienkonzept passt dort natürlich besser zur Bedienung auf einem Tablet mit Touch-Bedienung.


    Die wesentlichen Funktionen inkl. Stream abspielen, funktionieren damit recht gut, sogar aus der Ferne über VPN.


    Ich Nutze live ausschließlich auf dem Linux-Laptop mit Firefox und ich kann, abgesehen von den langen Ladezeiten im Aufnahme-Reiter, Deine Probleme so nicht bestätigen.


    Gruß

    Heiko

    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?

    Leider bekomme da nicht viel raus.

    Das hängt hier und ich kann nichts machen:



    Das core-File sollte zumindest von der Zeit des Segfaults her passen:


    Code
    1. vdr ~ # ll /var/lib/vdr/core
    2. 48463491 446548 -rw------- 1 root root 1191378944 31. Aug 21:37 /var/lib/vdr/core


    Naja, muss noch mal bissel forschen...

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

    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
    1. Aug 31 14:02:25 vdr vdr[2912]: [3410] removing /video/Die_Olsenbande_und_ihr_großer_Coup
    2. Aug 31 14:02:25 vdr vdr[2912]: [3410] remove deleted recordings thread ended (pid=2912, tid=3410)

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

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

    Hallo.


    Da ich in der Vergangenheit immer mal einen Segfault hatte, es aber dann nie geschafft habe, wenn gdb lief, diesen zu reproduzieren, habe ich mal geschaut, ob man gdb generell laufen lassen könnte.


    Bei meinen Experimenten bin ich bei folgender Lösung gelandet:

    Umgebung: Gentoo

    Init-System: openrc


    Ich habe mir ein init-Script geschrieben in dem nach dem VDR-Start, eine screen-Sitzung (detached) mit der Ausführung eines Scriptes gestartet wird.

    Das Script startet dann gdb.

    Im Falle eines Segfaults, kann man dann in die Screen-Sitzung wechseln und bt aufrufen.


    vdr ~ # cat /etc/init.d/gdb-vdr


    vdr ~ # cat /usr/local/bin/gdb-vdr

    Shell-Script
    1. #!/bin/bash
    2. screen -ls | grep -oE "[0-9]+\.gdb-vdr" | sed -e "s/\..*$//g" > /var/run/screen-gdb-vdr.pid;
    3. gdb -iex "set pagination off" -q -ex cont -p $(pidof vdr);


    Mit folgenden Befehl, kann man dann in die Screen-Sitzung wechseln.

    Code
    1. vdr ~ # screen -x gdb-vdr



    Schönheitsfehler: Wenn ein Segfault auftritt während noch Aufnahmen anstehen, hängt der VDR und der Watchdog startet ihn auch nicht neu.

    Also leider dann doch nicht für den Dauereinsatz geeignet... Aber zum Testen ist es vielleicht ganz brauchbar...

    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
    1. commit 79a95914f0cc2789238f5fc3e96a9a61201bc0e0 (HEAD -> master, tag: 1.2.18, origin/master, origin/develop, origin/HEAD)
    2. Author: kamel5 <vdr.kamel5 (at) gmx (dot) net>
    3. Date: Wed Feb 9 13:55:34 2022 +0100
    4. 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

    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

    z.B.


    Und die info hat folgenden Inhalt: