Phew man this was a rabbit hole and I should have checked the most important thing at the start, but alas...
I noticed that sometimes when re-editing an episode, the timestamps for existing segments wouldn't match up with where they should be.
I then noticed that every time I opened the video and skipped to the end (where I wanted to place my Outro segment), it would have a different total runtime when I reached the end of the video.
So I experimented a little and the only time I can get the time to be consistent is when I use A/D to skip by 5 seconds each, making sure that every playlist segment is loaded in order.
However, even then, the total runtime is wrong.
However, after skipping through the video, and making sure in the Dev Tools Network tab that every segment is being downloaded, I end up with this total runtime:
And yea, fun fact: These actually save to the server just fine, which may or may not be causing me headaches when the Outro is set to skip (not sure yet, still testing this).
I'm also not sure if that is an issue with the Segment API plugin or generally with JF's Media Segments.
Either way though, the player should be consistently showing correct total runtimes, and timestamps in general.
I think there is actually a disconnect between what the player lets you skip to, and what it should be. In fact, when you just load up the player and it does the pre-buffering, hovering over the end of the player bar does show the correct end timestamp (plus-minus a couple few hundredths of a second because.. reasons I assume):
And directly skipping to that time, then advancing by 1s until it can't go further, it's also much closer to what it should be:
However, skipping to somewhere earlier in the video and then advancing by 5s each results in a different end timestamp:
Should be noted this is just an example, it changes depending on where to the video you initially skip to.
My guess is this is related to how the player requests the playlist segments. I think it can't quite figure out where it should be so it just makes an "educated guess".
The WebUI player as well as JMP and MPV are all showing the correct time, which is why I'm leaning towards this being an issue with the video player being used.
Since the FPS are fractional (as many bluray media are), this might be an issue with the player slowing down the video so it matches a integer FPS value? It's just a guess and I have not done the math to figure it out.
edit:
Actually, from some further experimentation it might just be that the player is repeating the final segment a second time... for... some reason :thinking:
Phew man this was a rabbit hole and I should have checked the most important thing at the start, but alas...
I noticed that sometimes when re-editing an episode, the timestamps for existing segments wouldn't match up with where they should be. I then noticed that every time I opened the video and skipped to the end (where I wanted to place my Outro segment), it would have a different total runtime when I reached the end of the video.
So I experimented a little and the only time I can get the time to be consistent is when I use A/D to skip by 5 seconds each, making sure that every playlist segment is loaded in order. However, even then, the total runtime is wrong.
For example, I have this episode:
However, after skipping through the video, and making sure in the Dev Tools Network tab that every segment is being downloaded, I end up with this total runtime:
And yea, fun fact: These actually save to the server just fine, which may or may not be causing me headaches when the Outro is set to skip (not sure yet, still testing this). I'm also not sure if that is an issue with the Segment API plugin or generally with JF's Media Segments.
Either way though, the player should be consistently showing correct total runtimes, and timestamps in general.
I think there is actually a disconnect between what the player lets you skip to, and what it should be. In fact, when you just load up the player and it does the pre-buffering, hovering over the end of the player bar does show the correct end timestamp (plus-minus a couple few hundredths of a second because.. reasons I assume):
And directly skipping to that time, then advancing by 1s until it can't go further, it's also much closer to what it should be:
However, skipping to somewhere earlier in the video and then advancing by 5s each results in a different end timestamp:
Should be noted this is just an example, it changes depending on where to the video you initially skip to. My guess is this is related to how the player requests the playlist segments. I think it can't quite figure out where it should be so it just makes an "educated guess".
The WebUI player as well as JMP and MPV are all showing the correct time, which is why I'm leaning towards this being an issue with the video player being used. Since the FPS are fractional (as many bluray media are), this might be an issue with the player slowing down the video so it matches a integer FPS value? It's just a guess and I have not done the math to figure it out.
edit: Actually, from some further experimentation it might just be that the player is repeating the final segment a second time... for... some reason :thinking: