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]: Cache hit forcing crash #2674

New Issue
Closed
opened 2026-04-25 00:09:32 +02:00 by adam · 4 comments
adam commented 2026-04-25 00:09:32 +02:00
Owner
Copy Link
Copy Source

Originally created by @miketangovictor on GitHub (Mar 20, 2025).

What happened?

When attempting to open a podcast series with a large number of episodes on the iOS app (0.9.79-beta) the screen pauses, then disconnects and returns the user to the podcast home screen. This appears to be only on Podcasts with a large number of episodes (over 1,000 though have seen behavior with 800+ episodes as well).

Logs do not show a crash, just the last event of the cache loading, then the user disconnecting and then the normal behavior of the app refreshing the data. The cycle continues.

Behavior started long after the release of the the iOS app version, and believe it was timed to the server 2.20 release.

What did you expect to happen?

Expect to be able to open the episode list normally and have the app not crash.

Steps to reproduce the issue

  1. Add a Podcast with a large number of episodes. I've seen the behavior consistently with a library of over 1000 episodes like Stuff You Should Know.
  2. Navigate to select the podcast, once selected the app pauses and the crash behavior takes place.

Audiobookshelf version

2.20

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?

Other (list in "Additional Notes" box)

Logs

2025-03-20 09:44:30.438

DEBUG

[ApiCacheManager] Cache hit: {"user":"v-audiobookshelf","url":"/libraries/4e463247-befe-4d55-95b6-8aaace238a8e/items?sort=addedAt&desc=1&limit=20&page=-1&minified=1&include=rssfeed,numEpisodesIncomplete"}

2025-03-20 09:44:46.444

DEBUG

[SocketAuthority] User Offline v-audiobookshelf

2025-03-20 09:44:46.446

INFO

[SocketAuthority] Socket 5NQGqeCi86PFGpB_AADP disconnected from client "v-audiobookshelf" after 32307ms (Reason: transport close)

2025-03-20 09:44:47.111

DEBUG

[ApiCacheManager] count: 6 size: 220721

2025-03-20 09:44:47.112

DEBUG

[ApiCacheManager] Cache hit: {"user":"v-audiobookshelf","url":"/libraries"}

2025-03-20 09:44:47.126

INFO

[SocketAuthority] Socket Connected to /socket.io B-H43Cg1FSbRVd00AADR

2025-03-20 09:44:47.128

DEBUG

[ApiCacheManager] count: 6 size: 220721

2025-03-20 09:44:47.128

DEBUG

[ApiCacheManager] Cache hit: {"user":"v-audiobookshelf","url":"/libraries/4e463247-befe-4d55-95b6-8aaace238a8e?include=filterdata"}

2025-03-20 09:44:47.132

DEBUG

[SocketAuthority] User Online v-audiobookshelf

2025-03-20 09:44:47.151

DEBUG

[ApiCacheManager] count: 6 size: 220721

2025-03-20 09:44:47.152

DEBUG

[ApiCacheManager] Cache hit: {"user":"v-audiobookshelf","url":"/libraries/4e463247-befe-4d55-95b6-8aaace238a8e/personalized?minified=1&include=rssfeed,numEpisodesIncomplete"}

2025-03-20 09:44:52.342

DEBUG

[ApiCacheManager] count: 6 size: 220721

2025-03-20 09:44:52.343

DEBUG

[ApiCacheManager] Cache hit: {"user":"v-audiobookshelf","url":"/libraries/4e463247-befe-4d55-95b6-8aaace238a8e/items?sort=addedAt&desc=1&limit=20&page=0&minified=1&include=rssfeed,numEpisodesIncomplete"}

2025-03-20 09:47:07.210

DEBUG

[ApiCacheManager] count: 6 size: 220721

2025-03-20 09:47:07.211

DEBUG

[ApiCacheManager] Cache hit: {"user":"v-audiobookshelf","url":"/libraries/4e463247-befe-4d55-95b6-8aaace238a8e/items?sort=addedAt&desc=1&limit=20&page=0&minified=1&include=rssfeed,numEpisodesIncomplete"}

2025-03-20 09:47:21.182

DEBUG

[ApiCacheManager] count: 6 size: 220721

2025-03-20 09:47:21.183

DEBUG

[ApiCacheManager] Cache hit: {"user":"v-audiobookshelf","url":"/libraries/4e463247-befe-4d55-95b6-8aaace238a8e/personalized?minified=1&include=rssfeed,numEpisodesIncomplete"}

Additional Notes

Docker running on a Synology NAS. I have a secondary installation on Ubuntu also running within Docker and it does not show the same issue. I've cleared the cache, but have not taken further steps to troubleshoot.

Originally created by @miketangovictor on GitHub (Mar 20, 2025). ### What happened? When attempting to open a podcast series with a large number of episodes on the iOS app (0.9.79-beta) the screen pauses, then disconnects and returns the user to the podcast home screen. This appears to be only on Podcasts with a large number of episodes (over 1,000 though have seen behavior with 800+ episodes as well). Logs do not show a crash, just the last event of the cache loading, then the user disconnecting and then the normal behavior of the app refreshing the data. The cycle continues. Behavior started long after the release of the the iOS app version, and believe it was timed to the server 2.20 release. ### What did you expect to happen? Expect to be able to open the episode list normally and have the app not crash. ### Steps to reproduce the issue 1. Add a Podcast with a large number of episodes. I've seen the behavior consistently with a library of over 1000 episodes like Stuff You Should Know. 2. Navigate to select the podcast, once selected the app pauses and the crash behavior takes place. ### Audiobookshelf version 2.20 ### 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? Other (list in "Additional Notes" box) ### Logs ```shell 2025-03-20 09:44:30.438 DEBUG [ApiCacheManager] Cache hit: {"user":"v-audiobookshelf","url":"/libraries/4e463247-befe-4d55-95b6-8aaace238a8e/items?sort=addedAt&desc=1&limit=20&page=-1&minified=1&include=rssfeed,numEpisodesIncomplete"} 2025-03-20 09:44:46.444 DEBUG [SocketAuthority] User Offline v-audiobookshelf 2025-03-20 09:44:46.446 INFO [SocketAuthority] Socket 5NQGqeCi86PFGpB_AADP disconnected from client "v-audiobookshelf" after 32307ms (Reason: transport close) 2025-03-20 09:44:47.111 DEBUG [ApiCacheManager] count: 6 size: 220721 2025-03-20 09:44:47.112 DEBUG [ApiCacheManager] Cache hit: {"user":"v-audiobookshelf","url":"/libraries"} 2025-03-20 09:44:47.126 INFO [SocketAuthority] Socket Connected to /socket.io B-H43Cg1FSbRVd00AADR 2025-03-20 09:44:47.128 DEBUG [ApiCacheManager] count: 6 size: 220721 2025-03-20 09:44:47.128 DEBUG [ApiCacheManager] Cache hit: {"user":"v-audiobookshelf","url":"/libraries/4e463247-befe-4d55-95b6-8aaace238a8e?include=filterdata"} 2025-03-20 09:44:47.132 DEBUG [SocketAuthority] User Online v-audiobookshelf 2025-03-20 09:44:47.151 DEBUG [ApiCacheManager] count: 6 size: 220721 2025-03-20 09:44:47.152 DEBUG [ApiCacheManager] Cache hit: {"user":"v-audiobookshelf","url":"/libraries/4e463247-befe-4d55-95b6-8aaace238a8e/personalized?minified=1&include=rssfeed,numEpisodesIncomplete"} 2025-03-20 09:44:52.342 DEBUG [ApiCacheManager] count: 6 size: 220721 2025-03-20 09:44:52.343 DEBUG [ApiCacheManager] Cache hit: {"user":"v-audiobookshelf","url":"/libraries/4e463247-befe-4d55-95b6-8aaace238a8e/items?sort=addedAt&desc=1&limit=20&page=0&minified=1&include=rssfeed,numEpisodesIncomplete"} 2025-03-20 09:47:07.210 DEBUG [ApiCacheManager] count: 6 size: 220721 2025-03-20 09:47:07.211 DEBUG [ApiCacheManager] Cache hit: {"user":"v-audiobookshelf","url":"/libraries/4e463247-befe-4d55-95b6-8aaace238a8e/items?sort=addedAt&desc=1&limit=20&page=0&minified=1&include=rssfeed,numEpisodesIncomplete"} 2025-03-20 09:47:21.182 DEBUG [ApiCacheManager] count: 6 size: 220721 2025-03-20 09:47:21.183 DEBUG [ApiCacheManager] Cache hit: {"user":"v-audiobookshelf","url":"/libraries/4e463247-befe-4d55-95b6-8aaace238a8e/personalized?minified=1&include=rssfeed,numEpisodesIncomplete"} ``` ### Additional Notes Docker running on a Synology NAS. I have a secondary installation on Ubuntu also running within Docker and it does not show the same issue. I've cleared the cache, but have not taken further steps to troubleshoot.
adam added the bug label 2026-04-25 00:09:32 +02:00
adam closed this issue 2026-04-25 00:09:32 +02:00
adam commented 2026-04-25 00:09:33 +02:00
Author
Owner
Copy Link
Copy Source

@nichwall commented on GitHub (Mar 20, 2025):

Is there anything in crash_logs.txt?

You can also check the docker logs for crash information.

@nichwall commented on GitHub (Mar 20, 2025): Is there anything in `crash_logs.txt`? You can also check the docker logs for crash information.
adam commented 2026-04-25 00:09:33 +02:00
Author
Owner
Copy Link
Copy Source

@miketangovictor commented on GitHub (Mar 20, 2025):

Good question, but nothing at all in the crash_logs.txt and the Docker logs for the container match the information that shows up in the debug logs in ABS.

When I watch traffic in the logs, you see traffic on the server when you first get to the "Library" page. When you click into a podcast, there is not any additional traffic on the server for it to load the list of episodes, so it tells me that the episode list for each of those has already been pre-loaded on the device when you first get to the Library page.

When you click into one of the series with a lot of episodes, it pauses, and the next traffic you see on the Server is the device disconnecting for the reason of Transport Close (which is typical). And then it just goes back through the same process of pulling the metadata including the episode lists.

I will try flushing the metadata next, but with this appearing to be tied to Podcasts with a lot of episodes, I can't help but think there is just an overflow somewhere.

@miketangovictor commented on GitHub (Mar 20, 2025): Good question, but nothing at all in the crash_logs.txt and the Docker logs for the container match the information that shows up in the debug logs in ABS. When I watch traffic in the logs, you see traffic on the server when you first get to the "Library" page. When you click into a podcast, there is not any additional traffic on the server for it to load the list of episodes, so it tells me that the episode list for each of those has already been pre-loaded on the device when you first get to the Library page. When you click into one of the series with a lot of episodes, it pauses, and the next traffic you see on the Server is the device disconnecting for the reason of Transport Close (which is typical). And then it just goes back through the same process of pulling the metadata including the episode lists. I will try flushing the metadata next, but with this appearing to be tied to Podcasts with a lot of episodes, I can't help but think there is just an overflow somewhere.
adam commented 2026-04-25 00:09:33 +02:00
Author
Owner
Copy Link
Copy Source

@nichwall commented on GitHub (Mar 20, 2025):

Hm. It is probably an issue with the app. Do you see "server starting" in the logs? Looking at the logs you shared again, the server startup message is not showing (it is multiple lines, somewhere between 20 and 100 depending on specific server configuration)

@nichwall commented on GitHub (Mar 20, 2025): Hm. It is probably an issue with the app. Do you see "server starting" in the logs? Looking at the logs you shared again, the server startup message is not showing (it is multiple lines, somewhere between 20 and 100 depending on specific server configuration)
adam commented 2026-04-25 00:09:33 +02:00
Author
Owner
Copy Link
Copy Source

@miketangovictor commented on GitHub (Mar 20, 2025):

I think I'm going to go ahead and close this. I'm not certain on the root cause, but I went through my files for each of the Podcasts and for those that were failing, I did find a number of duplicate files in my directory. In all cases they have the name of an episode followed by a long string of numbers such as (2993990a-9649-4ddd-86264-4a6b18b197b2). If I'm not mistaking, the files with this naming convention were included when there were errors in downloads and when they were replaced with a "clean" file the old was never automatically deleted.

I went through and deleted those files throughout and re-scanned my whole library and the symptom seems to have gone away. I'm still curious as to why this started now as most of these files have existed for 6+ months, but it was a worthwhile thing to cleanup either way.

@miketangovictor commented on GitHub (Mar 20, 2025): I think I'm going to go ahead and close this. I'm not certain on the root cause, but I went through my files for each of the Podcasts and for those that were failing, I did find a number of duplicate files in my directory. In all cases they have the name of an episode followed by a long string of numbers such as (2993990a-9649-4ddd-86264-4a6b18b197b2). If I'm not mistaking, the files with this naming convention were included when there were errors in downloads and when they were replaced with a "clean" file the old was never automatically deleted. I went through and deleted those files throughout and re-scanned my whole library and the symptom seems to have gone away. I'm still curious as to why this started now as most of these files have existed for 6+ months, but it was a worthwhile thing to cleanup either way.
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
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#2674
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?