Optimizar OSMC/KODI para reproducción en LAN (parte 2)

En la entrega anterior vimos una parte de cómo optimizar Kodi para que la reproducción a través de nuestra red doméstica vaya mejor de lo que iba antes.

En mi caso esto no era suficiente, ya que seguía teniendo tirones para archivos de vídeo mayores de 900 megas (hoy en día casi cualquier archivo supera ese tamaño.

Para ello debemos prescindir del protocolo Samba y pasarnos al sistema NFS, o usar ambos si vamos a acceder a las carpetas que tengamos compartidas desde otros PC con windows. Si tenemos un servidor windows también podemos usar programas que nos ofrezcan esta funcionalidad, como por ejemplo FreeNFS (la última aztualización es del 2013) o haneWIN NFS Server. Personalmente no los he probado, así que no podría recomendar ninguno

Bueno, al meollo de la cuestión. Todo este post está orientado para ser realizado con Debian 8 en la parte del servidor y con OSMC en la parte de la raspberry pi 2, el cual está basado también en Debian. También debería funcionar en distribuciones ubuntu y sus variables, tanto en la versión cliente como en la versión del servidor.

Lo primero que tenemos que hacer es instalar el paquete NFS. En el cliente escribimos:

sudo apt-get install nfs-common

Pulsamos que  que queremos instalar los paquetes adicionales en caso de que los haya. Seguidamente, en la parte del servidor:

sudo apt-get install nfs-kernel-server nfs-common

Volvemos a indicar que instale las dependencias de los paquetes en caso de haberlas. Ya tenemos instalado en ambas partes los paquetes necesarios. Ahora trabajamos en la parte del servidor, mas concretamente en el archivo /etc/exports 

Indicamos la ruta de los directorios que queremos exportar y, como medida de seguridad adicional, a la ip que queremos exportarla (es decir, quién puede acceder a dichas carpetas). Por esta razón tengo puesta una ip fija en la raspberry. El archivo quedaría tal que así:


# /etc/exports: the access control list for filesystems which may be exported
# to NFS clients. See exports(5).
#
# Example for NFSv2 and NFSv3:
# /srv/homes hostname1(rw,sync,no_subtree_check) hostname2(ro,sync,no_subtree_check)
#
# Example for NFSv4:
# /srv/nfs4 gss/krb5i(rw,sync,fsid=0,crossmnt,no_subtree_check)
# /srv/nfs4/homes gss/krb5i(rw,sync,no_subtree_check)
#
/home/archivos_video 192.168.1.254(ro)
/home/public 192.168.1.254(rw)

Básicamente, las líneas que empiezan por # son comentarios. En la penúltima línea se indica que la ruta /home/archivos_video se «exporta» a la dirección ip 192.168.1.254 (la de mi raspberry) como sólo lectura (read only).

Seguidamente en la raspberry, los importamos editando el archivo /etc/fstab, quedando de la siguiente manera:

/dev/mmcblk0p1 /boot vfat defaults,noatime 0 0
/dev/mmcblk0p2 / ext4 defaults,noatime 0 0
192.168.1.192:/home/transmission/pelis /home/osmc/Movies nfs vers=3,udp,x-systemd.automount,noauto
192.168.1.192:/home/transmission/series /home/osmc/TVShows nfs vers=3,udp,x-systemd.automount,noauto
192.168.1.192:/home/transmission/documentales /home/osmc/Documentals nfs vers=3,udp,x-systemd.automount,noauto
192.168.1.192:/home/public/temp /home/osmc/.kodi/temp nfs vers=3,udp,x-systemd.automount

Las dos primeras líneas vienen por defecto. En las líneas 3,4,5 y 6 estoy montando los directorios que estoy exportando en unas carpetas previamente creadas. Paso a explicar qué es cada opción de las líneas del archivo:

  • 192.168.1.192:/home/transimision…..: La ruta remota que hemos compartido a través de NFS
  • nfs: Probablemente el parámetro más obvio. Estamos indicando el sistema de archivos a usar
  • vers=3La versión a usar del protocolo NFS. En este caso la 3. No hemos cogido la 4 porque hay opciones que no nos interesan y complicarían la configuración ligeramente. Para más información podéis leer el artículo de la wikipedia.
  • udp: Pese a que UDP no está orientado a conexión y no tiene reenvío de tramas erróneas, lo vamos a elegir porque es el que mayor tasa de transferencia nos da. A mi no me ha dado ningún problema. Más abajo tenéis una tabla donde se indica el resultado de diferentes pruebas cliente-servidor realizados en mi red interna.
  • noauto: esto hará que el montaje no se realice ni cuando se inicia el sistema ni cuando ejecutamos mount -a.
  • x-systemd.automount: El montaje se realizará la primera vez que se accede a los datos (por lo que evitaremos el error de device not found que da al inicio, pues se intenta montar antes de que esté disponible la tarjeta de red). Hay una línea que no tiene la opción de noauto y, aunque dará error al iniciar OSMC, se montará igualmente. Esto lo he puesto así porque me interesa que se monte cuanto antes. Suele ir en conjunción con noauto.

noauto x-systemd.automount en la misma línea básicamente indica al sistema que se monte el directorio bajo demanda.

Prueba 1

Montando a pelo con el comando: sudo mount.nfs 192.168.1.192:/home/public /home/osmc/temporal/

El montaje queda: 192.168.1.192:/home/public on /home/osmc/temporal type nfs4 (rw,relatime,vers=4.0,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=192.168.1.254,local_lock=none,addr=192.168.1.192)

Sequential Output Sequential Input Random
Per chr Block Rewrite Per chr Block Seeks
K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec K/sec /sec %CP
154 97 11257 5 5147 6 508 99 11806 5 161.5 18
259ms 6606ms 6788ms 33374us 443ms 1955ms
Sequential create Random create
Create Read Delete Create Read Delete
/sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
21 1 2587 9 197 8 21 1 1815 23 791 21
348ms 1008ms 11378ms 433ms 5781us 269ms

Prueba 2

Modificación en fstab192.168.1.192:/home/public /home/osmc/temporal nfs vers=3,udp

El montaje queda: 192.168.1.192:/home/public on /home/osmc/temporal type nfs (rw,relatime,vers=3,rsize=32768,wsize=32768,namlen=255,hard,proto=udp,timeo=11,retrans=3,sec=sys,mountaddr=192.168.1.192,mountvers=3,mountport=49609,mountproto=udp,local_lock=none,addr=192.168.1.192)

Sequential Output Sequential Input Random
Per chr Block Rewrite Per chr Block Seeks
K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec K/sec /sec %CP
157 97 11596 5 5554 7 525 99 11674 6 115.2 14
258ms 5168ms 5931ms 34241us 44100us 3154ms
Sequential create Random create
Create Read Delete Create Read Delete
/sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
21 1 12000 28 1285 19 21 1 2051 23 1680 20
349ms 81877us 264ms 344ms 9133us 54287us

Prueba 3

Modificación en fstab192.168.1.192:/home/public /home/osmc/temporal nfs vers=3,rsize=8192,wsize=8192,udp,retrans=2.

El montaje queda: 192.168.1.192:/home/public on /home/osmc/temporal type nfs (rw,relatime,vers=3,rsize=8192,wsize=8192,namlen=255,hard,proto=udp,timeo=11,retrans=2,sec=sys,mountaddr=192.168.1.192,mountvers=3,mountport=49609,mountproto=udp,local_lock=none,addr=192.168.1.192)

Sequential Output Sequential Input Random
Per chr Block Rewrite Per chr Block Seeks
K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec K/sec /sec %CP
158 97 11362 5 5487 9 525 98 11430 9 138.7 16
261ms 5146ms 5791ms 31337us 81089us 5215ms
Sequential create Random create
Create Read Delete Create Read Delete
/sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
21 1 12067 27 1291 18 21 1 2005 24 1653 22
403ms 84253us 247ms 1064ms 10077us 7101us

Optimizar OSMC/KODI para reproducción en LAN (parte 1)

Muchos en casa tenemos un pequeño NAS o algún PC antiguo que nos hace de servidor (torrent, owncloud, apache, etc..) con carpetas compartidas para poder acceder a los archivos de vídeo que tenemos en el servidor.

Por desgarcia, el método normal que todo el mundo conoce de compartir archivos (mediante samba) no es eficiente y produce cortes en archivos de video muy pesados (también de audio).

En esta serie de artículos escribiré las configuraciones que tengo en casa y los pasos para llevarlas a cabo, ya que desde que lo tengo así configurado me va muy bien, llegando a  reproducir a la perfección archivos de 30 gigas.

Configuración de KODI v16

Esta configuración es válida para KODI v16, puesto que en el 17 cambiarán las etiquetas.

Este paso es el más obvio, pues el que más se recomienda tanto en foros como en blogs especializados.

Consiste en editar el archivo advancedsettings.xml que se encuentra en la ruta /home/osmc/.kodi/userdata/

Copio y pego parte del contenido (el que nos interesa en esta sección) de mi archivo y pongo una breve descripción de qué hace cada cosa.


<advancedsettings>
 <network>
  <cachemembuffersize>104857600</cachemembuffersize>
  <readbufferfactor>3</readbufferfactor>
  <buffermode>0</buffermode>
 </network>
</advancedsettings>

  • cachemembuffersize: Son los bytes de memoria RAM que se usarán para almacenar la cache de lo que vayamos a reproducir. Si se pone un 0, se usará todo el espacio disponible en el disco como cache. En esta configuración discrepo, ya que, cuando usamos Pulsar, por ejemplo, el archivo de vídeo se descarga entero a la tarjeta de memoria si o si. En otro artículo veremos como cambiar la ubicación de la cache para alargar la vida de nuestra tarjeta microSD.
  • readbufferfactor: Factor que multiplica lo que guarda de vídeo respecto a lo que estás viendo. EL valor 1 guarda un poco más. El 2 el doble de ese valor etc. Por defecto es 4. Cuanto mayor valor, mayor ancho de banda.
  • buffermode: Aquí va un valor desde 0 a 3. Estos valores son lo siguiente:
    • 0: Forzar el uso del buffer en todos los sistemas de archivos de Internet ( como “2” pero añadiendo también ftp,webdav,etc) Opción por defecto.
    • 1: Forzar el uso del buffer en todos los sistemas de archivos (incluyendo el local).
    • 2: Usar solo el buffer en los sistemas de archivos de Internet de streaming (http,etc).
    • 3: No usar el buffer bajo ningún concepto.

Configuración de KODI v17

En la siguiente versión de Kodi, las etiquetas del archivo advancedsettings.xml quedarían de la siguiente forma:


<advancedsettings>
 <cache>
  <memorysize>104857600</memorysize>
  <readfactor>3</readfactor>
  <buffermode>0</buffermode>
 </cache>
</advancedsettings>

En esta versión cambia el parámetro cachemembuffersize por memorysize readbufferfactor por readfactor, siendo exactamente los mismo parámetros que antes, solo que mejor organizados y cambiados de la sección network a la sección cache.

En el siguiente artículo se verá cómo mejorar la velocidad de transferencia entre nuestro servidor y la raspberry mediante el cambio de sambaNFS y su posterior montaje en local. Aunque estará dedicado a servidores Linux, también se puede usar Windows como un servidor NFS con software de terceros.