Gabi92 1 Posted August 17 Posted August 17 Hi there. Since few weeks i´ve started noticing that outside my house there are some films and series that don´t reproduce on TVs. One of them is grand torino and if i try to play it in my house nuc everything works ok but on my parent´s in law tv it shows the loading screen and after that it show an error like: can´t reproduce right now because there is no streams available. In the other hand, few movies that work or don´t, shows trailers that aren´t even related before playing the actual movie/series. How can i get rid of it? I attach the emby logs so you can see it. Thank you in advance. hardware_detection-63922575201.txt ffmpeg-transcode-9c8fc3b3-df21-448a-9c00-dafb9b70b21a_1.txt embyserver-63922575189.txt
vdatanet 1661 Posted Monday at 01:04 PM Posted Monday at 01:04 PM As far as I know, LG TVs don't support PGS subtitles. If that's what you're using, the server has to burn them into the video, which forces a transcode — and if your server doesn't have enough horsepower for that, playback just hangs. Try a different subtitle format (SRT/ASS) and see if it plays fine.
Gabi92 1 Posted yesterday at 06:00 AM Author Posted yesterday at 06:00 AM The server has a rtx A2000 with a dedicated ssd to transcode, this is not the issue as it works well in mobile while doing transcode. The movie also is being played without subtitles, i´ve tried also with the forced ones
vdatanet 1661 Posted yesterday at 06:04 AM Posted yesterday at 06:04 AM So, there's something wrong: >>>>>> Processing Plan Name CanDoInHW WillDoInHW Reason Automatic software decoder >> False False Software Codec VideoInput >> False False Not a hardware decoder SubtitleOverlay >> False False VideoOutput >> False False Not a hardware encoder x264 >> False False Software Codec 14:53:13.898 Stream #0:1(spa): Audio: ac3, 48000 Hz, 5.1(side), fltp, 384 kb/s (default) 14:53:13.912 elapsed=00:00:00.42 frame= 1 fps=0.0 q=0.0 size=N/A time=00:00:00.00 bitrate=N/A throttle=off speed= 0x 14:53:14.411 elapsed=00:00:00.94 frame= 19 fps=0.0 q=28.0 size=N/A time=00:00:00.73 bitrate=N/A throttle=off speed=0.776x 14:53:14.936 elapsed=00:00:01.45 frame= 31 fps= 21 q=28.0 size=N/A time=00:00:01.24 bitrate=N/A throttle=off speed=0.858x 14:53:15.451 elapsed=00:00:02.00 frame= 44 fps= 22 q=28.0 size=N/A time=00:00:01.76 bitrate=N/A throttle=off speed=0.877x 14:53:15.999 elapsed=00:00:02.55 frame= 61 fps= 24 q=28.0 size=N/A time=00:00:02.52 bitrate=N/A throttle=off speed=0.988x 14:53:16.535 elapsed=00:00:03.10 frame= 76 fps= 25 q=28.0 size=N/A time=00:00:03.23 bitrate=N/A throttle=off speed=1.04x 14:53:17.125 [segment @ 0x393a2cc0] Opening '/var/lib/emby/transcoding-temp/51A997/51A997.m3u8.tmp' for writing 14:53:17.126 SegmentComplete=video:0 Index=26 Start=0.000000 End=81.039378 Duration=81.039378 offset_pts=0 start_pts=0 Frames=72 filename=51A997_26.ts 14:53:17.132 [segment @ 0x393a2cc0] Opening '/var/lib/emby/transcoding-temp/51A997/51A997_27.ts.tmp' for writing 14:53:17.133 elapsed=00:00:03.62 frame= 90 fps= 25 q=28.0 size=N/A time=00:00:03.74 bitrate=N/A throttle=off speed=1.03x 14:53:17.348 subtitle_kickoff: resend - pts: 82374 14:53:17.353 subtitle_kickoff: call subtitle_resend_current 82384 frame->format: 1 14:53:17.573 elapsed=00:00:04.14 frame= 101 fps= 24 q=28.0 size=N/A time=00:00:04.06 bitrate=N/A throttle=off speed=0.981x 14:53:18.131 elapsed=00:00:04.65 frame= 111 fps= 24 q=28.0 size=N/A time=00:00:04.54 bitrate=N/A throttle=off speed=0.977x 14:53:18.598 elapsed=00:00:05.16 frame= 122 fps= 24 q=28.0 size=N/A time=00:00:05.02 bitrate=N/A throttle=off speed=0.972x 14:53:19.122 elapsed=00:00:05.69 frame= 134 fps= 24 q=28.0 size=N/A time=00:00:05.53 bitrate=N/A throttle=off speed=0.972x 14:53:19.645 elapsed=00:00:06.20 frame= 150 fps= 24 q=28.0 size=N/A time=00:00:06.11 bitrate=N/A throttle=off speed=0.985x 14:53:20.044 [segment @ 0x393a2cc0] Opening '/var/lib/emby/transcoding-temp/51A997/51A997.m3u8.tmp' for writing
Gabi92 1 Posted yesterday at 06:16 AM Author Posted yesterday at 06:16 AM 10 minutes ago, vdatanet said: So, there's something wrong: >>>>>> Processing Plan Name CanDoInHW WillDoInHW Reason Automatic software decoder >> False False Software Codec VideoInput >> False False Not a hardware decoder SubtitleOverlay >> False False VideoOutput >> False False Not a hardware encoder x264 >> False False Software Codec 14:53:13.898 Stream #0:1(spa): Audio: ac3, 48000 Hz, 5.1(side), fltp, 384 kb/s (default) 14:53:13.912 elapsed=00:00:00.42 frame= 1 fps=0.0 q=0.0 size=N/A time=00:00:00.00 bitrate=N/A throttle=off speed= 0x 14:53:14.411 elapsed=00:00:00.94 frame= 19 fps=0.0 q=28.0 size=N/A time=00:00:00.73 bitrate=N/A throttle=off speed=0.776x 14:53:14.936 elapsed=00:00:01.45 frame= 31 fps= 21 q=28.0 size=N/A time=00:00:01.24 bitrate=N/A throttle=off speed=0.858x 14:53:15.451 elapsed=00:00:02.00 frame= 44 fps= 22 q=28.0 size=N/A time=00:00:01.76 bitrate=N/A throttle=off speed=0.877x 14:53:15.999 elapsed=00:00:02.55 frame= 61 fps= 24 q=28.0 size=N/A time=00:00:02.52 bitrate=N/A throttle=off speed=0.988x 14:53:16.535 elapsed=00:00:03.10 frame= 76 fps= 25 q=28.0 size=N/A time=00:00:03.23 bitrate=N/A throttle=off speed=1.04x 14:53:17.125 [segment @ 0x393a2cc0] Opening '/var/lib/emby/transcoding-temp/51A997/51A997.m3u8.tmp' for writing 14:53:17.126 SegmentComplete=video:0 Index=26 Start=0.000000 End=81.039378 Duration=81.039378 offset_pts=0 start_pts=0 Frames=72 filename=51A997_26.ts 14:53:17.132 [segment @ 0x393a2cc0] Opening '/var/lib/emby/transcoding-temp/51A997/51A997_27.ts.tmp' for writing 14:53:17.133 elapsed=00:00:03.62 frame= 90 fps= 25 q=28.0 size=N/A time=00:00:03.74 bitrate=N/A throttle=off speed=1.03x 14:53:17.348 subtitle_kickoff: resend - pts: 82374 14:53:17.353 subtitle_kickoff: call subtitle_resend_current 82384 frame->format: 1 14:53:17.573 elapsed=00:00:04.14 frame= 101 fps= 24 q=28.0 size=N/A time=00:00:04.06 bitrate=N/A throttle=off speed=0.981x 14:53:18.131 elapsed=00:00:04.65 frame= 111 fps= 24 q=28.0 size=N/A time=00:00:04.54 bitrate=N/A throttle=off speed=0.977x 14:53:18.598 elapsed=00:00:05.16 frame= 122 fps= 24 q=28.0 size=N/A time=00:00:05.02 bitrate=N/A throttle=off speed=0.972x 14:53:19.122 elapsed=00:00:05.69 frame= 134 fps= 24 q=28.0 size=N/A time=00:00:05.53 bitrate=N/A throttle=off speed=0.972x 14:53:19.645 elapsed=00:00:06.20 frame= 150 fps= 24 q=28.0 size=N/A time=00:00:06.11 bitrate=N/A throttle=off speed=0.985x 14:53:20.044 [segment @ 0x393a2cc0] Opening '/var/lib/emby/transcoding-temp/51A997/51A997.m3u8.tmp' for writing Which movie is it? We´ve played several and the issue was with Gran Torino.
vdatanet 1661 Posted yesterday at 06:18 AM Posted yesterday at 06:18 AM Your log: {"Chapters":[],"Protocol":"File","Id":"mediasource_392391","Path":"/discos/Series/Series/E/Euphoria (2019) [tvdb=360261]/Temporada 1/1080p/1x01 - [1] - Piloto.mkv","Type":"Default","Container":"mkv","Size":3904650596,"Name":"1x01 - [1] - .....
Gabi92 1 Posted yesterday at 06:19 AM Author Posted yesterday at 06:19 AM Euphoria was fine, maybe there was an issue while playing with teh A2000 but it plays fine
vdatanet 1661 Posted yesterday at 06:21 AM Posted yesterday at 06:21 AM This is the only log you posted.
Gabi92 1 Posted yesterday at 06:32 AM Author Posted yesterday at 06:32 AM Give me a second, i´m asking them to reproduce the movie
Gabi92 1 Posted yesterday at 07:42 AM Author Posted yesterday at 07:42 AM Hi there. Here are the logs, movie won´t reproduce and only "ads" will appear. It only play´s trailers that aren´t even related. Logs.zip
vdatanet 1661 Posted yesterday at 07:52 AM Posted yesterday at 07:52 AM Gran Torino: 08:59:19.040 /discos/Peliculas/Pelis/G/Gran Torino (2008) [tmdb=13223] 1080p.mkv: Stale file handle Resumen Problema principal: Stale file handle (error ESTALE de Linux) al acceder a /discos/Peliculas/Pelis/G/Gran Torino (2008)...mkv. No es un fallo de transcodificación: ffmpeg muere en menos de un segundo, antes siquiera de leer el archivo. Secuencia del log: Intenta transcodificar por hardware (NVDEC VC-1 → NVENC H.264 en la A2000) → falla en 0,8 s. Emby interpreta mal la causa y hace fallback a software. Reintenta con x264 → falla igual en 2 ms. La línea del fallback es ruido: el hardware está bien configurado. Solución: desde el host (y el contenedor si aplica), comprobar y remontar: ls /discos/Peliculas mount | grep discos umount -l /discos && mount -a Si es NFS, revisar el servidor (exportfs -ra) y montar con hard,intr en vez de soft. Después reiniciar Emby, porque mantiene handles abiertos al montaje antiguo. Dos detalles secundarios: Límite de bitrate remoto de 5 Mbps para el usuario Angel, con un archivo VC-1 a 29,7 Mbps: siempre transcodificará. Si la TV de los suegros está en la red local, conviene marcarla como tal para saltarse el límite. Parámetros de encoder alterados: preset superfast y CRF 35 en lugar de veryfast/23. Ese CRF da una calidad bastante pobre; con NVENC funcionando ya no hace falta.
Gabi92 1 Posted yesterday at 08:20 AM Author Posted yesterday at 08:20 AM Fixed nfs problem, now you can see it in the logs. About the limit, it was done in purpose and they are outside the lan network. Logs.zip
vdatanet 1661 Posted yesterday at 08:27 AM Posted yesterday at 08:27 AM Ahora el log parece correcto, ¿que sucede exactamente?. ¿Solo reproduce trailers no relacionados?
vdatanet 1661 Posted yesterday at 08:39 AM Posted yesterday at 08:39 AM Resumen 1. Los trailers: Cinema Mode Tienes activo el plugin Emby.Server.CinemaMode 1.0.50 junto con Trailers. En el log se ve antes de la película: 10:11:29 Playback start ... "Un gran viaje atrevido y maravilloso" 10:11:31 Playback stopped ... "Eleanor the Great" 10:11:35 Playback start ... "Gran Torino" Es exactamente lo que reporta el usuario: trailers sin relación con la película elegida. Es el comportamiento previsto de Cinema Mode (pre-rolls tipo cine) y se desactiva en Plugins → Cinema Mode. 2. Por qué no arranca después: bucle de seek La película sí empieza — los segmentos 0 a 12 se sirven bien. Entonces: 10:11:38.977 Starting transcoding because segmentGap is 641 and max allowed gap is 8. requestedIndex=664 La TV salta al segmento 664 (= 33:12, probablemente una posición de reanudación). Emby mata ffmpeg y lanza otro con -ss 00:33:12. A partir de ahí, bucle: ocho intentos idénticos, cada uno terminando con exit 137 (SIGKILL) tras ~10.300 ms. La TV espera exactamente 10 segundos, no recibe el segmento, desconecta y lo vuelve a pedir; eso mata el ffmpeg y el siguiente empieza de cero. Nunca llega a producirlo. Pantalla negra hasta que la sesión muere sola a las 10:14. Por qué el seek tarda más de 10 segundos El almacenamiento va muy lento. En el mismo log: SubtitleEncoder: Subtitle extraction took 289,348ms 289 segundos para extraer un SRT interno de 47 KB. Leer el archivo de 26 GB hasta el minuto 33 es inviable a esa velocidad. Había un escaneo de biblioteca en marcha (ValidatePhysicalRoots, decenas de consultas a TMDb y ffprobe entre las 10:10 y 10:11), compitiendo por la misma E/S. Solo 2 vCPU (Processor count: 2). Aunque NVENC haga el trabajo pesado, el demux y el segmentado son CPU. Qué hacer, por orden de impacto Desactivar Cinema Mode. Medir /discos: dd if=/discos/Peliculas/... of=/dev/null bs=1M count=2000. Si es NFS, revisar rsize/wsize y que no esté montado soft. Es el problema de fondo, el mismo que causó el Stale file handle anterior. Mover los escaneos de biblioteca a la madrugada y desactivar el monitoreo en tiempo real. Subir el contenedor a 4 vCPU como mínimo. Probar sin la posición de reanudación: marcar como no vista y reproducir desde el principio. Si funciona, confirma que el problema es el seek. Secundario Plugin ScripterX roto: lanza NullReferenceException en cada evento de progreso (150+ excepciones en dos minutos). Actualizarlo o quitarlo. Error de resolución de nombres en /discos/Peliculas/Pelis/H y /W: bug de Emby en VideoListResolver, normalmente disparado por archivos de versiones múltiples mal nombrados. A medio plazo: este archivo es el peor caso posible — remux Blu-ray VC-1 de 29,7 Mbps con límite remoto de 5 Mbps. Reencodarlo a H.264/HEVC a 8-10 Mbps eliminaría todos estos problemas de golpe.
Gabi92 1 Posted 2 hours ago Author Posted 2 hours ago I´ve fixed few issues related to nfs and now it works fine, here is how it´s being mounted: /Peliculas on /discos/Peliculas type nfs4 (ro,nosuid,nodev,noexec,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.1.247,local_lock=none,addr=192.168.1.252,user,_netdev) The speed shouldn´t be an issue also: dd if=/discos/Peliculas/Pelis/G/Gran\ Torino\ \(2008\)\ \[tmdb\=13223\]\ 1080p.mkv of=/dev/null bs=1M count=2000 2000+0 records in 2000+0 records out 2097152000 bytes (2,1 GB, 2,0 GiB) copied, 10,3508 s, 203 MB/s I´ve disabled the real time monitoring and library scans, unisntalled scripterX. They have tried and the movie reproduces fine since start but if they try to go fordwards or backwards few seconds/mins it breaks and stop reproducing. Logs.zip
vdatanet 1661 Posted 1 hour ago Posted 1 hour ago Emby seek failure — summary What's already fixed Compared to the earlier logs, this session is clean: no Cinema Mode trailers, no ScripterX exceptions, no library scan running, no subtitle extraction. All three playback starts from position 0 work perfectly — NVDEC/NVENC on the A2000, ~16x realtime. What's still failing: seeking I tabulated all nine ffmpeg processes by seek offset and time to first frame (Output #0 ffmpeg -ss segment Time to first frame 502623 — (start) 0 0.11 s 8566cd — (start) 0 0.11 s ec8167 — (start) 0 0.24 s 8cf2e1 00:01:39 33 3.86 s 628a12 00:10:30 210 killed at 10 s 174bd3 00:10:30 210 killed at 7 s ee0dc3 00:21:30 430 killed at 10 s f083f6 00:21:30 430 killed at 9 s 9c9f51 00:33:30 670 killed at 9.6 s ee36e8 00:33:30 670 killed at 7.9 s Seek time scales with how far into the file you jump. A jump to 1:39 takes 3.86 s and barely makes it; anything past ~10 minutes never arrives in time. Key detail: in the failing logs, ffmpeg opens and probes the file normally in ~0.93 s (identical to the working ones), prints the stream mapping, and then goes silent: 09:49:43.112 Stream mapping: 09:49:43.112 Stream #0:0 -> #0:0 (vc1 (vc1_cuvid) -> h264 (h264_nvenc)) 09:49:43.112 Stream #0:1 -> #0:1 (copy) 09:49:43.112 Press [q] to stop, [?] for help [nothing more — SIGKILL 9 seconds later] No Output #0, no frames. Opening the file is fine; positioning inside it is what's slow. The LG app waits exactly 10 seconds, then kills ffmpeg and re-requests — the loop we saw before. Why Running the numbers on the one good data point: 1:39 at 29.7 Mbps is ~368 MB into the file, covered in 3.86 s ≈ 95 MB/s. At that rate, 10:30 (2.3 GB) would need ~24 s and 33:30 (7.5 GB) ~78 s. That matches the observed failures exactly. So ffmpeg appears to be reading the file linearly to reach the seek point instead of jumping directly. Two possible causes: The MKV has no Cues index. Without Cues, the Matroska demuxer walks clusters until it finds the target. The file is from 2017, muxed with libebml 1.3.4 + libmatroska 1.4.5 and no writing-application tag, which is unusual. Storage is slow at random access. 95 MB/s is about the ceiling of a spinning disk or a gigabit network mount. How to tell them apart # 1. Does the file have an index? mkvinfo "/discos/Peliculas/Pelis/G/Gran Torino (2008) [tmdb=13223] 1080p.mkv" | grep -i -E "cue|seek head" # 2. How long does a real seek take? time /opt/emby-server/bin/ffmpeg -ss 00:33:30 \ -i "/discos/Peliculas/Pelis/G/Gran Torino (2008) [tmdb=13223] 1080p.mkv" \ -frames:v 1 -f null - 2>/dev/null # 3. Is random-access read OK? time dd if="/discos/Peliculas/Pelis/G/Gran Torino (2008) [tmdb=13223] 1080p.mkv" \ of=/dev/null bs=1M skip=7000 count=200 If dd with skip=7000 returns in under a second but ffmpeg takes a minute, it's the index. If dd is also slow, it's the disk. Fixes If it's the index, rebuild it losslessly, no re-encode: mkvmerge -o "Gran Torino (2008) [tmdb=13223] 1080p.fixed.mkv" \ "Gran Torino (2008) [tmdb=13223] 1080p.mkv" A few minutes of copying and seeks become instant. Worth trying first — cheap and reversible. Either way, this file remains the worst case: 26 GB of VC-1 at 29.7 Mbps against a 5 Mbps remote limit, so it always transcodes and always runs near the timeout. Re-encoding to H.264 or HEVC at 8–10 Mbps would bring it to ~7 GB: less data to traverse on a seek, and possibly direct play. With the A2000, an NVENC pass is about ten minutes. Still outstanding: Processor count: 2. Every retry spawns a new ffmpeg while the previous one is still dying, and two cores don't help. Four vCPUs would give some headroom in those critical seconds.
Gabi92 1 Posted 43 minutes ago Author Posted 43 minutes ago Here is all the info: Mkvinfo: |+ Seek head (subentries will be skipped) size 86 data size 81 Seek rate: time /opt/emby-server/bin/ffmpeg -ss 00:33:30 -i "/discos/Peliculas/Pelis/G/Gran Torino (2008) [tmdb=13223] 1080p.mkv" -frames:v 1 -f null - 2>/dev/null real 0m0,002s user 0m0,000s sys 0m0,002s Random-access: time dd if="/discos/Peliculas/Pelis/G/Gran Torino (2008) [tmdb=13223] 1080p.mkv" of=/dev/null bs=1M skip=7000 count=200 200+0 records in 200+0 records out 209715200 bytes (210 MB, 200 MiB) copied, 0,0228371 s, 9,2 GB/s real 0m0,026s user 0m0,000s sys 0m0,025s I´ve added two extra cores
vdatanet 1661 Posted 38 minutes ago Posted 38 minutes ago Thanks — but neither of those two tests actually measured what we need. Here's what they show: The ffmpeg seek test didn't run. real 0m0.002s is 2 milliseconds. A process can't even start that fast, let alone open a 26 GB file and decode a frame. It errored out immediately and the 2>/dev/null hid the message. Most likely the path didn't resolve in that shell — were you on the Proxmox host rather than inside the Emby container? Please re-run it without discarding stderr. The dd test read from RAM, not disk. 9.2 GB/s is faster than any NVMe drive on the market (Gen4 tops out around 7 GB/s). That's the page cache serving a file that was already warm — probably from your own earlier ffmpeg attempt. It tells us nothing about a cold read. The mkvinfo output is inconclusive. I only see the Seek head line; no Cues element appeared. That may mean the index is genuinely missing (which would explain everything), or it may mean the output got cut. I need the full top-level element list. Could you re-run these, inside the Emby container: FILE="/discos/Peliculas/Pelis/G/Gran Torino (2008) [tmdb=13223] 1080p.mkv" # 1. Full element list — I'm looking for whether "Cues" is present mkvinfo "$FILE" | head -40 # 2. Seek timing at several depths, errors visible for t in 00:00:10 00:01:39 00:10:30 00:33:30; do echo "== $t" time /opt/emby-server/bin/ffmpeg -hide_banner -v error \ -ss $t -i "$FILE" -frames:v 1 -f null - done # 3. Cold read, bypassing cache dd if="$FILE" of=/dev/null bs=1M skip=7000 count=200 iflag=direct One more test, and it may be the answer If it turns out the storage is genuinely fast, then the index isn't the problem and I'd suspect the NVDEC VC-1 decoderinstead. Seeking with vc1_cuvid is a known weak spot — the hardware decoder can stall for a long time before emitting the first frame after a seek, and it wouldn't show up when starting from position 0. This isolates it — same seek, software decode vs. the exact hardware path Emby uses: # software decode time /opt/emby-server/bin/ffmpeg -hide_banner -v error \ -ss 00:33:30 -i "$FILE" -frames:v 1 -f null - # hardware decode, exactly as Emby invokes it time /opt/emby-server/bin/ffmpeg -hide_banner -v error \ -init_hw_device cuda=cuda:0 -f matroska,webm -ss 00:33:30 \ -c:v vc1_cuvid -hwaccel cuda -hwaccel_output_format cuda \ -i "$FILE" -frames:v 1 -f null - If the first is fast and the second is slow, the fix is simple: in Transcoding settings, turn off hardware decoding for VC-1 while leaving NVENC encoding on. You lose a little decode efficiency on this one codec and get working seeks. And the thing you didn't mention You added two cores — thanks. But you didn't say whether seeking behaves any differently now. That's the most important piece of information I'm missing. Could you try jumping to the 30-minute mark on the TV again and tell me what happens, and send the fresh embyserver.txt plus any new ffmpeg logs? If it still hangs, the new logs will show whether the failure window moved at all.
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now