Problemy z buforowaniem w Kodi (w Openelec)


9

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:

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


150 MB może być zawyżone, ale 5 MB jest prawdopodobnie zbyt niskie dla zawartości około 1 MB / s, jeśli chcesz uniknąć niepewności. Porzuciłbym paranoję dotyczącą karty SD. Kupiłeś to, prawda? Jeśli nie, będzie jeszcze bezpieczniej w chłodnej, suchej szafce.
Złotowłosa

Dzięki za troskę. Pamiętaj jednak, że moje pytanie nie dotyczy samego bufora sdcard. Po drugie, 150M, przy ~ 1 MB / s ... Tak, 150s. To jest absurdalnie długie. Czy istnieje opcja zmiany rozmiaru bufora podczas korzystania z karty SD? To może być rozwiązanie. Następnie, bez względu na rozmiar pamięci podręcznej, załaduje cały film (czasem kilka GB) na sdcard, nie tylko bufor. Wiem, sdcard są tanie. To nie jest wielka sprawa. Wiem. Ale dlaczego miałbym zawracać sobie głowę sdcard, gdy pamięć RAM powinna działać?
Gui-Don,

Przepraszam - nieco to stonowałem po spojrzeniu na to. Nie korzystałem z Kodi, więc nie mogę tu pomóc, to była tylko ogólna obserwacja. IMO, buforowanie na dysk jest lepszą strategią niż buforowanie do RAM, ponieważ jeśli zapełnisz RAM w 100%, system nie ma pamięci podręcznej dysku, co wyraźnie wpłynie na wszystkie aspekty działania. Jeśli jednak nie zapełnisz pamięci RAM i nic innego nie zrobisz, to, co piszesz na dysk (i jednocześnie odczytujesz z niego) z pewnością zostanie umieszczone w pamięci podręcznej dysku - tj. Pamięci RAM, ale jest dynamicznie zarządzane przez jądro, które jest co sprawia, że ​​jest to lepsza strategia.
goldilocks

W przypadku, gdy nie jest to jasne: system operacyjny wykorzystuje tak dużo nieprzydzielonej pamięci RAM, jak to możliwe do buforowania ( nazwałem to powyżej „pamięcią podręczną dysku”, co jest nieco mylące, ale podkreśla fakt, że zwykle są to głównie rzeczy często odczytywane z dysku ). Na pi nie jest niczym niezwykłym, że jest to cała nieprzydzielona pamięć RAM, jest to liczba „buforów” z free- więc czymś interesującym w twoim poście jest fakt, że ta liczba jest stosunkowo niewielka. Jeśli zwiększysz pamięć podręczną Kodi na dysk, liczba ta może / powinna wzrosnąć podczas działania, aby ją dopasować.
złotowłosa

1
Widziałem;) OK, rozumiem, że korzystanie z dysku jest lepsze niż zapełnianie pamięci RAM. Jest to dobre rozwiązanie, aby działało, jeśli mogę zmniejszyć potrzebny rozmiar bufora do odtworzenia wideo. BTW, wydaje się, że jest to procent, a nie kwota bezwzględna. Mimo to ciekawi mnie, co się tutaj dzieje. Dziwne, że tak dużo pamięci RAM nie było używane, nawet podczas buforowania wideo.
Gui-Don,

Odpowiedzi:


2

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>

Dotyczy to w szczególności urządzenia Vero4K, które ma więcej pamięci niż Pi, więc musisz dostosować te ustawienia do dostępnej pamięci.
ZacWolf,

1

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.


Cieszę się, że rozwiązałeś problem i jestem pewien, że pomoże to wielu osobom, które napotkały ten problem. W moim przypadku jednak od samego początku korzystałem z sieci Ethernet. Dla rpi1 nie sądzę, że to jest rozwiązanie. To powiedziawszy, to dziwne, że miałeś podobny problem na rpi3, ponieważ ma dwa razy więcej pamięci RAM niż rpi1… Mogę się mylić, ale wygląda na to, że obsługa pamięci podręcznej na kodi jest po prostu kiepska.
Gui-Don

-1

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

1
Proszę podać najważniejsze fakty z połączonego źródła. W przeciwnym razie, jeśli połączone źródło przejdzie w tryb offline, post będzie bezużyteczny.
Symulant

1
Czy Xunity nie jest tylko GUI do tego celu? Chodzi mi o to, czym różni się od samodzielnego modyfikowania pliku advancedsettings.xml ? Właściwie ustawiłem brak pamięci podręcznej, jest to sposób, aby powoli ładować filmy SFTP lub webdav.
Gui-Don,

To jest gui. Jednak z mojego doświadczenia wynika, że ​​bezpośrednia edycja może być trudna (ze względu na uprawnienia itp.). Dodatek działa ładnie, użyłem go :-)
Meir
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.