The timestamp in the share URL should override the saved position for the user.#5163
Open
pjkottke wants to merge 1 commit intoadvplyr:masterfrom
Open
The timestamp in the share URL should override the saved position for the user.#5163pjkottke wants to merge 1 commit intoadvplyr:masterfrom
pjkottke wants to merge 1 commit intoadvplyr:masterfrom
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Brief summary
When a share link includes a ?t= query parameter specifying a start time, it should seek to that position rather than resuming from the listener's previously cached position.
Which issue is fixed?
No existing issue, this is a new bug fix.
In-depth Description
Share links support a ?t= query parameter for specifying a start time. However, when a returning visitor has an active share session (via share_session_id cookie), the server returns the cached currentTime from that session and ignores the ?t parameter entirely.
The fix is in ShareController.getMediaItemShareBySlug: when an existing session is found and returned early, ?t is now checked and applied to playbackSession.currentTime before the response is sent. The client (_slug.vue) is also updated to prefer ?t over playbackSession.currentTime as a belt-and-suspenders guard.
This is useful any time someone wants to share a link to a specific moment (a particular chapter or scene) with someone who has already listened to part of the same share.
How have you tested this?
npm testCreated a share link for an audiobook
Opened the link and listened for ~30 seconds (establishing a cached session)
Reloaded the page - confirmed it resumed from the cached position (expected baseline behavior)
Appended ?t=120 to the URL and reloaded - confirmed playback started at 2:00 rather than the cached position
Removed ?t and reloaded - confirmed it returned to resuming from cached position