You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
So I have an issue that has occured when using the IOS app through testflight or through sidestore. The issue is I will do a listening session for a book lets say for example it starts at timestamp 1:00:00, I will listen for 30 minutes. Then I will pause/stop playback or change Bluetooth devices (headset to car or vice versa). When I go to resume the playback the app will not respond/crash and then switch to playing Apple Music instead. When I go into the app I see a websocket error and it acts like my most recent playback session did not happen it will start back at the 1:00:00 timestamp and I have to fast-forward back to where I was. I have enabled websocket support through my nginx proxy manager setup. The book can be downloaded or streamed does not seem to make a difference.
What did you expect to happen?
I would expect it to start playback from where I last left off.
Steps to reproduce the issue
Listen to book for awhile on IOS app
Pause playback
Resume playback
Audiobookshelf version
2.17.5
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
I think this is the correct stuff from the logs
2024-12-30 09:46:07.055
DEBUG
[PlaybackSessionManager] startSessionRequest for device iPhone13,2 / v0.9.77
2024-12-30 09:46:07.056
DEBUG
[PlaybackSessionManager] "abateman" starting direct play session for item "bb299510-3e83-4f27-9437-19c917a24ea5" with id 9c0bde32-e499-4450-8ca9-88a979f432f9 (Device: iPhone13,2 / v0.9.77)
2024-12-30 09:46:10.863
DEBUG
[PlaybackSessionManager] syncSession "9c0bde32-e499-4450-8ca9-88a979f432f9" (Device: iPhone13,2 / v0.9.77) | Total Time Listened: 0
2024-12-30 09:46:37.105
DEBUG
[PlaybackSessionManager] syncSession "9c0bde32-e499-4450-8ca9-88a979f432f9" (Device: iPhone13,2 / v0.9.77) | Total Time Listened: 26.23524498939514
2024-12-30 09:47:07.073
DEBUG
[PlaybackSessionManager] syncSession "9c0bde32-e499-4450-8ca9-88a979f432f9" (Device: iPhone13,2 / v0.9.77) | Total Time Listened: 56.21263098716736
2024-12-30 09:47:22.065
DEBUG
[PlaybackSessionManager] syncSession "9c0bde32-e499-4450-8ca9-88a979f432f9" (Device: iPhone13,2 / v0.9.77) | Total Time Listened: 71.21701383590698
2024-12-30 09:47:52.082
DEBUG
[PlaybackSessionManager] syncSession "9c0bde32-e499-4450-8ca9-88a979f432f9" (Device: iPhone13,2 / v0.9.77) | Total Time Listened: 101.22532081604004
2024-12-30 09:48:07.070
DEBUG
[PlaybackSessionManager] syncSession "9c0bde32-e499-4450-8ca9-88a979f432f9" (Device: iPhone13,2 / v0.9.77) | Total Time Listened: 116.23482894897461
2024-12-30 09:48:22.103
DEBUG
[PlaybackSessionManager] syncSession "9c0bde32-e499-4450-8ca9-88a979f432f9" (Device: iPhone13,2 / v0.9.77) | Total Time Listened: 131.23537588119507
2024-12-30 09:48:52.103
DEBUG
[PlaybackSessionManager] syncSession "9c0bde32-e499-4450-8ca9-88a979f432f9" (Device: iPhone13,2 / v0.9.77) | Total Time Listened: 161.2343168258667
2024-12-30 09:49:22.093
DEBUG
[PlaybackSessionManager] syncSession "9c0bde32-e499-4450-8ca9-88a979f432f9" (Device: iPhone13,2 / v0.9.77) | Total Time Listened: 191.23461484909058
2024-12-30 09:49:47.604
DEBUG
[PlaybackSessionManager] syncSession "9c0bde32-e499-4450-8ca9-88a979f432f9" (Device: iPhone13,2 / v0.9.77) | Total Time Listened: 206.23501110076904
2024-12-30 09:59:49.390
INFO
[PlaybackSessionManager] Syncing local session "The Swarm" (0178AD96-86B0-4F6E-9152-4945CEE2CC8B)
2024-12-30 09:59:49.427
DEBUG
[PlaybackSessionManager] Updated session for"The Swarm" (0178AD96-86B0-4F6E-9152-4945CEE2CC8B)
2024-12-30 09:59:49.465
DEBUG
[PlaybackSessionManager] Not updating progress for"The Swarm" because it has been updated more recently
Additional Notes
My setup for accessing it remotely is using my FQDN setup with Nginx proxy manager. I have websocket support, cache assets, block common exploits enabled in NGPM crash_logs.txt
So just experienced the issue again while on my home network. The playback went back about 20 minutes or so from where I stopped the playback. Pulled the daily and crash logs and uploaded them here
The text was updated successfully, but these errors were encountered:
I will also try to remember to grab logs and record timestamps when it happens again. This issue is not 100% reproducible. I would say it happens like one out of every 5 or so playback sessions
2025-01-02.txt
What happened?
So I have an issue that has occured when using the IOS app through testflight or through sidestore. The issue is I will do a listening session for a book lets say for example it starts at timestamp 1:00:00, I will listen for 30 minutes. Then I will pause/stop playback or change Bluetooth devices (headset to car or vice versa). When I go to resume the playback the app will not respond/crash and then switch to playing Apple Music instead. When I go into the app I see a websocket error and it acts like my most recent playback session did not happen it will start back at the 1:00:00 timestamp and I have to fast-forward back to where I was. I have enabled websocket support through my nginx proxy manager setup. The book can be downloaded or streamed does not seem to make a difference.
What did you expect to happen?
I would expect it to start playback from where I last left off.
Steps to reproduce the issue
Audiobookshelf version
2.17.5
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
Additional Notes
My setup for accessing it remotely is using my FQDN setup with Nginx proxy manager. I have websocket support, cache assets, block common exploits enabled in NGPM
crash_logs.txt
2025-01-02.txt
So just experienced the issue again while on my home network. The playback went back about 20 minutes or so from where I stopped the playback. Pulled the daily and crash logs and uploaded them here
The text was updated successfully, but these errors were encountered: