Pufferprobleme mit Kodi (auf openelec)

Jedes Mal, wenn ich versuche, schwere (meistens 1080p) Videos über das Netzwerk zu streamen (webdav, sftp ...), schlägt dies entweder fehl oder ich erhalte die Meldung "Cache ist voll" usw. Videos werden abgespielt, aber zufällig gestoppt (um erneut zu puffern) , Ich vermute).

Ich weiß, dass dies ein häufiges Problem ist und ich weiß, welche Optimierungen ich vornehmen kann (auch Curl ).

Die Umgebung:

Ich verwende ein RPi-Modell B und habe eine 100M / b-Internetverbindung. Ich habe mit Kodi 14.2 und Kodi 15 (openelec 5.0.7, openelec 5.95.2) getestet.

Die Tests:

Bisher habe ich unter vielen zusätzlichen Optionen Folgendes versucht:

Cache\Protocol | Webdav      | SFTP (local and internet)
--------------------------------------------------------------------------
No cache       | not loading | loads quickly, no error, stops frequently
--------------------------------------------------------------------------
(5mb cache)    | not loading | slow to load, cache error, stops randomly
--------------------------------------------------------------------------
(25mb cache)   | not loading | very slow to load, cache error, stops randomly
--------------------------------------------------------------------------
sdcard cache   | not loading | incredibly slow to load, no error, fine
--------------------------------------------------------------------------

Videoproblem?

Nee. Wenn es auf die SD-Karte kopiert wird, läuft es reibungslos.

RAM Problem?

Ich würde die Hardwarebeschränkung verstehen, wenn der RAM voll wäre, aber beim Ansehen von Videos habe free -mich Folgendes:

             total         used         free       shared      buffers
Mem:           373          236          137            4           34
-/+ buffers:                202          171
Swap:            0            0            0

Es scheint, dass es genügend gibt ...

Interessanterweise sind die Puffer, wie @goldilocks bemerkte, ungewöhnlich niedrig.

Netzwerk Problem?

Wenn ich eine Videodatei manuell mit SFTP herunterlade und gleichzeitig dieselbe Datei wiedergebe, funktioniert dies. Download-Geschwindigkeit: ~ 1,5 MB / s. Weder das Netzwerk noch die Entschlüsselung sind also ein Engpass.

Anderes Problem?

Fehler in der Protokolldatei (mit Video-Debug, ffmpeg-Debug), außer Debug und Hinweise:

ERROR: CCurlFile::FillBuffer - Failed: Timeout was reached
ERROR: OMXPlayerVideo: Got MSGQ_IS_ERROR(-1) Aborting

OK, Curl ist also nicht für Video-Streaming optimiert. Aber was ist mit SFTP? Es sollte ein Kinderspiel sein.

Konfigurationsproblem?

Der letzte Test oben (SD-Karten-Cache) ist interessant. Das Video wird abgespielt, nachdem ca. 150M (!) Auf die SD-Karte ( .kodi/temp/filecache000.cache) heruntergeladen wurden . Obwohl es gut läuft, ist es keine praktikable Lösung, da es zu langsam ist, um zu starten.

Es scheint zu versuchen, die gleiche Menge an RAM herunterzuladen, wobei die Konfiguration in ignoriert wird advancedsettings.xml. Ich habe überprüft, die Datei wird ohne Probleme geladen. Dies ist ein Beispiel für etwas, das ich getestet habe ( .kodi/userdata/advancedsettings.xml):

<advancedsettings>
    <network>
        <buffermode>1</buffermode>
        <cachemembuffersize>5242880</cachemembuffersize>
        <readbufferfactor>4.0</readbufferfactor>
        <curlclienttimeout>60</curlclienttimeout>
        <curllowspeedtime>20</curllowspeedtime>
    </network>
</advancedsettings>

Hinweis: Einige dieser Optionen sind in Kodi 17 nicht mehr korrekt. Informationen zum Update finden Sie in der Antwort von @ZacWolf

Also hat jemand eine Idee? Was könnte hier falsch sein? Was auch immer die Lösung sein mag, ich möchte auch wissen, warum die normale Nutzung (RAM-Puffer) in diesem Fall fehlschlägt.

EDIT: Test auf Archlinux

Ich habe Kodi unter Archlinux installiert, um festzustellen, ob es sich um ein Kodi- oder Openelec-Problem handelt. Es ist das gleiche: HD-Videos sind abgehackt, daher scheint es ein Fehler in Kodi zu sein. Es ist eher ein Protokollproblem (SFTP und WebDAV: http), weil mein Test mit SSHFS großartig funktioniert. Leider ist es nicht trivial, SSHFS auf openelec zu installieren.

EDIT 2: Eine Problemumgehung

Ich schreibe es hier, weil es das Pufferproblem nicht direkt angeht, aber ich habe Kodi seit mehr als einem Jahr unter Archlinux installiert und es funktioniert perfekt. Es ist weniger noob-freundlich als openelec, aber für diejenigen, die interessiert sind:

Installieren Sie Archlinux für ARM (sehr einfach, folgen Sie einfach der Anleitung - für rpi1, für neuere, ändern Sie einfach die Plattform);
Installieren Sie Kodi ( folgen Sie dem Archlinux-Wiki-Handbuch - installieren Sie im Grunde das kodi-rbpPaket);
Aktivieren Sie den Kodi-Dienst, um Kodi beim Start automatisch auszuführen : # systemctl enable kodi.service;
Installieren Sie SSHFS : pacman -Suy sshfs;
Verwenden Sie die sehr nützliche automatische SSHFS-Bereitstellung mit /etc/fstab, um Ihre entfernte Freigabe bereitzustellen .

Getan. Vergessen Sie nicht, frenquently ( pacman -Suy) zu aktualisieren .

kodi openelec

— Gui-Don
quelle

150 MB sind zwar zu hoch, aber 5 MB sind wahrscheinlich zu niedrig für ~ 1 MB / s Bitrateninhalt, wenn Sie Abplatzungen vermeiden möchten. Ich würde die Paranoia über die SD-Karte aufgeben. Du hast es gekauft, um es richtig zu benutzen? Wenn nicht, ist es in einem kühlen, trockenen Schrank irgendwo noch sicherer.

— Goldlöckchen

Dank für Ihr Interesse. Beachten Sie jedoch, dass meine Frage nicht nur den SD-Kartenpuffer betrifft. Zweitens 150 MB bei ~ 1 MB / s ... Ja, 150 Sekunden. Das ist absurd lang. Gibt es eine Option zum Ändern der Puffergröße bei Verwendung von SD-Karte? Dies könnte eine Lösung sein. Unabhängig von der Cache-Größe wird dann das gesamte Video (manchmal mehrere GB) auf die SD-Karte geladen, nicht nur der Puffer. Ich weiß, SD-Karte sind billig. Es ist keine große Sache. Ich kenne. Aber warum sollte ich mich um SD-Karte kümmern, während RAM funktionieren sollte?

— Gui-Don

Entschuldigung - ich habe das etwas abgeschwächt, nachdem ich zurückgeschaut habe. Ich habe Kodi nicht benutzt, daher kann ich hier nicht viel helfen, es war nur eine allgemeine Beobachtung. IMO, das Puffern auf die Festplatte ist eine bessere Strategie als das Puffern auf den Arbeitsspeicher, denn wenn Sie den Arbeitsspeicher zu 100% füllen, hat das System keinen Festplatten-Cache mehr, was sich spürbar auf alle Aspekte des Betriebs auswirkt . Wenn Sie jedoch den Arbeitsspeicher nicht füllen und nichts anderes tut, wird das, was Sie auf die Festplatte schreiben (und gleichzeitig von dieser lesen), sicherlich in den Festplatten-Cache gestellt - dh in den Arbeitsspeicher, aber dynamisch vom Kernel verwaltet Was macht dies zu einer besseren Strategie.

— Goldlöckchen

Für den Fall, dass dies nicht klar ist: Das Betriebssystem verwendet so viel nicht festgeschriebenen RAM wie möglich für das Caching (ich habe dies oben als "Festplatten-Cache" bezeichnet, was eine leichte Fehlbezeichnung ist, betont jedoch die Tatsache, dass es sich normalerweise um häufig von der Festplatte gelesenes Material handelt ). Auf dem Pi wäre es nicht ungewöhnlich, dass dies alles nicht festgeschriebener RAM ist, dies ist die "Puffer" -Zahl von free- etwas Interessantes in Ihrem Beitrag ist also die Tatsache, dass diese Anzahl relativ klein ist. Wenn Sie den To-Disk-Cache von Kodi vergrößern, kann / sollte sich diese Anzahl während der Aktion erhöhen, um sie ungefähr zu erreichen.

— Goldlöckchen

Ich habe gesehen;) OK, ich verstehe, dass die Verwendung der Festplatte besser ist als das Auffüllen des RAM. Es ist eine gute Lösung, damit es funktioniert, wenn ich die erforderliche Puffergröße für die Wiedergabe des Videos reduzieren kann. Übrigens scheint es eher ein Prozentsatz als ein absoluter Betrag zu sein. Trotzdem bin ich gespannt, was hier passiert. Es ist seltsam, dass ich so viel RAM ungenutzt habe, auch wenn das Video gepuffert wird.

— Gui-Don

BEARBEITEN (12/2017)

Kodi v17 hat Tags in advancedsetting.xml umbenannt und verschoben

<cachemembuffersize> wurde in <memorysize> umbenannt

<readbufferfactor> wurde in <readfactor> umbenannt

UND sie wurden aus <Netzwerk> entfernt und zu <Cache> hinzugefügt

Meine fortschrittliche.xml sieht jetzt so aus:

<?xml version="1.0" encoding="utf-8"?>
<advancedsettings>
        <cache>
                <memorysize>524288000</memorysize>
                <buffermode>1</buffermode>
                <readfactor>6</readfactor>
        </cache>
</advancedsettings>

— ZacWolf
quelle

Dies gilt speziell für ein Vero4K-Gerät, das über mehr Speicher als ein Pi verfügt. Daher müssen Sie diese Einstellungen an Ihren verfügbaren Speicher anpassen.

— ZacWolf

Ich verwende Pi 3 mit OpenElec und bin auch auf viele Pufferprobleme gestoßen.

Ich habe über WLAN darauf gestreamt, da ich dachte, es befindet sich direkt neben dem Router und sollte keine Probleme haben. Nachdem ich mich über Ethernet angeschlossen hatte, musste ich die erweiterte XML-Datei alle zusammen entfernen, da die Pufferprobleme aufhörten.

Mein Laptop und mein Telefon funktionieren beide gut über WLAN, ohne zu puffern, sodass das Problem durch das integrierte Wi-Fi des Pi 3 auf OpenElec verursacht wird.

— Marcus
quelle

Ich bin froh, dass Sie Ihr Problem behoben haben, und ich bin sicher, dass es vielen Menschen helfen wird, die auf dieses Problem gestoßen sind. In meinem Fall habe ich allerdings von Anfang an Ethernet verwendet. Für rpi1 denke ich nicht, dass dies die Lösung ist. Davon abgesehen ist es seltsam, dass Sie ein ähnliches Problem auf rpi3 hatten, da es doppelt so viel RAM wie rpi1 hat… Ich kann mich irren, aber es scheint, dass die Cache-Handhabung auf kodi einfach beschissen ist.

— Gui-Don

-1

Ich hatte das gleiche Problem und habe diesen "Hack" verwendet . Die Dinge laufen jetzt reibungslos.

--- edit --- Nach @Simulant Vorschlag:

Installieren Sie das xunity-Wartungstool.
Bin ins Programm gekommen (keine Einstellungen), xunity - Tweaks.
Wählen Sie 'Add 0 Cache Advanced XML

— Meir
quelle

Bitte geben Sie die wichtigsten Fakten aus Ihrer verlinkten Quelle an. Andernfalls wäre Ihr Beitrag nutzlos, wenn die verknüpfte Quelle offline geschaltet würde.

— Simulant

Ist Xunity nicht nur eine grafische Benutzeroberfläche für diesen Zweck? Ich meine, wie unterscheidet es sich davon, die Datei advancedsettings.xml selbst zu optimieren? Eigentlich habe ich die No-Cache-Einstellung vorgenommen, es ist viel zu langsam, um für SFTP- oder Webdav-Videos zu laden.

— Gui-Don

Es ist eine GUI. Aber meiner Erfahrung nach kann die direkte Bearbeitung schwierig sein (aufgrund von Berechtigungen usw.). Das Addon funktioniert gut, ich habe es benutzt :-)

— Meir