Problemy z buforowaniem w Kodi (w Openelec)

Za każdym razem, gdy próbuję przesyłać strumieniowo ciężkie (głównie 1080p) filmy przez sieć (webdav, sftp ...), albo to kończy się niepowodzeniem, albo pojawia się komunikat „Pamięć podręczna jest pełna” itp. Filmy zaczynają się odtwarzać, ale losowo zatrzymują się (aby ponownie buforować , Zgaduję).

Wiem, że jest to częsty problem i znam poprawki, które mogę zrobić ( również zwijają się ).

Środowisko:

Używam RPi model B i mam połączenie internetowe 100 M / b. Testowałem z Kodi 14.2 i Kodi 15 (openelec 5.0.7, openelec 5.95.2).

Testy:

Do tej pory spośród wielu dodatkowych opcji próbowałem:

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

Problem z wideo

Nie. Jeśli skopiowane na kartę SD, działa płynnie.

Problem z pamięcią RAM?

Zrozumiałbym ograniczenia sprzętowe, gdyby pamięć RAM była pełna, ale podczas oglądania filmów free -mdaje mi to:

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

Wygląda na to, że jest dużo dostępnych ...

Interesujący fakt, jak zauważył @goldilocks, bufory są niezwykle niskie.

Problem z siecią?

Jeśli pobieram plik wideo ręcznie za pomocą SFTP, jednocześnie odtwarzając ten sam plik, działa. Szybkość pobierania: ~ 1,5 MB / s. Tak więc ani sieć, ani deszyfrowanie nie stanowią wąskiego gardła.

Inny problem?

Błędy w pliku dziennika (z debugowaniem wideo, debugowaniem ffmpeg), z wyjątkiem debugowania i powiadomień:

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

OK, więc curl nie jest zoptymalizowany pod kątem przesyłania strumieniowego wideo. Ale co z SFTP? To powinien być bułka z masłem.

Problem z konfiguracją?

Ostatni test powyżej (pamięć podręczna sdcard) jest interesujący. Rozpocznie się odtwarzanie wideo po pobraniu około 150M (!) Na sdcard ( .kodi/temp/filecache000.cache). Chociaż działa dobrze, nie jest to realne rozwiązanie, ponieważ jest zbyt wolne, aby rozpocząć.

Wygląda na to, że próbuje pobrać tę samą ilość pamięci RAM, ignorując konfigurację w advancedsettings.xml. Sprawdziłem, plik jest ładowany bez żadnych problemów. Oto przykład czegoś, co przetestowałem ( .kodi/userdata/advancedsettings.xml):

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

Uwaga: niektóre z tych opcji nie są już poprawne w Kodi 17, patrz odpowiedź @ZacWolf na aktualizację

Więc ktoś ma jakiś pomysł? Co może być nie tak? Niezależnie od rozwiązania, chcę również wiedzieć, dlaczego normalne użycie (bufor RAM) kończy się niepowodzeniem w tym przypadku.

EDYCJA: Test na Archlinuxie

Zainstalowałem kodi na Archlinuxie, aby ustalić, czy jest to problem z kodi czy openelec. To samo: filmy HD są niepewne, więc w kodi wydaje się to być błąd. To bardziej problem z protokołem (SFTP i WebDAV: http), ponieważ mój test z SSHFS działa świetnie. Niestety instalacja SSHFS na openelec nie jest trywialna.

EDYCJA 2: Obejście

Piszę to tutaj, ponieważ nie rozwiązuje to bezpośrednio problemu buforowania, ale zainstalowałem kodi na Archlinuxie od ponad roku i działa doskonale. Jest mniej przyjazny dla noobów niż openelec, ale dla zainteresowanych:

• Zainstaluj Archlinux dla ARM (bardzo proste, wystarczy postępować zgodnie z instrukcją - dotyczy rpi1, w przypadku nowszej wystarczy zmienić platformę);
• Zainstaluj Kodi ( postępuj zgodnie z przewodnikiem Archlinux wiki - w zasadzie zainstaluj kodi-rbppakiet);
• Włącz Kodi usługę automatycznego uruchamiania przy starcie kodi: # systemctl enable kodi.service;
• Zainstalować sshfs: pacman -Suy sshfs;
• Użyj bardzo użyteczne SSHFS automounting z /etc/fstabzamontowanie odległy udział.

Gotowy. Nie zapomnij często aktualizować ( pacman -Suy).

EDYCJA (12/2017)

Kodi v17 zmienił nazwę i przeniósł tagi w Advancedsetting.xml

<cachemembuffersize> przemianowano na <memorysize>

<readbufferfactor> przemianowano na <readfactor>

I zostały usunięte z <sieci> i dodane do <cache>

Mój Advancesettings.xml wygląda teraz następująco:

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

Używam Pi 3 z OpenElec i napotkałem również wiele problemów z buforowaniem.

Przesyłałem go strumieniowo przez Wi-Fi, ponieważ uznałem, że jest tuż obok routera i nie powinien mieć żadnych problemów. Po podłączeniu przez Ethernet musiałem usunąć zaawansowany plik XML razem, gdy problemy z buforowaniem ustały.

Mój laptop i telefon działają dobrze przez Wi-Fi bez buforowania, więc problem z wbudowanym Wi-Fi Pi 3 na OpenElec jest przyczyną problemu.

Miałem ten sam problem i użyłem tego „hacka” , teraz wszystko działa płynnie.

--- edycja --- Zgodnie z sugestią @Simulant:

• Zainstaluj narzędzie do konserwacji xunity.
• Dostałem się do programu (nie ustawienia), xunity - poprawki.
• Wybierz opcję „Dodaj 0 pamięci podręcznej Advanced XML