Problemas de almacenamiento intermedio con kodi (en openelec)


9

Cada vez que intento transmitir videos pesados ​​(principalmente 1080p) a través de la red (webdav, sftp ...), falla o aparece el mensaje "caché está lleno", etc. Los videos comienzan a reproducirse, pero se detienen aleatoriamente (para volver a almacenar en búfer) , Supongo).

Sé que este es un problema común y sé los ajustes que puedo hacer ( curl también).

El entorno:

Utilizo un RPi modelo B y tengo una conexión a Internet de 100M / b. He estado probando con Kodi 14.2 y Kodi 15 (openelec 5.0.7, openelec 5.95.2).

Los exámenes:

Hasta ahora, entre muchas opciones adicionales, esto es lo que probé:

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

No Si se copia en la tarjeta SD, funciona sin problemas.

Problema de RAM?

Entendería la limitación de hardware si la RAM estuviera llena, pero, mientras free -mveo videos, me da esto:

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

Parece que hay muchos disponibles ...

Dato interesante, como notó @goldilocks, los buffers son inusualmente bajos.

¿Problema de red?

Si estoy descargando un archivo de video manualmente con SFTP, mientras reproduzco este mismo archivo al mismo tiempo, funciona. Velocidad de descarga: ~ 1.5MB / s. Entonces, ni la red, ni el descifrado es un cuello de botella.

Otro problema?

Errores en el archivo de registro (con depuración de video, depuración ffmpeg), excepto depuración y avisos:

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

De acuerdo, curl no está optimizado para la transmisión de video. ¿Pero qué hay de SFTP? Debería ser pan comido.

Problema de configuración?

La última prueba anterior (caché de tarjeta sd) es interesante. Comienza a reproducir el video, después de descargar unos 150M (!) En la tarjeta sd ( .kodi/temp/filecache000.cache). Aunque funciona bien, no es una solución viable, ya que es demasiado lento para comenzar.

Parece intentar descargar la misma cantidad de RAM, ignorando la configuración advancedsettings.xml. Lo comprobé, el archivo se carga sin ningún problema. Este es un ejemplo de algo que probé ( .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: algunas de estas opciones ya no son correctas en kodi 17, consulte la respuesta de @ZacWolf para actualizar

Entonces, ¿alguien tiene alguna idea? ¿Qué podría estar mal aquí? Cualquiera sea la solución, también quiero saber por qué falla el uso normal (RAM buffer) en este caso.

EDITAR: Prueba en Archlinux

Instalé kodi en Archlinux, para determinar si es un problema de kodi u openelec. Es lo mismo: los videos HD son entrecortados, por lo que parece ser un error en kodi. Es más como un problema de protocolo (SFTP y WebDAV: http) porque mi prueba con SSHFS funciona muy bien. Desafortunadamente, no es trivial instalar SSHFS en openelec.

EDIT 2: una solución

Lo escribo aquí, porque no aborda directamente el problema del almacenamiento en búfer, pero he instalado kodi en Archlinux durante más de un año y funciona perfectamente bien. Es menos amigable para los novatos que openelec, pero para aquellos que estén interesados:

  • Instale Archlinux para ARM (muy fácil, solo siga la guía ; es para rpi1, para una más reciente, simplemente cambie la plataforma);
  • Instale Kodi ( siga la guía wiki de Archlinux , básicamente, instale el kodi-rbppaquete);
  • Habilitar el servicio Kodi Kodi se ejecute automáticamente en el arranque: # systemctl enable kodi.service;
  • Instalar SSHFS: pacman -Suy sshfs;
  • Utilice el muy útil montaje automático SSHFS con /etc/fstabpara montar su parte distante.

Hecho. No te olvides de actualizar con frecuencia ( pacman -Suy).


150 MB pueden estar en el lado alto, pero 5 MB es probablemente demasiado bajo para ~ 1 MB / s de contenido de velocidad de bits si desea evitar el entrecortado. Quitaría la paranoia sobre la tarjeta SD. Lo compraste para usar ¿verdad? Si no, será aún más seguro en un armario fresco y seco en algún lugar.
Ricitos de oro

Gracias por tu preocupación. Pero, tenga en cuenta que mi pregunta no es solo sobre el búfer sdcard. Segundo, 150M, a ~ 1MB / s ... Sí, 150s. Esto es absurdamente largo. ¿Existe una opción para cambiar el tamaño del búfer cuando se usa sdcard? Esto podría ser una solución. Luego, sea cual sea el tamaño del caché, cargará todo el video (a veces varios GB) en la tarjeta sd, no solo el búfer. Lo sé, las tarjetas SD son baratas. No es gran cosa. Lo sé. Pero, ¿por qué debería preocuparme por la tarjeta SD mientras la RAM debería estar funcionando?
Gui-Don

Lo siento, lo atenué un poco después de volver a mirarlo. No he usado Kodi, así que no puedo ser de mucha ayuda aquí, fue solo una observación general. En mi opinión, el almacenamiento en búfer en el disco es una mejor estrategia que el almacenamiento en búfer en la memoria RAM porque si llena la RAM al 100%, el sistema no tiene memoria caché en el disco, lo que afectará notablemente todos los aspectos de la operación. Sin embargo, si no llena la RAM y nada más lo hace, lo que está escribiendo (y leyendo simultáneamente) en el disco se colocará en la memoria caché del disco, es decir, RAM, pero el núcleo lo gestiona dinámicamente, que es lo que hace que esta sea una mejor estrategia.
Ricitos de oro

En caso de que eso no esté claro: el sistema operativo utiliza la mayor cantidad de RAM no comprometida posible para el almacenamiento en caché (me referí a esto anteriormente como "caché de disco", que es un nombre poco apropiado, pero enfatiza el hecho de que generalmente se trata principalmente de material que se lee con frecuencia del disco ) En el PI no sería inusual para que eso sea toda la memoria RAM no comprometida, esta es la cifra "buffers" de free- por lo que algo interesante en su puesto es el hecho de que este número es relativamente pequeño. Si aumenta el caché de disco de Kodi, ese número podría / debería aumentar mientras está en acción para igualarlo.
Ricitos de oro

1
Vi;) OK, entiendo que usar el disco es mejor que llenar la RAM. Es una buena solución para que funcione, si puedo reducir el tamaño de búfer necesario para reproducir el video. Por cierto, parece ser un porcentaje, en lugar de una cantidad absoluta. Aún así, tengo curiosidad por lo que sucede aquí. Es extraño que haya tanta RAM sin usar, incluso mientras el video está en búfer.
Gui-Don

Respuestas:


2

EDITAR (12/2017)

Kodi v17 renombrado y reubicado etiquetas en advancedsetting.xml

<cachemembuffersize> renombrado a <memorysize>

<readbufferfactor> renombrado a <readfactor>

Y se eliminaron de <network> y se agregaron a <cache>

Mi advanceettings.xml ahora se ve así:

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

Esto es específicamente para un dispositivo Vero4K, que tiene más memoria que un Pi, por lo que deberá ajustar esta configuración específica para su memoria disponible.
ZacWolf

1

Estoy ejecutando Pi 3 con OpenElec y también me encontré con muchos problemas de almacenamiento en búfer.

Lo estaba transmitiendo a través de Wi-Fi ya que pensé que estaba justo al lado del enrutador y no debería tener ningún problema. Bueno, después de conectarme a través de Ethernet, tuve que eliminar todo el archivo xml avanzado, ya que los problemas de almacenamiento en búfer se detuvieron.

Mi computadora portátil y mi teléfono funcionan bien a través de Wi-Fi sin almacenamiento en búfer, por lo que algo con el Wi-Fi incorporado de Pi 3 en OpenElec está causando el problema.


Me alegra que haya solucionado su problema y estoy seguro de que ayudará a muchas personas que se encontraron con este problema. Sin embargo, en mi caso usé Ethernet desde el principio. Para rpi1 no creo que esta sea la solución. Dicho esto, es extraño que haya tenido un problema similar en rpi3, ya que tiene el doble de RAM que rpi1 ... Puedo estar equivocado, pero parece que el manejo de caché en kodi es simplemente malo.
Gui-Don

-1

Tuve el mismo problema y usé este 'truco' , las cosas ahora funcionan sin problemas.

--- editar --- Siguiendo la sugerencia de @Simulant:

  • Instalar la herramienta de mantenimiento de xunity.
  • Ingresé al programa (no a la configuración), xunity - ajustes.
  • Seleccione 'Agregar 0 caché XML avanzado

1
Por favor, alinee los fakts clave de su fuente vinculada. De lo contrario, si la fuente vinculada se desconecta, su publicación sería inútil.
Simulante

1
¿No es Xunity solo una GUI para ese propósito? Quiero decir, ¿cómo es diferente de ajustar el archivo advancedsettings.xml yo mismo? En realidad, hice la configuración sin caché, es una forma lenta de cargar videos SFTP o webdav.
Gui-Don

Es una gui. Pero desde mi experiencia, la edición directa puede ser complicada (debido a permisos, etc.). El complemento funciona bien, lo usé :-)
Meir
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.