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

PmK · November 15, 2019 at 8:59 AM

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.org/git/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!

Display More

PmK · November 21, 2019 at 10:05 AM

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

wmautner · November 21, 2019 at 11:14 AM

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 · November 21, 2019 at 11:19 AM

Hast du diese Patche integriert?

streamdev-abrt-fix

Deadlock fix

PmK · November 21, 2019 at 1:31 PM

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 · November 21, 2019 at 8:24 PM

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;
}

Display More

beinhart · November 22, 2019 at 8:50 AM

PmK

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

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

gruss

beinhart

wmautner · November 22, 2019 at 9:17 AM

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

Quote from beinhart

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

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

PmK · November 22, 2019 at 10:26 AM

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 · November 27, 2019 at 3:03 PM

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 · December 5, 2019 at 1:35 PM

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

Display More

Participate now!