[Bug]: Android - Slow skipping on long books #1362

New Issue

2026-04-24T23:57:50+02:00

adam commented

2026-04-24 23:57:50 +02:00

Originally created by @ldunkum on GitHub (Mar 29, 2026).

I have verified that the bug is not already awaiting release

Yes

What was the Problem?

Skipping forwards and backwards becomes very slow on long books after a while. This persists when re-downloading the books. At first I thought it's just at the end of long books, but after listening to the book for a while, skipping is slow everywhere in that book. This has happened to multiple books, doesn't matter if it's an m4b or multiple mp3s.

I was wondering if there's any correlation with the listening speed, but setting it to 1x playback doesn't make a difference.

Screen recording example

Slow skipping:

https://github.com/user-attachments/assets/60593be6-2ec9-4e38-8d35-05c846105ce5

After clearing app data and re-downloading:

https://github.com/user-attachments/assets/885ccef4-519f-4a06-bd5b-32bd2299c463

Steps to Reproduce the Issue

Listen to any long book for a while.

What was Expected?

Skipping should stay smooth, no matter how often a book is listened to.

Phone Model

Samsung Galaxy S21 FE

Phone OS

Android 16

Audiobookshelf App Version

Android App - 0.12.0-beta

Installation Source

Google Play Store

Additional Notes

I took a look at the code with Claude Code and this was its suggestion:

MediaEventManager.seekEvent() is called on every seek via PlayerListener.onPositionDiscontinuity → mediaProgressSyncer.seek():

DbManager.kt:273-274 — Paper.book("mediaItemHistory").read(id) — deserializes entire history

DbManager.kt:270-271 — Paper.book("mediaItemHistory").write(id, mediaItemHistory) — serializes + writes it back

The MediaItemHistory.events list grows unboundedly — every play, pause, seek, and 15-second save event appends to it.
Each seek deserializes and re-serializes the entire thing, on the main thread.

This could make sense because I skip around often and the if every event is stored in the DB, it could easily contain 50k events for a book this size, especially when re-listening.

Originally created by @ldunkum on GitHub (Mar 29, 2026). ### I have verified that the [bug is not already awaiting release](https://github.com/advplyr/audiobookshelf-app/issues?q=is%3Aissue%20label%3A%22awaiting%20release%22) Yes ### What was the Problem? Skipping forwards and backwards becomes very slow on long books after a while. This persists when re-downloading the books. At first I thought it's just at the end of long books, but after listening to the book for a while, skipping is slow everywhere in that book. This has happened to multiple books, doesn't matter if it's an m4b or multiple mp3s. I was wondering if there's any correlation with the listening speed, but setting it to 1x playback doesn't make a difference. <details><summary>Screen recording example</summary> <p> Slow skipping: https://github.com/user-attachments/assets/60593be6-2ec9-4e38-8d35-05c846105ce5 After clearing app data and re-downloading: https://github.com/user-attachments/assets/885ccef4-519f-4a06-bd5b-32bd2299c463 </p> </details> ### Steps to Reproduce the Issue Listen to any long book for a while. ### What was Expected? Skipping should stay smooth, no matter how often a book is listened to. ### Phone Model Samsung Galaxy S21 FE ### Phone OS Android 16 ### Audiobookshelf App Version Android App - 0.12.0-beta ### Installation Source Google Play Store ### Additional Notes I took a look at the code with Claude Code and this was its suggestion: > MediaEventManager.seekEvent() is called on every seek via PlayerListener.onPositionDiscontinuity → mediaProgressSyncer.seek(): > > - DbManager.kt:273-274 — Paper.book("mediaItemHistory").read(id) — deserializes entire history > - DbManager.kt:270-271 — Paper.book("mediaItemHistory").write(id, mediaItemHistory) — serializes + writes it back > > The MediaItemHistory.events list grows unboundedly — every play, pause, seek, and 15-second save event appends to it. > Each seek deserializes and re-serializes the entire thing, on the main thread. This could make sense because I skip around often and the if every event is stored in the DB, it could easily contain 50k events for a book this size, especially when re-listening.

adam added the bug label 2026-04-24 23:57:50 +02:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/audiobookshelf-app#1362