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

[Bug]: Seeking resets playback to 0 #3047

New Issue
Open
opened 2026-04-25 00:13:15 +02:00 by adam · 11 comments
adam commented 2026-04-25 00:13:15 +02:00
Owner
Copy Link
Copy Source

Originally created by @p-rintz on GitHub (Oct 21, 2025).

What happened?

Hi there,

I am having a strange issue where seeking podcasts resets the playback back to 0 when using any mobile app on iOS.

I tried plappa, audiobookshelf app and shelfplayer. They all suffer from this.
But the web player in a browser on desktop works fine.

Because this affects all apps on iOS Ive tried, I think the issue is better here than in the app repository.
But I have found a similar issue there: https://github.com/advplyr/audiobookshelf-app/issues/1697

The person there suggests it might relate to the size of the files that are being seeked in.
Which might be a possibility. Podcasts are singular large files, while audiobooks (which seek fine) are multiple smaller mp3 files.

What did you expect to happen?

Seeking should work and not reset playback to 0

Steps to reproduce the issue

  1. Open a podcast in app on iOS
  2. Try to seek
  3. Playback gets reset to 0

Audiobookshelf version

2.30.0

How are you running audiobookshelf?

Docker

What OS is your Audiobookshelf server hosted from?

Linux

If the issue is being seen in the UI, what browsers are you seeing the problem on?

None

Logs

audiobookshelf-1  | [2025-10-21 18:24:58.471] DEBUG: [PlaybackSessionManager] "philipp" starting direct play session for item "75ee6a3e-92ca-4aa5-9486-04394ac09de7" with id 11402148-28e6-4079-9c5c-51ae0a6ac85f (Device: iPad14,1 / v0.10.1)
audiobookshelf-1  | [2025-10-21 18:24:58.619] DEBUG: [SessionController] Serving audio track 1 for session "11402148-28e6-4079-9c5c-51ae0a6ac85f" belonging to user "philipp"
audiobookshelf-1  | [2025-10-21 18:24:59.151] DEBUG: [SessionController] Serving audio track 1 for session "11402148-28e6-4079-9c5c-51ae0a6ac85f" belonging to user "philipp"
audiobookshelf-1  | [2025-10-21 18:24:59.313] DEBUG: [SessionController] Serving audio track 1 for session "11402148-28e6-4079-9c5c-51ae0a6ac85f" belonging to user "philipp"
audiobookshelf-1  | [2025-10-21 18:24:59.378] DEBUG: [PlaybackSessionManager] syncSession "11402148-28e6-4079-9c5c-51ae0a6ac85f" (Device: iPad14,1 / v0.10.1) | Total Time Listened: 0
audiobookshelf-1  | [2025-10-21 18:25:12.964] DEBUG: [PlaybackSessionManager] syncSession "11402148-28e6-4079-9c5c-51ae0a6ac85f" (Device: iPad14,1 / v0.10.1) | Total Time Listened: 13.525434970855713
audiobookshelf-1  | [2025-10-21 18:25:12.979] DEBUG: [ApiCacheManager] mediaProgress.afterUpdate: Clearing cache
audiobookshelf-1  | [2025-10-21 18:25:12.991] DEBUG: [ApiCacheManager] Array.afterUpsert: Clearing cache
audiobookshelf-1  | [2025-10-21 18:25:19.624] DEBUG: [PlaybackSessionManager] syncSession "11402148-28e6-4079-9c5c-51ae0a6ac85f" (Device: iPad14,1 / v0.10.1) | Total Time Listened: 15.90760612487793
audiobookshelf-1  | [2025-10-21 18:25:19.637] DEBUG: [ApiCacheManager] mediaProgress.afterUpdate: Clearing cache
audiobookshelf-1  | [2025-10-21 18:25:19.648] DEBUG: [ApiCacheManager] Object.afterBulkUpdate: Clearing cache
audiobookshelf-1  | [2025-10-21 18:25:22.764] DEBUG: [SocketAuthority] User Offline philipp

Additional Notes

My logs dont seem to really show anything relevant. I attached a log showing me tring to seek forward in the audiobookshelf app.

Downgrade to 2.29.0 did not show it being better there.

Originally created by @p-rintz on GitHub (Oct 21, 2025). ### What happened? Hi there, I am having a strange issue where seeking podcasts resets the playback back to 0 when using any mobile app on iOS. I tried plappa, audiobookshelf app and shelfplayer. They all suffer from this. But the web player in a browser on desktop works fine. Because this affects all apps on iOS Ive tried, I think the issue is better here than in the app repository. But I have found a similar issue there: https://github.com/advplyr/audiobookshelf-app/issues/1697 The person there suggests it might relate to the size of the files that are being seeked in. Which might be a possibility. Podcasts are singular large files, while audiobooks (which seek fine) are multiple smaller mp3 files. ### What did you expect to happen? Seeking should work and not reset playback to 0 ### Steps to reproduce the issue 1. Open a podcast in app on iOS 2. Try to seek 3. Playback gets reset to 0 ### Audiobookshelf version 2.30.0 ### How are you running audiobookshelf? Docker ### What OS is your Audiobookshelf server hosted from? Linux ### If the issue is being seen in the UI, what browsers are you seeing the problem on? None ### Logs ```shell audiobookshelf-1 | [2025-10-21 18:24:58.471] DEBUG: [PlaybackSessionManager] "philipp" starting direct play session for item "75ee6a3e-92ca-4aa5-9486-04394ac09de7" with id 11402148-28e6-4079-9c5c-51ae0a6ac85f (Device: iPad14,1 / v0.10.1) audiobookshelf-1 | [2025-10-21 18:24:58.619] DEBUG: [SessionController] Serving audio track 1 for session "11402148-28e6-4079-9c5c-51ae0a6ac85f" belonging to user "philipp" audiobookshelf-1 | [2025-10-21 18:24:59.151] DEBUG: [SessionController] Serving audio track 1 for session "11402148-28e6-4079-9c5c-51ae0a6ac85f" belonging to user "philipp" audiobookshelf-1 | [2025-10-21 18:24:59.313] DEBUG: [SessionController] Serving audio track 1 for session "11402148-28e6-4079-9c5c-51ae0a6ac85f" belonging to user "philipp" audiobookshelf-1 | [2025-10-21 18:24:59.378] DEBUG: [PlaybackSessionManager] syncSession "11402148-28e6-4079-9c5c-51ae0a6ac85f" (Device: iPad14,1 / v0.10.1) | Total Time Listened: 0 audiobookshelf-1 | [2025-10-21 18:25:12.964] DEBUG: [PlaybackSessionManager] syncSession "11402148-28e6-4079-9c5c-51ae0a6ac85f" (Device: iPad14,1 / v0.10.1) | Total Time Listened: 13.525434970855713 audiobookshelf-1 | [2025-10-21 18:25:12.979] DEBUG: [ApiCacheManager] mediaProgress.afterUpdate: Clearing cache audiobookshelf-1 | [2025-10-21 18:25:12.991] DEBUG: [ApiCacheManager] Array.afterUpsert: Clearing cache audiobookshelf-1 | [2025-10-21 18:25:19.624] DEBUG: [PlaybackSessionManager] syncSession "11402148-28e6-4079-9c5c-51ae0a6ac85f" (Device: iPad14,1 / v0.10.1) | Total Time Listened: 15.90760612487793 audiobookshelf-1 | [2025-10-21 18:25:19.637] DEBUG: [ApiCacheManager] mediaProgress.afterUpdate: Clearing cache audiobookshelf-1 | [2025-10-21 18:25:19.648] DEBUG: [ApiCacheManager] Object.afterBulkUpdate: Clearing cache audiobookshelf-1 | [2025-10-21 18:25:22.764] DEBUG: [SocketAuthority] User Offline philipp ``` ### Additional Notes My logs dont seem to really show anything relevant. I attached a log showing me tring to seek forward in the audiobookshelf app. Downgrade to 2.29.0 did not show it being better there.
adam added the bugwaiting labels 2026-04-25 00:13:15 +02:00
adam commented 2026-04-25 00:13:16 +02:00
Author
Owner
Copy Link
Copy Source

@Vito0912 commented on GitHub (Oct 21, 2025):

Are these mp3s?

@Vito0912 commented on GitHub (Oct 21, 2025): Are these mp3s?
adam commented 2026-04-25 00:13:16 +02:00
Author
Owner
Copy Link
Copy Source

@p-rintz commented on GitHub (Oct 21, 2025):

Yes. Audiobooks and podcasts are both mp3.

@p-rintz commented on GitHub (Oct 21, 2025): Yes. Audiobooks and podcasts are both mp3.
adam commented 2026-04-25 00:13:16 +02:00
Author
Owner
Copy Link
Copy Source

@Vito0912 commented on GitHub (Oct 21, 2025):

Then try reencoding them into e.g. m4b.
The chances are very high that this is caused by corrupted or incorrect headers.

In any case, it should not be ABS's fault - ABS can't do anything about it as it uses the built-in players from your OS. The linked issue is a rare case (and personally I think there is something wrong with the transmission, not with the actual app, as it would not make any sense that the same file works through one connection, but not trough the other).

@Vito0912 commented on GitHub (Oct 21, 2025): Then try reencoding them into e.g. m4b. The chances are very high that this is caused by corrupted or incorrect headers. In any case, it should not be ABS's fault - ABS can't do anything about it as it uses the built-in players from your OS. The linked issue is a rare case (and personally I think there is something wrong with the transmission, not with the actual app, as it would not make any sense that the same file works through one connection, but not trough the other).
adam commented 2026-04-25 00:13:16 +02:00
Author
Owner
Copy Link
Copy Source

@p-rintz commented on GitHub (Oct 21, 2025):

I will try. I have tried a few more podcasts just now. And found one which isnt affected. Strange that is just started happening recently though. (and not just one podcast).

Is there a good way to automatically reencode podcasts after they are downloaded?

@p-rintz commented on GitHub (Oct 21, 2025): I will try. I have tried a few more podcasts just now. And found one which isnt affected. Strange that is just started happening recently though. (and not just one podcast). Is there a good way to automatically reencode podcasts after they are downloaded?
adam commented 2026-04-25 00:13:16 +02:00
Author
Owner
Copy Link
Copy Source

@Vito0912 commented on GitHub (Oct 21, 2025):

podcasts cannot be encoded by ABS. If you want to encode podcasts episodes you cannot let ABS manage the downloading.

The only way would be if you reencode to the same file format (mp3). If the header are corrupted, this can fix the issue too

@Vito0912 commented on GitHub (Oct 21, 2025): podcasts cannot be encoded by ABS. If you want to encode podcasts episodes you cannot let ABS manage the downloading. The only way would be if you reencode to the same file format (mp3). If the header are corrupted, this can fix the issue too
adam commented 2026-04-25 00:13:16 +02:00
Author
Owner
Copy Link
Copy Source

@p-rintz commented on GitHub (Oct 21, 2025):

Can audiobookshelf do the reencode?

Otherwise Ill try to cobble together a script based on inotify, but if there is some built-in solution, that would of course be better.

Reencode seems to fix the issue, btw. I just tried it on a podcast that had the issue and its ok now.

@p-rintz commented on GitHub (Oct 21, 2025): Can audiobookshelf do the reencode? Otherwise Ill try to cobble together a script based on inotify, but if there is some built-in solution, that would of course be better. Reencode seems to fix the issue, btw. I just tried it on a podcast that had the issue and its ok now.
adam commented 2026-04-25 00:13:16 +02:00
Author
Owner
Copy Link
Copy Source

@Vito0912 commented on GitHub (Oct 21, 2025):

ABS can do encoding, just not for podcasts. For audiobooks you can also encode to other formats.

If reencoding fixes the issue, then it's either the fault of the ABS download implementation (I know advplyr changed something recently) or just general corrupt files.

@Vito0912 commented on GitHub (Oct 21, 2025): ABS can do encoding, just not for podcasts. For audiobooks you can also encode to other formats. If reencoding fixes the issue, then it's either the fault of the ABS download implementation (I know advplyr changed something recently) or just general corrupt files.
adam commented 2026-04-25 00:13:16 +02:00
Author
Owner
Copy Link
Copy Source

@p-rintz commented on GitHub (Oct 21, 2025):

Alright. Thanks. Ill write a small bash script to fix the files.

Should I keep this open or close it?

@p-rintz commented on GitHub (Oct 21, 2025): Alright. Thanks. Ill write a small bash script to fix the files. Should I keep this open or close it?
adam commented 2026-04-25 00:13:17 +02:00
Author
Owner
Copy Link
Copy Source

@Vito0912 commented on GitHub (Oct 21, 2025):

You said that multiple podcasts are affected, so maybe it is indeed ABSs fault, I would leave it open for now

Maybe @advplyr can say if you should close/open/ knows, why this is happening

@Vito0912 commented on GitHub (Oct 21, 2025): You said that multiple podcasts are affected, so maybe it is indeed ABSs fault, I would leave it open for now Maybe @advplyr can say if you should close/open/ knows, why this is happening
adam commented 2026-04-25 00:13:17 +02:00
Author
Owner
Copy Link
Copy Source

@advplyr commented on GitHub (Oct 21, 2025):

Can you share the podcasts so I can test? This is most likely not an Abs issue since the files are being direct played. Abs is just hosting the mp3 file and serving it as-is.

@advplyr commented on GitHub (Oct 21, 2025): Can you share the podcasts so I can test? This is most likely not an Abs issue since the files are being direct played. Abs is just hosting the mp3 file and serving it as-is.
adam commented 2026-04-25 00:13:17 +02:00
Author
Owner
Copy Link
Copy Source

@p-rintz commented on GitHub (Oct 22, 2025):

Of course. Two episodes from two podcasts that were separately affected are LdN450 of Lage der Nation and the Sony Watchmen episode of The Vergecast.

@p-rintz commented on GitHub (Oct 22, 2025): Of course. Two episodes from two podcasts that were separately affected are LdN450 of Lage der Nation and the Sony Watchmen episode of The Vergecast.
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 bug waiting
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#3047
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?