Playback fails with specific files

[ebr 14903]

It sounds like burning in the subs was most of your problem.

[PlzLessSerious 1]

On second though - the problem cannot be just the CPU on the NAS. When you look at the resource graphs I posted earlier, the CPU was way below 90% initially. Sure it waited a bunch on IO, but still it was below 40%. If the CPU was the bottleneck it would have been maxed out.

 

The only thing close to being maxed out was the 'Volume' graph. I have 2 Seagate Ironwolf Pro disks. I guess they are just not fast enough? But... why would volume utilization be a bottleneck for transcoding when direct play works fine? I would assume transcoding also just needs to read the file, process it on CPU/GPU and pump it to the network. Reducing the transcoding part should not affect Disk Utilization that much.

 

The same video file without the forced subs plays fine and the Disk Utilization sits at 3-4% steady now. This only makes sense if the transcoding somewhy does a lot of disk reading and writing...

Edited April 20, 2020 by PlzLessSerious

[ebr 14903]

The same video file without the forced subs plays fine 

 

Right.  Burning in subs is probably the most intensive operation there is.

 

 

This only makes sense if the transcoding somewhy does a lot of disk reading and writing...

 

Well, it does because one file has to be read and another one written and then that sent out to the target (with who knows what other I/O in between to do the actual conversion inside ffmpeg).

 

 

If the CPU was the bottleneck it would have been maxed out.

 

Not necessarily as your CPU has 4 cores and some operations cannot be multi-threaded/spread across cores.  So, it is possible for your CPU to be "maxed out" on some process but only show you 25% utilization.

 

Bottom line, it sounds like avoiding the graphic subs is going to be what you need to watch.

[PlzLessSerious 1]

Right.  Burning in subs is probably the most intensive operation there is.

 

 

Well, it does because one file has to be read and another one written and then that sent out to the target (with who knows what other I/O in between to do the actual conversion inside ffmpeg).

 

 

Not necessarily as your CPU has 4 cores and some operations cannot be multi-threaded/spread across cores.  So, it is possible for your CPU to be "maxed out" on some process but only show you 25% utilization.

 

Bottom line, it sounds like avoiding the graphic subs is going to be what you need to watch.

 

Thanks, that was interesting info for me. I would not have expected the transcoding to write the new file to disk but rather to just stream it directly.

I tried playing around with this by creating a ram-disk and assigning the folder as Emby transcoding temporary path, but that did not help. So I will just live with the lousy trascoding performance.

 

... which turns out isn't actually even a big problem. My stupid brain is. Now that I had Roku Emby player video quality set to [auto] all the videos mentioned earlier start up pretty much immediately. And when I change that setting to 720p/10MP, the slow loading or.. no loading is back again. So I have verifiable proof that in most files' cases, that was the issue. 

 

So, if someone finds this thread, trying to solve their movie startup issues, make sure you haven't changed the default settings unless you know what the settings actually do