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 6 hours ago Author Posted 6 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 5 hours ago Posted 5 hours 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 4 hours ago Author Posted 4 hours 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 4 hours ago Posted 4 hours 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.
Gabi92 1 Posted 1 hour ago Author Posted 1 hour ago Everything has been running under emby lxc before and now: 1º: + EBML head size 40 data size 35 |+ EBML version: 1 size 4 data size 1 |+ EBML read version: 1 size 4 data size 1 |+ Maximum EBML ID length: 4 size 4 data size 1 |+ Maximum EBML size length: 8 size 4 data size 1 |+ Document type: matroska size 11 data size 8 |+ Document type version: 4 size 4 data size 1 |+ Document type read version: 2 size 4 data size 1 + Segment: size 26027072746 size 26027072758 data size 26027072746 |+ Seek head (subentries will be skipped) size 86 data size 81 |+ EBML void: size 4010 size 4013 data size 4010 |+ Segment information size 150 data size 144 | + Timestamp scale: 1000000 size 7 data size 3 | + Multiplexing application: libebml v1.3.4 + libmatroska v1.4.5 size 38 data size 35 | + Writing application: mkvmerge v13.0.0 ('The Juggler') 64bit size 41 data size 38 | + Duration: 01:56:40.651000000 size 7 data size 4 | + Date: 2017-07-14 10:45:54 UTC size 11 data size 8 | + Title: Gran Torino (2008) size 21 data size 18 | + Segment UID: 0x99 0x76 0x85 0x09 0xff 0xfa 0xc2 0x28 0x9e 0x8f 0xa0 0x15 0xc2 0xdc 0xde 0x3c size 19 data size 16 |+ Tracks size 508 data size 502 | + Track size 153 data size 150 | + Track number: 1 (track ID for mkvmerge & mkvextract: 0) size 3 data size 1 | + Track UID: 176360255512953789 size 11 data size 8 | + Track type: video size 3 data size 1 | + "Lacing" flag: 0 size 3 data size 1 | + Minimum cache: 1 size 4 data size 1 | + Codec ID: V_MS/VFW/FOURCC size 17 data size 15 | + Codec's private data: size 74 (FourCC: 0x57564331 "WVC1": VC-1) size 77 data size 74 | + Default duration: 00:00:00.041708333 (23.976 frames/fields per second for a video track) size 8 data size 4 | + Video track size 24 data size 22 | + Pixel width: 1920 size 4 data size 2 | + Pixel height: 1080 size 4 data size 2 | + Display width: 1920 size 7 data size 4 | + Display height: 1080 size 7 data size 4 | + Track size 74 data size 72 | + Track number: 2 (track ID for mkvmerge & mkvextract: 1) size 3 data size 1 | + Track UID: 8233816553667599537 size 11 data size 8 | + Track type: audio size 3 data size 1 | + Codec ID: A_AC3 size 7 data size 5 | + Default duration: 00:00:00.032000000 (31.250 frames/fields per second for a video track) size 8 data size 4 2º was giving errors but i´ve checked the execution rights and looks fine: ls -l /opt/emby-server/bin/ total 1268 -rwxr-xr-x 1 root root 581 ago 22 2017 emby-clinfo -rwxr-xr-x 1 root root 577 ago 22 2017 emby-ffdetect -rwxr-xr-x 1 root root 575 ago 22 2017 emby-ffmpeg -rwxr-xr-x 1 root root 930 ago 22 2017 emby-server -rwxr-xr-x 1 root root 581 ago 22 2017 emby-vainfo -rwxr-xr-x 1 root root 104168 ago 22 2017 ffdetect -rwxr-xr-x 1 root root 927568 ago 22 2017 ffmpeg -rwxr-xr-x 1 root root 797032 ago 22 2017 ffprobe Also i´ve tried with the other bin file and it has runned fine: for t in 00:00:10 00:01:39 00:10:30 00:33:30; do echo "== $t"; time /opt/emby-server/bin/emby-ffmpeg -hide_banner -v error -ss $t -i "$FILE" -frames:v 1 -f null -; done == 00:00:10 real 0m0,111s user 0m0,076s sys 0m0,027s == 00:01:39 real 0m0,146s user 0m0,105s sys 0m0,023s == 00:10:30 real 0m0,246s user 0m0,208s sys 0m0,026s == 00:33:30 real 0m0,146s user 0m0,115s sys 0m0,023s 3º: dd if="$FILE" of=/dev/null bs=1M skip=7000 count=200 iflag=direct 200+0 records in 200+0 records out 209715200 bytes (210 MB, 200 MiB) copied, 0,746605 s, 281 MB/s Extra tests: Software: time /opt/emby-server/bin/emby-ffmpeg -hide_banner -v error \ -ss 00:33:30 -i "$FILE" -frames:v 1 -f null - real 0m0,141s user 0m0,117s sys 0m0,023s Hardware: time /opt/emby-server/bin/emby-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 - real 0m1,296s user 0m0,033s sys 0m1,022s I´ve attached the logs after the two extras cores were added Logs.zip
vdatanet 1661 Posted 1 hour ago Posted 1 hour ago Good news — your tests ruled out both of my earlier theories. The index is fine (software seeks return in 0.15 s) and the disk is fine (281 MB/s). The problem is somewhere else entirely, and the new logs point at the NVDEC VC-1 decoder: after a seek it produces no frames at all, so ffmpeg dies before writing anything. Before I explain the details, could you try one quick change and tell me what happens? Dashboard → Transcoding → uncheck VC1 under hardware decoding. Leave everything else as it is — keep NVENC encoding on, and keep hardware decoding enabled for H.264 and HEVC. Then play Gran Torino and jump to somewhere around the 30-minute mark. With 4 cores the software VC-1 decode should keep up fine, and NVENC still handles the encoding. Let me know whether seeking works after that. If it does, we've found it and I'll explain what was going on. If it doesn't, send me the new logs and we keep digging.
Gabi92 1 Posted 57 minutes ago Author Posted 57 minutes ago I've applied the changes and now it works fine. Is there any option to use the A2000 for decoding without this issues? Thank you for your dedication and patience.
vdatanet 1661 Posted 41 minutes ago Posted 41 minutes ago (edited) Glad that did it — and thanks for running all those tests, they're what made it findable. What was happening: your file stores VC-1 using the legacy Video-for-Windows wrapper (Codec ID: V_MS/VFW/FOURCC, FourCC WVC1). With that layout the VC-1 sequence header lives in the container's codec private data rather than repeating in-band through the stream. Starting from position 0 works because the header is applied at initialization; after a mid-stream seek, NVDEC has nothing to re-initialize from and emits zero frames. The software decoder handles it because ffmpeg re-injects the extradata on seek. On getting the A2000 back into the decode path — there's no setting that fixes this while keeping NVDEC on VC-1. The mismatch is between the file's container layout and what the hardware decoder needs, so it's the file that has to change, not Emby. Two routes: Remux to a native VC-1 mapping. Cheap and lossless, worth trying first: ffmpeg -i "Gran Torino (2008) [tmdb=13223] 1080p.mkv" \ -c copy -bsf:v vc1_unpack \ "Gran Torino (2008) [tmdb=13223] 1080p.remux.mkv" Then test seeking on the new file with hardware decode re-enabled. It may or may not help depending on whether the sequence headers are recoverable — no harm in finding out, it's a few minutes of copying. Re-encode. This is the one I'd actually do. It solves several things at once: ffmpeg -i "Gran Torino (2008) [tmdb=13223] 1080p.mkv" \ -c:v hevc_nvenc -preset p5 -rc vbr -cq 24 -b:v 0 -maxrate 12M \ -c:a copy -c:s copy \ "Gran Torino (2008) [tmdb=13223] 1080p.hevc.mkv" About ten minutes on the A2000. You'd go from 26 GB to roughly 7 GB, the LG TV can direct-play HEVC so it may not transcode at all, and if it ever does, HEVC hardware decode has none of these problems. Practically speaking, keep VC1 hardware decoding off. VC-1 is a dead codec — you'll only have it on old Blu-ray remuxes, and those are exactly the files worth converting anyway. Everything modern in your library is H.264 or HEVC and still gets full GPU decode. Edited 40 minutes ago by vdatanet
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