Problemi di buffering con kodi (su openelec)

Ogni volta che provo a trasmettere video pesanti (principalmente 1080p) attraverso la rete (webdav, sftp ...), o non riesce o ricevo il messaggio "cache è piena" ecc. La riproduzione dei video inizia, ma si arresta in modo casuale (per eseguire nuovamente il buffer , Suppongo).

So che questo è un problema comune e conosco le modifiche che posso fare ( anche arricciare ).

L'ambiente:

Uso un modello RPi B e ho una connessione Internet 100M / b. Ho provato con Kodi 14.2 e Kodi 15 (openelec 5.0.7, openelec 5.95.2).

I test:

Finora, tra molte altre opzioni, questo è quello che ho provato:

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

Problema video?

No. Se copiato sulla scheda SD, funziona senza problemi.

Problema RAM?

Comprenderei la limitazione hardware se la RAM fosse piena, ma, mentre guardo i video, free -mmi dà questo:

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

Sembra che ci siano molti disponibili ...

Fatto interessante, come notato da @goldilocks, i buffer sono insolitamente bassi.

Problema di rete?

Se si sta scaricando un file video manualmente con SFTP, durante la riproduzione di questo stesso file allo stesso tempo, funziona. Velocità di download: ~ 1,5 MB / s. Quindi, né la rete, né la decrittazione sono un collo di bottiglia.

Altro problema?

Errori nel file di registro (con debug video, debug ffmpeg), ad eccezione del debug e degli avvisi:

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

OK, quindi l'arricciatura non è ottimizzata per lo streaming video. Ma che dire di SFTP? Dovrebbe essere un gioco da ragazzi.

Problema di configurazione?

L'ultimo test sopra (cache sdcard) è interessante. Inizia a riprodurre il video, dopo aver scaricato circa 150 M (!) Sulla scheda SD ( .kodi/temp/filecache000.cache). Anche se funziona bene, non è una soluzione praticabile in quanto è troppo lento per avviarsi.

Sembra provare a scaricare la stessa quantità di RAM, ignorando la configurazione advancedsettings.xml. Ho controllato, il file viene caricato senza alcun problema. Questo è un esempio di qualcosa che ho testato ( .kodi/userdata/advancedsettings.xml):

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

Nota: alcune di queste opzioni non sono più corrette in Kodi 17, vedere la risposta di @ZacWolf per l'aggiornamento

Qualcuno ha qualche idea? Cosa potrebbe essere sbagliato qui? Qualunque sia la soluzione, voglio anche sapere perché il normale utilizzo (buffer RAM) non riesce in questo caso.

EDIT: Test su Archlinux

Ho installato kodi su Archlinux, per determinare se si tratta di un problema di kodi o openelec. È lo stesso: i video HD sono instabili, quindi sembra essere un bug in Kodi. È più come un problema di protocollo (SFTP e WebDAV: http) perché il mio test con SSHFS funziona alla grande. Sfortunatamente, non è banale installare SSHFS su openelec.

EDIT 2: una soluzione alternativa

Lo scrivo qui, perché non affronta direttamente il problema del buffering, ma ho installato kodi su Archlinux da più di un anno e funziona perfettamente. È meno amichevole rispetto a openelec, ma per coloro che sono interessati:

Installa Archlinux per ARM (molto semplice, basta seguire la guida - è per rpi1, per quello più recente, basta cambiare la piattaforma);
Installa Kodi ( segui la guida wiki di Archlinux - in sostanza, installa il kodi-rbppacchetto);
Attivare il servizio Kodi per eseguire automaticamente Kodi all'avvio: # systemctl enable kodi.service;
Installare SSHFS: pacman -Suy sshfs;
Usa l' utilunt SSHFS molto utile con /etc/fstabper montare la tua condivisione distante.

Fatto. Non dimenticare di aggiornare in modo frenetico ( pacman -Suy).

kodi openelec

— Gui-Don
fonte

150 MB potrebbero essere nella parte alta, ma probabilmente 5 MB è troppo basso per ~ 1 MB / s di contenuto in bitrate se si desidera evitare il rischio di incertezza. Vorrei abbandonare la paranoia sulla scheda SD. L'hai comprato per usare giusto? In caso contrario, sarà ancora più sicuro in un armadio fresco e asciutto da qualche parte.

— riccioli d'oro

Grazie per la tua preoccupazione. Ma tieni presente che la mia domanda non riguarda solo il buffer sdcard. In secondo luogo, 150 MB, a ~ 1 MB / s ... Sì, 150 secondi. Questo è assurdamente lungo. Esiste un'opzione per modificare la dimensione del buffer quando si utilizza sdcard? Questa potrebbe essere una soluzione. Quindi, qualunque sia la dimensione della cache, caricherà l'intero video (a volte diversi GB) sulla scheda SD, non solo nel buffer. Lo so, le sdcard sono economiche. Non è un grosso problema. Lo so. Ma perché dovrei preoccuparmi di sdcard mentre la RAM dovrebbe funzionare?

— Gui-Don,

Mi dispiace - l'ho attenuato un po 'dopo averlo guardato indietro. Non ho usato Kodi quindi non posso essere di grande aiuto qui, è stata solo un'osservazione generale. IMO, il buffering su disco è una strategia migliore rispetto al buffering su RAM perché se si riempie la RAM al 100%, il sistema non ha più cache del disco che avrà un impatto notevole su tutti gli aspetti dell'operazione. Tuttavia, se non si riempie la RAM e nient'altro fa, ciò che si sta scrivendo (e contemporaneamente leggendo dal disco) verrà sicuramente inserito nella cache del disco - cioè, RAM, ma gestito dinamicamente dal kernel, che è ciò che rende questa una strategia migliore.

— riccioli d'oro

Nel caso ciò non sia chiaro: il sistema operativo utilizza la quantità di RAM non memorizzata che può per la memorizzazione nella cache (ho indicato sopra come "cache del disco", che è un termine improprio, ma sottolinea il fatto che di solito si tratta principalmente di roba frequentemente letta dal disco ). Per quanto riguarda il pi, non sarebbe insolito che fosse tutta RAM senza commit, questa è la cifra dei "buffer" da free- quindi qualcosa di interessante nel tuo post è il fatto che questo numero è relativamente piccolo. Se aumenti la cache su disco di Kodi, quel numero potrebbe / dovrebbe aumentare mentre sei in azione per abbinarlo.

— riccioli d'oro

Ho visto;) OK, ho capito che usare il disco è meglio che riempire la RAM. È una buona soluzione per farlo funzionare, se posso ridurre le dimensioni del buffer necessarie per riprodurre il video. A proposito, sembra essere una percentuale, piuttosto che un importo assoluto. Tuttavia, sono curioso di sapere cosa succede qui. È strano che non abbia utilizzato così tanta RAM, anche quando il video è in buffer.

— Gui-Don,

EDIT (12/2017)

Kodi v17 tag rinominati e riposizionati in advancedsetting.xml

<cachemembuffersize> rinominato in <memorysize>

<readbufferfactor> rinominato in <readfactor>

E sono stati rimossi da <network> e aggiunti a <cache>

Il mio advancesettings.xml ora assomiglia a:

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

— ZacWolf
fonte

Questo è specificamente per un dispositivo Vero4K, che ha più memoria di un Pi, quindi dovrai modificare queste impostazioni specifiche per la tua memoria disponibile.

— ZacWolf

Sto eseguendo Pi 3 con OpenElec e ho riscontrato anche molti problemi di buffering.

Lo stavo trasmettendo in streaming tramite Wi-Fi, dato che pensavo fosse proprio accanto al router e non avrei dovuto avere problemi. Bene, dopo aver effettuato il collegamento tramite Ethernet, sono riuscito a rimuovere il file XML avanzato tutti insieme quando i problemi di buffering si sono interrotti.

Sia il mio laptop che il mio telefono funzionano bene tramite Wi-Fi senza buffering, quindi qualcosa con il Wi-Fi integrato di Pi 3 su OpenElec sta causando il problema.

— Marcus
fonte

Sono contento che tu abbia risolto il problema e sono sicuro che aiuterà molte persone che hanno riscontrato questo problema. Nel mio caso però ho usato Ethernet dall'inizio. Per rpi1 non penso che questa sia la soluzione. Detto questo, è strano che tu abbia avuto un problema simile su rpi3, poiché ha il doppio della RAM di rpi1 ... Posso sbagliarmi, ma sembra che la gestione della cache su Kodi sia semplicemente scadente.

— Gui-Don,

-1

Ho avuto lo stesso problema e ho usato questo 'hack' , le cose funzionano senza problemi ora.

--- modifica --- Seguendo il suggerimento @Simulant:

Installare lo strumento di manutenzione xunity.
Entrato nel programma (non impostazioni), xunity - tweaks.
Seleziona 'Aggiungi 0 cache Advanced XML

— Meir
fonte

Si prega di allineare i falsi chiave dalla fonte collegata. Altrimenti se la fonte collegata non fosse in linea il tuo post sarebbe inutile.

— Simulante,

Xunity non è solo una GUI a tale scopo? Voglio dire, in che cosa differisce dal modificare personalmente il file advancedsettings.xml ? In realtà, ho fatto l'impostazione senza cache, è un modo per rallentare il caricamento per i video SFTP o webdav.

— Gui-Don,

È una gui. Ma dalla mia esperienza l'editing diretto può essere complicato (a causa di autorizzazioni, ecc.). L'addon funziona bene, l'ho usato :-)

— Meir