INTERACT FORUM
More => Old Versions => JRiver Media Center 20 for Windows => Topic started by: masterjoe on April 08, 2015, 09:24:37 am
-
So in order to find out what's wrong I need to start another thread / topic.
My problem is that MC20 does not allow to change the playback position within a video on my LG TV.
Scenario:
- MC20 (build 87)
- LG TV (see attached Whitebear DMR analyzer report)
- movie library
- selected profile for DLNA: Samsung BD/TV
Steps:
- On the LG TV select a video file from MC20 DLNA library
- Play the video back -> works.
- Try to jump forward in the video -> The video starts over from the beginning again! (No matter to which position one tries to seek.)
So jumping to a specific time position in the video file (no matter what file format it has!!) leads to playing back the video from the start again. Bummer.
Note that the SAME video file is seekable on Serviio and Plex media servers. Here the change of the playback position leads into correctly jumping to that position!
So the problem has to do with MC20 and NOT with the files used.
-
The issue is probably that when MC has to transcode video to another format that the TV can play, it is not providing an HTTP Content-Length header. This means that the TV has no reference point enabling it to calculate the byte range offset for a byte-range seek command. The MC developers say that this is because they cannot calculate the Content-length in advance until the full transcoding has been completed. This statement is indeed logically true. I have personally been trying to encourage JRiver that even if they cannot calculate an exact Content-length in advance, they should deliver an estimated value. This would allow the TV to do a Seek and even if the byte destination is a bit off, it would still move onwards in the track, and would certainly be better than the current situation where the track starts replaying at zero. (Also MC would need to be able to satisfy such a byte range seek by converting that into an estimate time seek offset. If JRiver were clever about it, the estimated content-length and the estimated byte seek offset could refer to each other and the resulting time seek offset would actually be pretty accurate..)
-
It's true that it only happens with transcoded files. They should indeed implement a way to seek within a file - even if it's not 100% accurate due to transcoding issues. But not being able to seek at all is annoying. You can't just stop a video and then watch it from where you left.
-
Well pls... any feedback from the developers?
Transcoded video needs to be seekable!
-
Bump.