starred/audiobookshelf
1
0
Fork 0
mirror of https://github.com/advplyr/audiobookshelf.git synced 2026-05-30 23:40:40 +02:00
Code Issues 1.0k Packages Projects Releases 10 Wiki Activity

[PR #5163] The timestamp in the share URL should override the saved position for the user. #4448

New Issue
Open
opened 2026-04-25 00:19:47 +02:00 by adam · 0 comments
adam commented 2026-04-25 00:19:47 +02:00
Owner
Copy Link
Copy Source

📋 Pull Request Information

Original PR: https://github.com/advplyr/audiobookshelf/pull/5163
Author: @pjkottke
Created: 4/2/2026
Status: 🔄 Open

Base: master ← Head: master

📝 Commits (1)

  • 5a6b3d8 updates to allow share t argument to over-ride server stored position

📊 Changes

2 files changed (+8 additions, -2 deletions)

View changed files

📝 client/pages/share/_slug.vue (+3 -1)
📝 server/controllers/ShareController.js (+5 -1)

📄 Description

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 test

Created 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

🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.

## 📋 Pull Request Information **Original PR:** https://github.com/advplyr/audiobookshelf/pull/5163 **Author:** [@pjkottke](https://github.com/pjkottke) **Created:** 4/2/2026 **Status:** 🔄 Open **Base:** `master` ← **Head:** `master` --- ### 📝 Commits (1) - [`5a6b3d8`](https://github.com/advplyr/audiobookshelf/commit/5a6b3d8e6158730cd7dede97234884d9137c1285) updates to allow share t argument to over-ride server stored position ### 📊 Changes **2 files changed** (+8 additions, -2 deletions) <details> <summary>View changed files</summary> 📝 `client/pages/share/_slug.vue` (+3 -1) 📝 `server/controllers/ShareController.js` (+5 -1) </details> ### 📄 Description ## 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 test` Created 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 --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
adam added the pull-request label 2026-04-25 00:19:47 +02:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
authentication
backlog
bug
chapter editor
config-issue
ebooks
encoding/embedding
enhancement
help wanted
listening sessions & progress
planned
possible plugin
progress sync
pull-request
Mirrored from GitHub Pull Request
 sorting/filtering/searching
unable to reproduce
upload
users & permissions
waiting
No Label pull-request
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam (Adam Melkus)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/audiobookshelf#4448
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?