Streamdev, i/o throttle activated und dann vdr-absturz

PmK · 15. November 2019

Hallo Jungs,

mein VDR läuft jetzt langsam aber sicher halbwegs stabil. Nur ein Problem plagt mich noch.

Es kommt immer wieder mal vor (Vorzugsweise wenn man nach längerer Zeit mal umschaltet), das ich folgenden Fehler im Log habe und der VDR abstürzt.

Das passiert mir 2-3x am Tag.

Im Forum hatte ich gesehen das es dafür eine Anpassung des Streamdevs gab. Ich verwende allerdings die Version aus dem git -> https://projects.vdr-developer…vdr-plugin-streamdev.git/

Gibt es noch irgendetwas was ich hier tun kann?

Grüsse, PmK

Code

Nov 15 06:34:52 raspberrypi vdr: [398] switching to channel 1 S19.2E-1-1057-61200 (RTL HD)

Nov 15 06:34:53 raspberrypi vdr: [1026] i/o throttle activated, count = 1 (tid=1026)

Nov 15 06:34:53 raspberrypi vdr: [1026] buffer usage: 70% (tid=1025)

Nov 15 06:34:53 raspberrypi vdr: [1026] buffer usage: 80% (tid=1025)

Nov 15 06:34:54 raspberrypi vdr: [1026] buffer usage: 90% (tid=1025)

Nov 15 06:34:54 raspberrypi vdr: [1026] buffer usage: 100% (tid=1025)

Nov 15 06:35:21 raspberrypi vdr: [398] PANIC: watchdog timer expired - exiting!

Alles anzeigen

PmK · 21. November 2019

Hat echt keiner solche Probleme das er nach längerer Zeit plötzlich beim Umschalten derartige Abstürze hat?

wmautner · 21. November 2019

Gelegentlich hab ich auch einen i/o throttle, aber eigentlich immer ein release dahinter, ggf. dann ring buffer overflows.

Was mich hier wundert, daß 1 Minute gar nichts ins Log eingetragen wurde und dann der Watchdog abgelaufen ist ... normalerweise kommt bei 100% gleich ein "ring buffer overflow" oder ähnliche Reaktion.

nanohcv · 21. November 2019

Hast du diese Patche integriert?

streamdev-abrt-fix

Deadlock fix

PmK · 21. November 2019

Hallo nanohcv, laut dem was ich so gefunden habe sollten diese Patches eigentlich im GIT eingepflegt sein. Ich schau aber gleich mal ob da vieleicht doch noch was fehlt.

Edit:

okayy.... der Deadlock Fix ist drin, der andere patch allerdings nicht. Jetzt bin ich gespannt ob das ein für alle mal ein Ende hat mit diesen komischen Abstürzen.. Danke nanohcv!!

nanohcv · 21. November 2019

Also im git ist keiner von beiden, gerade nochmal kontrolliert.

Schau lieber beim Deadlock-Fix genau hin, weil auf den kommt es an

Wichtig ist hier, dass die Zeile auskommentiert bzw. gelöscht wird.

So muss es aussehen:

Code

bool cStreamdevDevice::SetPid(cPidHandle *Handle, int Type, bool On) {
    Dprintf("SetPid, Pid=%d, Type=%d, On=%d, used=%d\n", Handle->pid, Type, On, Handle->used);

    bool res = true; 
    if (Handle->pid && (On || !Handle->used)) {
        res = m_ClientSocket->SetPid(Handle->pid, On);

        m_Pids += (!res) ? 0 : On ? 1 : -1;
        if (m_Pids < 0) 
            m_Pids = 0;
    }
    return res;
}

Alles anzeigen

beinhart · 22. November 2019

PmK

ciminus hat sich um das plugin zwischenzeitlich gekuemmert. nimm doch mal diesen git:

https://github.com/ciminus/vdr-plugin-streamdev

gruss

beinhart

wmautner · 22. November 2019

Die letzten Änderungen da sind 2 Jahre zurück?

Zitat von beinhart

ciminus hat sich um das plugin zwischenzeitlich gekuemmert. nimm doch mal diesen git:

https://github.com/ciminus/vdr-plugin-streamdev

PmK · 22. November 2019

nanohcv den Deadlock-Fix hatte ich mal selbst eingebaut. Aber wie gesagt, früh immer Abbrüche. Da war dann aber auch keine Info wegen Deadlock in den Logs.

Bei dem Repo von ciminus ist aber die Änderung anscheinend drin.

wwilde · 27. November 2019

Seid ihr sicher, daß das Problem aus dem Streamdev Plugin und nicht vom System selbst kommt?

Ich habe da etwas von "btrfs" im Avatarfenster gesehen - BTRFS macht aber z. T. auch Snaphots und/ oder ein rebalancing des BTREE Baumes. Während des Rebalancings hatte ich selbst auf meinem "Arbeitsknecht" (Notebook mit SSDs) früher schon mal mehrere Minuten lang ein komplett unresponsives System. Das hat dann eben auch wie geschildert noch nicht einmal mehr Logeinträge produziert. Mittlerweile hat sich das allerdings auch bei den aktuellsten Distributionen gebessert. Ich hatte allerdings mit BTRFS hin und wieder ein defektes und irreparables Filesystem, weshalb ich mittlerweile wieder auf andere Filesysteme zurück gegangen bin.

PmK · 5. Dezember 2019

Also nach einigen Tagen testen kann ich bis jetzt folgendes sagen:

Vorher hatte ich nach den Abstürzen immer wieder kein OSD mehr auf dem Raspberry und musste das Teil dann neu booten. Das hab ich bisher mit beiden Patches nicht mehr gehabt.

ABER:

Ich bekomm jetzt immer noch nach längerer Laufzeit (RPI läuft 24/7) wenn man einschaltet den selben Fehler siehe unten.

Filesystem ist bei mir ext4, Recordings-Verzeichnis hängt per nfs4 im System.

Code

Dec  5 06:09:21 raspberrypi vdr: [16892] ERROR: 9 TS packet(s) not accepted in Transfer Mode
Dec  5 06:09:21 raspberrypi vdr: [16515] rpihddevice: set HDMI audio output format to 2ch PCM, 48.0kHz
Dec  5 06:09:28 raspberrypi vdr: [16515] rpihddevice: set HDMI audio output format to 2ch PCM, 48.0kHz
Dec  5 06:09:35 raspberrypi vdr: [17423] animator thread thread started (pid=16505, tid=17423, prio=high)
Dec  5 06:09:36 raspberrypi vdr: [16515] rpihddevice: set HDMI audio output format to 2ch PCM, 48.0kHz
Dec  5 06:09:36 raspberrypi vdr: [16505] switching to channel 6 S19.2E-1-1109-5402 (DMAX HD)
Dec  5 06:09:37 raspberrypi vdr: [16893] i/o throttle activated, count = 1 (tid=16893)
Dec  5 06:09:38 raspberrypi vdr: [16893] buffer usage: 70% (tid=16892)
Dec  5 06:09:38 raspberrypi vdr: [16893] buffer usage: 80% (tid=16892)
Dec  5 06:09:38 raspberrypi vdr: [16893] buffer usage: 90% (tid=16892)
Dec  5 06:09:38 raspberrypi vdr: [16893] buffer usage: 100% (tid=16892)
Dec  5 06:10:05 raspberrypi vdr: [16505] PANIC: watchdog timer expired - exiting!
Dec  5 06:10:05 raspberrypi vdr: [17423] animator thread thread ended (pid=16505, tid=17423)
Dec  5 06:10:05 raspberrypi lircd[448]: lircd-0.9.4c[448]: Info: removed client

Alles anzeigen

Streamdev, i/o throttle activated und dann vdr-absturz

Jetzt mitmachen!

Teilen