Problemas de buffer com o kodi (no openelec)

9

Sempre que tento transmitir vídeos pesados ​​(principalmente 1080p) através da rede (webdav, sftp ...), ele falha ou aparece a mensagem “o cache está cheio” etc. Os vídeos começam a ser reproduzidos, mas param aleatoriamente (para armazenar novamente em buffer) , Eu acho).

Sei que esse é um problema comum e sei os ajustes que posso fazer ( enrolar também).

O ambiente:

Eu uso um RPi modelo B e tenho uma conexão de internet de 100M / b. Eu tenho testado com o Kodi 14.2 e o Kodi 15 (openelec 5.0.7, openelec 5.95.2).

Os testes:

Até agora, entre muitas opções adicionais, é isso que tentei:

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 de vídeo?

Não. Se copiado no cartão SD, ele funciona sem problemas.

Problema de RAM?

Eu entenderia a limitação de hardware se a RAM estivesse cheia, mas, enquanto assiste a vídeos, free -mme dá o seguinte:

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

Parece que há muitas disponíveis ...

Fato interessante, como @goldilocks notou, os buffers são extraordinariamente baixos.

Problema de rede?

Se eu estiver baixando um arquivo de vídeo manualmente com SFTP, ao reproduzir esse mesmo arquivo ao mesmo tempo, ele funcionará. Velocidade de download: ~ 1.5MB / s. Portanto, nem a rede, nem a descriptografia são um gargalo.

Outro problema?

Erros no arquivo de log (com depuração de vídeo, depuração de ffmpeg), exceto depuração e avisos:

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

OK, então o enrolamento não é otimizado para streaming de vídeo. Mas e o SFTP? Deve ser um pedaço de bolo.

Problema de configuração?

O último teste acima (cache do sdcard) é interessante. Ele começa a reproduzir o vídeo, após descarregar cerca de 150M (!) No sdcard ( .kodi/temp/filecache000.cache). Embora funcione bem, não é uma solução viável, pois é muito lento para iniciar.

Parece tentar baixar a mesma quantidade de RAM, ignorando a configuração advancedsettings.xml. Eu verifiquei, o arquivo é carregado sem nenhum problema. Este é um exemplo de algo que testei ( .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: algumas dessas opções não estão mais corretas no kodi 17, consulte a resposta do @ZacWolf para atualização

Então, alguém tem alguma ideia? Oque pode estar errado aqui? Qualquer que seja a solução, também quero saber por que o uso normal (buffer RAM) falha nesse caso.

EDIT: Teste no Archlinux

Instalei o kodi no Archlinux, para determinar se é um problema do kodi ou do openelec. É o mesmo: vídeos em HD são instáveis, então parece ser um bug no kodi. É mais como um problema de protocolo (SFTP e WebDAV: http) porque meu teste com SSHFS funciona muito bem. Infelizmente, não é trivial instalar o SSHFS no openelec.

EDIT 2: Uma solução alternativa

Eu o escrevo aqui, porque ele não soluciona diretamente o problema de buffer, mas eu instalei o kodi no Archlinux há mais de um ano e funciona perfeitamente bem. É menos amigável para noob do que o openelec, mas para aqueles que estão interessados:

  • Instale o Archlinux for ARM (muito fácil, basta seguir o guia - é para o rpi1, para o mais recente, basta alterar a plataforma);
  • Instale o Kodi ( siga o guia wiki do Archlinux - basicamente, instale o kodi-rbppacote);
  • Ative o serviço kodi para executar automaticamente kodi na inicialização: # systemctl enable kodi.service;
  • Instale SSHFS: pacman -Suy sshfs;
  • Use as muito úteis SSHFS automontagem com /etc/fstaba montar sua parte distante.

Feito. Não se esqueça de atualizar com freqüência ( pacman -Suy).

kodi openelec Gui-Don
fonte
150 MB podem estar no lado alto, mas 5 MB provavelmente são muito baixos para ~ 1 MB / s de conteúdo de taxa de bits, se você quiser evitar cortes. Eu abandonaria a paranóia sobre o cartão SD. Você comprou para usar certo? Caso contrário, será ainda mais seguro em um armário fresco e seco em algum lugar.
goldilocks
Obrigado pela preocupação. Mas esteja ciente de que minha pergunta não é apenas sobre o buffer sdcard. Segundo, 150M, a ~ 1MB / s ... Sim, 150s. Isso é absurdamente longo. Existe uma opção para alterar o tamanho do buffer ao usar sdcard? Isso pode ser uma solução. Então, qualquer que seja o tamanho do cache, ele carregará o vídeo inteiro (às vezes vários GB) no sdcard, não apenas no buffer. Eu sei, sdcard são baratos. Não é grande coisa. Eu sei. Mas por que eu deveria me preocupar com sdcard enquanto a RAM deveria estar funcionando?
Gui-Don
Desculpe - diminuí um pouco depois de olhar para trás. Eu não usei o Kodi, então não posso ajudar muito aqui, foi apenas uma observação geral. Na IMO, o armazenamento em buffer no disco é uma estratégia melhor do que o armazenamento em buffer da RAM, porque se você preencher 100% da RAM, o sistema não terá cache de disco, o que afetará visivelmente todos os aspectos da operação. No entanto, se você não preencher a RAM e nada mais, o que você está gravando (e lendo simultaneamente) no disco certamente será colocado no cache do disco - ou seja, RAM, mas gerenciado dinamicamente pelo kernel, que é o que torna essa uma estratégia melhor.
goldilocks
Caso isso não esteja claro: o sistema operacional usa o máximo de RAM não armazenada possível para armazenar em cache (eu me referi a isso acima como "cache de disco", que é um pouco impróprio, mas enfatiza o fato de que geralmente são geralmente coisas lidas com freqüência no disco ) No pi, não seria incomum que tudo isso fosse RAM não confirmada, este é o número de "buffers" free- portanto, algo interessante em seu post é o fato de esse número ser relativamente pequeno. Se você aumentar o cache em disco do Kodi, esse número poderá / deverá aumentar enquanto estiver em ação para igualá-lo.
goldilocks
11
Eu vi;) OK, eu entendo que usar o disco é melhor do que encher a RAM. É uma boa solução para fazê-lo funcionar, se eu puder reduzir o tamanho do buffer necessário para reproduzir o vídeo. BTW, parece ser uma porcentagem, e não uma quantidade absoluta. Ainda assim, estou curioso sobre o que acontece aqui. É estranho que eu tenha usado tanta memória RAM, mesmo enquanto o vídeo está em buffer.
Gui-Don

Respostas:

2

EDIT (12/2017)

Tags Kodi v17 renomeadas e realocadas em advancedsetting.xml

<cachemembuffersize> renomeado para <memorysize>

<readbufferfactor> renomeado para <readfactor>

E eles foram removidos da <rede> e adicionados ao <cache>

Meu advancesettings.xml agora se parece com:

<?xml version="1.0" encoding="utf-8"?>
<advancedsettings>
        <cache>
                <memorysize>524288000</memorysize>
                <buffermode>1</buffermode>
                <readfactor>6</readfactor>
        </cache>
</advancedsettings>
ZacWolf
fonte
Isso é especificamente para um dispositivo Vero4K, que tem mais memória que um Pi, portanto, você precisará ajustar essas configurações específicas da memória disponível.
ZacWolf 04/04
1

Estou executando o Pi 3 com o OpenElec e também tive muitos problemas de buffer.

Eu estava transmitindo para ele por Wi-Fi, pois achei que estava ao lado do roteador e não deveria ter nenhum problema. Bem, depois de conectar via Ethernet, removi todos os arquivos xml avançados, pois os problemas de buffer pararam.

Meu laptop e telefone funcionam bem via Wi-Fi sem buffer, então algo com o Wi-Fi integrado do Pi 3 no OpenElec está causando o problema.

Marcus
fonte
Fico feliz que você tenha corrigido o problema e tenho certeza de que ajudará muitas pessoas que se depararam com esse problema. No meu caso, eu usei a Ethernet desde o início. Para o rpi1, não acho que essa seja a solução. Dito isto, é estranho que você tenha tido um problema semelhante no rpi3, pois ele tem o dobro de RAM do que o rpi1… Posso estar errado, mas parece que o manuseio de cache no kodi é ruim.
Gui-Don
-1

Eu tive o mesmo problema e usei esse 'hack' , as coisas correm bem agora.

--- editar --- Seguindo a sugestão do @Simulant:

  • Instale a ferramenta de manutenção do xunity.
  • Entrei no programa (não configurações), xunity - ajustes.
  • Selecione 'Adicionar 0 XML avançado de cache
Meir
fonte
11
Alinhe os fakes principais da sua fonte vinculada. Caso contrário, se a fonte vinculada ficar offline, sua postagem será inútil.
Simulante
11
O Xunity não é apenas uma GUI para esse fim? Quero dizer, como é diferente de ajustar o arquivo advancedsettings.xml sozinho? Na verdade, eu fiz a configuração sem cache, é uma maneira lenta de carregar para vídeos SFTP ou webdav.
Gui-Don
É um gui. Mas, pela minha experiência, a edição direta pode ser complicada (devido a permissões etc.). O addon funciona muito bem, eu usei-o :-)
Meir