Buenas a tod@s, he mirado en el foro pero no he encontrado nada respecto a mi duda y por eso he abierto este nuevo hilo, mi pregunta es cual de los dos protocolos seria mas eficiente y mejor para un servidor multimedia en una raspberry pi 3 conectada al router por cable, con el contenido multimedia almacenado en un hdd mecánico externo por usb y transmitiendo el contenido multimedia del hdd al cliente en este caso Jellyfin por wifi. He oído que es mejor Dlna que samba para este caso, otros dicen que es mas rápido samba que el Dlna, mucha gente dice que samba las películas de lato bitrate le van a saltos o directamente no reproducen el contenido, el caso es que no se que hacer y por eso os comento mi problema para ver si alguien que entienda del tema me aconseje.
Gracias por responder, pero a que te refieres con tener bien configurada la rpi 3, hay que tocarle ha algo especifico o algo?
Samba y DLNA son dos protocolos distintos, el primero es de uso general para compartir el contenido de unidades de almacenamiento e impresoras, el segundo para compartir únicamente ficheros multimedia: fotos, música y vídeos.
Yo he montado en Linux Mint, miniDLNA, es muy sencillo de configurar, ahora estoy probando otro que no recuerdo, pero emito directo a mi TV, no uso ningún reproductor.
depende principalmente de las capacidades de los clientes
samba es un protocolo para compartir ficheros, asi que el cliente tiene que ser capaz de interpretar el fichero multimedia, tanto a nivel software como hardware y la red tiene que permitir que se transfiera el fichero de forma fluida
dlna es un protocolo para compartir contenido multimedia, asi que el cliente y el servidor negocian sus capacidades y en un principio el servidor se ha de adaptar a lo que puede hacer el cliente, el problema es que una raspberry 3 no puede adaptarse con todos los contenidos a todos los clientes
Creo que algo no he entendido de tu mensaje.
Si vas a reproducir el contenido via Jellyfin, y el servidor de Jellyfin está instalado en la misma raspberry pi, no necesitas ni samba ni dlna para enviar el contenido al cliente, todo se hace internamente desde la aplicación, o así creo recordar que lo monté yo.
Creo que lo que más cuello de botella te va a hacer es el usb del hdd externo en caso de que no necesites recodificar los vídeos, y se envíen en su códec nativo al cliente.
Si tienes que recodificarlos, el problema será la CPU de la Pi, que dependiendo de resolución y FPS igual no aguanta tanto tute.
El único sentido que le veo a querer tener samba/dlna en el hdd de origen es si quieres sincronizarlo con otro disco en red (de un pc en el que te bajes el contenido, por ejemplo). En ese caso yo tiraría por samba, es fácil y muy compatible y la velocidad realmente te da igual, no necesitas que se transfiera en tiempo real.
La cosa es que si montas DLNA, no necesitas Jellyfin para reproducir, no?
#10 Si, en jellyfin se puede usar el protocolo dlna por eso lo preguntaba, al final me he decidido por dlna, haciendo pruebas me ha sucedido algo curioso, las películas de bajo bitrate sin transcodificar por wifi las reproduce sin problemas, la de alto bitrate se cortan o van a tirones, sin embargo si lo reproduzco esa misma del alto bitrate en un iPhone 6 antiguo con el cliente infuse por dlna y la película se ve perfecta, puede ser que el cuelllo de botella sea jellyfin?, porque no creo que un iphone 6 tenga mas potencia que un pc, ya que también hice la prueba de reproducirlo en un pc de gama alta con el cliente jellyfin de escritorio por cable y también iba a tirones, mi conexión cableada no es gigabit pero debería ir bien no?, es muy extraño.
#11 lo que se me ocurre así a bote pronto es que el iphone sea capaz de tragarse el códec original y el otro cliente no, y por lo tanto tenga que transcodificar.
Haz un htop en la pi mientras mandas la peli al iphone, y mientras mandas la peli al otro cliente. Mira a ver si hay diferencia en los consumos de cpu. Si ves que en el cliente que no es iphone la CPU se dispara, ya tienes localizado el problema.
Lo que es más coñazo es solucionarlo: transcodificar las pelis con antelación a un códec que el cliente pueda leer sin que haga falta recodificar en el momento de reproducción. No lo haría como parte del workflow de Jellyfin porque en una raspberry Pi como te pongas a recodificar pelis vas a tardar un buen rato, yo lo haría en otro pc si tienes uno más potente y luego lo pasas al disco compartido con Jellyfin ya en el códec apropiado.
#12 Gracias, probaré eso que me dices de la cpu a ver si es de los códecs y la transcodificación, la parte buena es que parece que no es por problema de velocidad del router o del hhd externo.
#12 Acabo e realizar las pruebas y no es de la cpu. El resultado después de las pruebas es el siguiente:
En el iphone con el cliente infuse lo reproduce sin problemas y la cpu estable y la memoria ram igual.
En una table con android y el cliente emby me sucede lo mas raro unas veces va bien y otra a tirones en ambos casos con la cpu y la ram estables y sin subidas altas.
En un chromecast google tv 4k conectado a un receptor av por hdmi y este a su vez conectado al tv por hdmi también y con el cliente jellyfin va a tirones siempre y la cpu y la ram estables.
Cómo has montado jellyfin? Docker?
Cómo está configurado el playback, haces transcoding o directstream? Por cómo está la CPU de la raspi siendo usada, todo apunta a que es directstream y por eso obtienes resultados dispares, porque cada cliente tiene sus capacidades. La aceleración por hardware en jellyfin funciona regulín en la versión docker, por si lo tienes montado así.
#15 No lo tengo por docker, las transcodificaciones las tengo desactivadas ya que la pi3 no tendría potencia para realizarlas, seguramente sea un tema de códecs pero en los audios o el USB del disco externo como comento un compañero por aqui, es la única lógica que le veo, aunque no estoy muy seguro.