[Enhancement]: Change "Lock Player" behaviour #1001

New Issue

2026-04-24T23:45:22+02:00

adam commented

2026-04-24 23:45:22 +02:00

Originally created by @gavinorland on GitHub (Jul 26, 2024).

Describe the Feature/Enhancement

Change "Lock Player" behaviour to leave the UI as-is, and instead render all except the dotted menu button unclickable.

Why would this be helpful?

"Lock Player" seems at first sight like it might lock the entire player UI (to prevent accidental interactions), until it is turned off again by the same control. But instead it hides the fwd/back controls, leaving all others (except the progress bar) clickable. This behaviour might not be the most obvious, and it leaves several interactions, including "pause" still possible.

This is just a suggestion, for consideration, that this behaviour might be changed.

Audiobookshelf App Version

Android App - 0.9.74

Originally created by @gavinorland on GitHub (Jul 26, 2024). ### Describe the Feature/Enhancement Change "Lock Player" behaviour to leave the UI as-is, and instead render all except the dotted menu button unclickable. ### Why would this be helpful? "Lock Player" seems at first sight like it might lock the entire player UI (to prevent accidental interactions), until it is turned off again by the same control. But instead it hides the fwd/back controls, leaving all others (except the progress bar) clickable. This behaviour might not be the most obvious, and it leaves several interactions, including "pause" still possible. This is just a suggestion, for consideration, that this behaviour might be changed. ### Audiobookshelf App Version Android App - 0.9.74

adam added the enhancement label 2026-04-24 23:45:22 +02:00

adam closed this issue

2026-04-24 23:45:23 +02:00

adam commented

2026-04-24 23:45:24 +02:00

@nichwall commented on GitHub (Jul 26, 2024):

The progress bar should not be clickable/seekable when the player is locked.

Maybe "lock player" could be renamed to "prevent seeking"? Locking the player just prevents all playback related actions other than play/pause, similar to other apps like Smart Audiobook Player.

https://github.com/user-attachments/assets/6937cffd-ddad-45bf-9112-9d6db9072a5e

@nichwall commented on GitHub (Jul 26, 2024): The progress bar should not be clickable/seekable when the player is locked. Maybe "lock player" could be renamed to "prevent seeking"? Locking the player just prevents all playback related actions other than play/pause, similar to other apps like Smart Audiobook Player. https://github.com/user-attachments/assets/6937cffd-ddad-45bf-9112-9d6db9072a5e

adam commented

2026-04-24 23:45:25 +02:00

@advplyr commented on GitHub (Jul 26, 2024):

Is there a use-case for hiding the 3-dot menu in the audio player or is this being requested because the name "Lock player" doesn't seem accurate?

@advplyr commented on GitHub (Jul 26, 2024): Is there a use-case for hiding the 3-dot menu in the audio player or is this being requested because the name "Lock player" doesn't seem accurate?

adam commented

2026-04-24 23:45:26 +02:00

@gavinorland commented on GitHub (Jul 26, 2024):

Hi @nichwall

The progress bar should not be clickable/seekable when the player is locked.

I agree - I question whether any of the controls should be clickable when the player is locked.

Yes, if the functionality isn't changed then I guess it could be renamed as you say. I see what you mean about it matching the other app's functionality but as it stands it still doesn't do what I (at least) expected it would.

@gavinorland commented on GitHub (Jul 26, 2024): Hi @nichwall > The progress bar should not be clickable/seekable when the player is locked. I agree - I question whether _any_ of the controls should be clickable when the player is locked. Yes, if the functionality isn't changed then I guess it could be renamed as you say. I see what you mean about it matching the other app's functionality but as it stands it still doesn't do what I (at least) expected it would.

adam commented

2026-04-24 23:45:26 +02:00

@gavinorland commented on GitHub (Jul 26, 2024):

@advplyr I don't see any condition where it would be worth hiding the three-dot menu. I'm mainly suggesting this because the function didn't do what I would expect - namely lock the whole player UI.

So - if this is actioned - the question would be whether to leave the functionality as-is and rename the action to "Disable Seeking"/"Enable Seeking", or to change the functionality to actually lock the whole UI (except the menu, so that "Unlock Player" can be selected). I think I would go for the latter, but I appreciate it's been done like this to match another app.

@gavinorland commented on GitHub (Jul 26, 2024): @advplyr I don't see any condition where it would be worth hiding the three-dot menu. I'm mainly suggesting this because the function didn't do what I would expect - namely lock the whole player UI. So - if this is actioned - the question would be whether to leave the functionality as-is and rename the action to "Disable Seeking"/"Enable Seeking", or to change the functionality to actually lock the whole UI (except the menu, so that "Unlock Player" can be selected). I think I would go for the latter, but I appreciate it's been done like this to match another app.

adam commented

2026-04-24 23:45:27 +02:00

@advplyr commented on GitHub (Jul 26, 2024):

I don't think we would ever want to disable the play/pause button especially if something is currently playing.

@advplyr commented on GitHub (Jul 26, 2024): I don't think we would ever want to disable the play/pause button especially if something is currently playing.

adam commented

2026-04-24 23:45:27 +02:00

@gavinorland commented on GitHub (Jul 27, 2024):

OK - maybe leave this one then, unless it garners more support, as "Lock Player" can be understood as "Lock player on" rather than "Lock player from any interaction".

@gavinorland commented on GitHub (Jul 27, 2024): OK - maybe leave this one then, unless it garners more support, as "Lock Player" can be understood as "Lock player on" rather than "Lock player from any interaction".

adam commented

2026-04-24 23:45:28 +02:00

@nichwall commented on GitHub (Jul 27, 2024):

From the request you opened the other day, maybe it could just be combined as a "Simplified Player" option?

https://github.com/advplyr/audiobookshelf-app/issues/1260

@nichwall commented on GitHub (Jul 27, 2024): From the request you opened the other day, maybe it could just be combined as a "Simplified Player" option? https://github.com/advplyr/audiobookshelf-app/issues/1260

adam commented

2026-04-24 23:45:30 +02:00

@gavinorland commented on GitHub (Jul 27, 2024):

I think I would leave #1260 as replicating "Car mode" as seen on other apps such as Audible and Podcast Republic, but it's true, this setting might not be necessary if that one was fully implemented.

@gavinorland commented on GitHub (Jul 27, 2024): I think I would leave #1260 as replicating "Car mode" as seen on other apps such as Audible and Podcast Republic, but it's true, this setting might not be necessary if that one was fully implemented.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/audiobookshelf-app#1001