INTERACT FORUM
More => Old Versions => JRiver Media Center 20 for Windows => Topic started by: 6233638 on June 12, 2015, 11:54:19 am
-
As mentioned here (http://yabb.jriver.com/interact/index.php?topic=98132.new#new), I've been ripping another TV series to MKV and using the [Playback Range] field to cut off the intro/credits.
But what I've noticed is that bookmarks seem to be relative to the edited duration, rather than the original length the video.
If I have a bookmark at 05:00 and edit the file to cut off the first 60 seconds of the video, when I resume playback it starts at the new 05:00 position, which is actually 06:00 in the file.
What I'd expect is that playback would start at "04:00" which is really the 5 minute point in the video file.
It seems like bookmarks should be set to the original duration rather than the edited duration?
-
Hmmm. That's a tricky one, and I expect that most people would want the current behaviour. Let's say you edit the file before playing back for the first time. You then watch 5 minutes of the edited version and stop the playback, thus bookmarking it. When you resume playback, you'd want it to be where you left off - 5 minutes into the duration, which may be 6 minutes into the original file.
I see what you're saying though; since you can manually manipulate the playback range, the bookmark is not a constant, unless it is relative to the start of the original file.
-
Yeah. I agree. There's no "right" answer for this. :-\
-
If the bookmark is based on the full length of the file, it should always resume at the correct position.
I'm not sure how the current behavior is beneficial in any way.
-
This is not a bug, just how Bookmarks work. They are always relative to the actual virtual playback range, not anything else. From a playback standpoint its the most intuitive too, if the bookmark says 04:00, then resuming the file will also say 04:00, and not suddenly 03:00 or w/e.
Changing this would require a lot of changes in MC, not to mention that it would break everyones bookmark of content with a playback range.
Its also somewhat important for streaming/transcoding, where a player getting a transcoded stream may not necessarily know about the playback range, it just gets a stream from start to finish (where MC applied the playback range already), and needs to possibly apply a bookmark to that - today that is trivial, without having to parse and understand the playback range, which would be a breaking change for all third party clients.
So, just accept it how it is.
-
Thanks for the detailed explanation.