HEVC x265 works, but...

HEVC x265 video-encoded file types work now, but ...
... only when I upgraded to the latest ffmpeg.exe manually. The reason I did so was because of ffmpeg faulting to the event viewer on my server machine. The manual update fixed that problem. (see the link to update ffmpeg on the Serviio wiki)

Not perfect, though. A 19 min 24 second test file .mkv shows as only 4 min 12 seconds duration in Serviio, but it does play all the way to the end of the 20 minute episode despite the stated time limit.

However, fast forward and resume are not working as of yet for this video stream. Fast forward still works fine on regular file types.

But... at least it plays all the way through if I just don't touch it. If I have to restart it, it does not resume.

HEVC benefits are drastically improved quality and very small file size (a typical HEVC is 345 Kbps and is perfect quality and size smaller than even a converted/compressed file, whereas the approx 452Kbps I usually get after manual compression is nowhere near perfect quality), but since the controls are not yet worked out, it is not a perfect solution, for now.

(Using latest Serviio 1.6)

[atc98092]

My guess is that since few devices can play HEVC files it is being transcoded (and changing FFMPEG also points to transcoding). Many playback devices will not FF rewind or resume with transcoded files. Nothing Serviio can do about that. Sometimes the transcoding can use a different file type that allows trick play (that's what these actions are referred to as).

That also explains the inaccurate time length. Many devices will only report the time remaining based on the file size (or some other calculation), and since the transcoded file is still being created during playback it reports based of the file as it exists. I see the same thing when playing back an online video from DailyMotion, since my Roku requires transcoding to play the file.

My guess is that since few devices can play HEVC files it is being transcoded (and changing FFMPEG also points to transcoding). Many playback devices will not FF rewind or resume with transcoded files. Nothing Serviio can do about that. Sometimes the transcoding can use a different file type that allows trick play (that's what these actions are referred to as).

That also explains the inaccurate time length. Many devices will only report the time remaining based on the file size (or some other calculation), and since the transcoded file is still being created during playback it reports based of the file as it exists. I see the same thing when playing back an online video from DailyMotion, since my Roku requires transcoding to play the file.

I am NOT transcoding. I previously disabled transcoding in the Serviio console, and the server has been stopped/restarted (rebooted machine) many times since then.

[atc98092]

My guess is that since few devices can play HEVC files it is being transcoded (and changing FFMPEG also points to transcoding). Many playback devices will not FF rewind or resume with transcoded files. Nothing Serviio can do about that. Sometimes the transcoding can use a different file type that allows trick play (that's what these actions are referred to as).

That also explains the inaccurate time length. Many devices will only report the time remaining based on the file size (or some other calculation), and since the transcoded file is still being created during playback it reports based of the file as it exists. I see the same thing when playing back an online video from DailyMotion, since my Roku requires transcoding to play the file.

I am NOT transcoding. I previously disabled transcoding in the Serviio console, and the server has been stopped/restarted (rebooted machine) many times since then.

If there's no transcoding, to my knowledge FFMPEG is never called, so changing it should have had no impact. Sounds like it's still enabled, regardless of setting. I can't explain why...

[DenyAll]

Transcoding may also occur if you have "Enable burned-in subtitles" enabled, so check that.
Perhaps post both MediaInfo and ffmpeg -i info for the file and see if that sheds any light. What device and profile is being used?