[Bug] Local listening sessions showing on the wrong day #1844

New Issue

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

adam commented

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

Originally created by @rasmuslos on GitHub (Mar 28, 2024).

Describe the feature/enhancement

Right now the only way to modify the listing statistics is to use the sessions endpoint. But if a user has, for example, listened to an item for four hours yesterday and three hours today, but not synced their progress to the server for a few days, everything will be squashed together on the day the session is updated.

A dedicated statics endpoint you could send something like

{
    1711494000: 10800000,
    1711580400: 14400000,
}

timestamp at 00:00: time listened

would make it possible to accurately keep track of listening statistics while the user is offline.

Originally created by @rasmuslos on GitHub (Mar 28, 2024). ### Describe the feature/enhancement Right now the only way to modify the listing statistics is to use the sessions endpoint. But if a user has, for example, listened to an item for four hours yesterday and three hours today, but not synced their progress to the server for a few days, everything will be squashed together on the day the session is updated. A dedicated statics endpoint you could send something like ``` { 1711494000: 10800000, 1711580400: 14400000, } ``` `timestamp at 00:00: time listened` would make it possible to accurately keep track of listening statistics while the user is offline.

adam added the bug label 2026-04-24 23:59:45 +02:00

adam closed this issue

2026-04-24 23:59:46 +02:00

adam commented

2026-04-24 23:59:46 +02:00

@advplyr commented on GitHub (Mar 28, 2024):

I believe I fixed this in v2.8.0. The problem was in the migration to sql the sequelize ORM was automatically updating the updatedAt and createdAt timestamps instead of using the timestamps passed in from the local session.

@advplyr commented on GitHub (Mar 28, 2024): I believe I fixed this in v2.8.0. The problem was in the migration to sql the sequelize ORM was automatically updating the `updatedAt` and `createdAt` timestamps instead of using the timestamps passed in from the local session.

adam commented

2026-04-24 23:59:47 +02:00

@rasmuslos commented on GitHub (Mar 28, 2024):

So if I want to report the time listened for yesterday I can send a session object with the timeListened and updatedAt properties with the previous values and for today I can do the same thing with the correct values?

@rasmuslos commented on GitHub (Mar 28, 2024): So if I want to report the time listened for yesterday I can send a session object with the `timeListened` and `updatedAt` properties with the previous values and for today I can do the same thing with the correct values?

adam commented

2026-04-24 23:59:47 +02:00

@advplyr commented on GitHub (Mar 28, 2024):

Yes but only for the /session/local and /session/local-all endpoints. I tested this quite a bit when I made that change 2 months ago but please test it again to make sure

@advplyr commented on GitHub (Mar 28, 2024): Yes but only for the `/session/local` and `/session/local-all` endpoints. I tested this quite a bit when I made that change 2 months ago but please test it again to make sure

adam commented

2026-04-24 23:59:48 +02:00

@rasmuslos commented on GitHub (Mar 30, 2024):

So I am currently looking into implementing this and found two things:

Is there any documentation for local sessions? By looking through the code I found that prefixing the identifier with play_local_ is a good idea but I could not find this documented anywhere
Is this (PlaybackSessionManager.js#L147) desired behavior? Because looking at ApiRouter.js#L477 it seems like sessions are grouped based on their date and the session manger uses the current date, not the one the session provides
https://github.com/advplyr/audiobookshelf/blob/93bec282d22e954097753c0210450b9f917a3e8e/server/managers/PlaybackSessionManager.js#L147

@rasmuslos commented on GitHub (Mar 30, 2024): So I am currently looking into implementing this and found two things: 1. Is there any documentation for local sessions? By looking through the code I found that prefixing the identifier with `play_local_` is a good idea but I could not find this documented anywhere 2. Is this (`PlaybackSessionManager.js#L147`) desired behavior? Because looking at `ApiRouter.js#L477` it seems like sessions are grouped based on their date and the session manger uses the current date, not the one the session provides https://github.com/advplyr/audiobookshelf/blob/93bec282d22e954097753c0210450b9f917a3e8e/server/managers/PlaybackSessionManager.js#L147

adam commented

2026-04-24 23:59:48 +02:00

@advplyr commented on GitHub (Mar 30, 2024):

No we don't want to use play_local_ anymore. It has to be UUIDv4. I just looked at the docs and realize it is out of date so I'm going to update this now. https://api.audiobookshelf.org/#sync-local-sessions

It has to be a UUIDv4 identifier because it is inserted into the database. This way you can send the same local playback session to the server and it will only overwrite the existing local session after it gets created.

Ah that is a nice catch. That looks like a bug that might be what users have been bringing up for a while now and I didn't see because I'm only testing over the same day. I'll follow up about this.

@advplyr commented on GitHub (Mar 30, 2024): 1. No we don't want to use `play_local_` anymore. It has to be UUIDv4. I just looked at the docs and realize it is out of date so I'm going to update this now. https://api.audiobookshelf.org/#sync-local-sessions It has to be a UUIDv4 identifier because it is inserted into the database. This way you can send the same local playback session to the server and it will only overwrite the existing local session after it gets created. 2. Ah that is a nice catch. That looks like a bug that might be what users have been bringing up for a while now and I didn't see because I'm only testing over the same day. I'll follow up about this.

adam commented

2026-04-24 23:59:49 +02:00

@advplyr commented on GitHub (Mar 30, 2024):

There is one issue with the current playback sessions model that is going to require a refactor of the data model. Currently playback sessions can only store a single date. I re-read your original post and realized that it is not going to be possible to show the listening session on both days.

There is already a bug report open for that. I'm not sure yet how to handle this because I don't want to completely change everything.

@advplyr commented on GitHub (Mar 30, 2024): There is one issue with the current playback sessions model that is going to require a refactor of the data model. Currently playback sessions can only store a single date. I re-read your original post and realized that it is not going to be possible to show the listening session on both days. There is already a bug report open for that. I'm not sure yet how to handle this because I don't want to completely change everything.

adam commented

2026-04-24 23:59:49 +02:00

@advplyr commented on GitHub (Mar 30, 2024):

I also want to reference this old commit where I fixed the date and dayOfWeek property when creating the playback session from the local playback session on the server side https://github.com/advplyr/audiobookshelf/commit/20a1d40d990b1d14750ba061a0dd808a016cb0ec

The commit I just made fixes the one you pointed out where updates to the playback session are using the current date and dayOfWeek instead of what is passed in.

@advplyr commented on GitHub (Mar 30, 2024): I also want to reference this old commit where I fixed the `date` and `dayOfWeek` property when creating the playback session from the local playback session on the server side https://github.com/advplyr/audiobookshelf/commit/20a1d40d990b1d14750ba061a0dd808a016cb0ec The commit I just made fixes the one you pointed out where updates to the playback session are using the current date and dayOfWeek instead of what is passed in.

adam commented

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

@advplyr commented on GitHub (Mar 30, 2024):

Your issue is actually a duplicate of https://github.com/advplyr/audiobookshelf/issues/1445

The docs I will update with UUIDv4

@advplyr commented on GitHub (Mar 30, 2024): Your issue is actually a duplicate of https://github.com/advplyr/audiobookshelf/issues/1445 The docs I will update with UUIDv4

adam commented

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

@rasmuslos commented on GitHub (Mar 31, 2024):

Nice that that has been resolved!

I also wanted do ask how verbose my session objects should be. Is it enough to include the duration listened and the updated at timestamp or are there more required fields / are they automatically added when the session is inserted into the database?

@rasmuslos commented on GitHub (Mar 31, 2024): Nice that that has been resolved! I also wanted do ask how verbose my session objects should be. Is it enough to include the duration listened and the updated at timestamp or are there more required fields / are they automatically added when the session is inserted into the database?

adam commented

2026-04-24 23:59:51 +02:00

@advplyr commented on GitHub (Mar 31, 2024):

It is expecting the entire playback session https://api.audiobookshelf.org/#playback-session

You don't need to include the date and dayOfWeek, those will be set automatically using the updatedAt timestamp you pass in.

@advplyr commented on GitHub (Mar 31, 2024): It is expecting the entire playback session https://api.audiobookshelf.org/#playback-session You don't need to include the `date` and `dayOfWeek`, those will be set automatically using the `updatedAt` timestamp you pass in.

adam commented

2026-04-24 23:59:51 +02:00

@rasmuslos commented on GitHub (Mar 31, 2024):

It is expecting the entire playback session https://api.audiobookshelf.org/#playback-session

You don't need to include the date and dayOfWeek, those will be set automatically using the updatedAt timestamp you pass in.

Even when I create a new local session all fields like mediaMetadata have to be present?

@rasmuslos commented on GitHub (Mar 31, 2024): > It is expecting the entire playback session https://api.audiobookshelf.org/#playback-session > > You don't need to include the `date` and `dayOfWeek`, those will be set automatically using the `updatedAt` timestamp you pass in. Even when I create a new local session all fields like `mediaMetadata` have to be present?

adam commented

2026-04-24 23:59:51 +02:00

@advplyr commented on GitHub (Mar 31, 2024):

I'm not sure what you mean by create a new local session. The same endpoint is used for create/update and it expects the full playback session object each time because it is just overwriting that record in the db.
I have some ideas on setting up a better system for that but as of now you need to manage and pass in the full object for those offline sessions.

@advplyr commented on GitHub (Mar 31, 2024): I'm not sure what you mean by create a new local session. The same endpoint is used for create/update and it expects the full playback session object each time because it is just overwriting that record in the db. I have some ideas on setting up a better system for that but as of now you need to manage and pass in the full object for those offline sessions.

adam commented

2026-04-24 23:59:51 +02:00

@rasmuslos commented on GitHub (Mar 31, 2024):

I'm not sure what you mean by create a new local session. The same endpoint is used for create/update and it expects the full playback session object each time because it is just overwriting that record in the db. I have some ideas on setting up a better system for that but as of now you need to manage and pass in the full object for those offline sessions.

Ok, i was wondering because with the current system I have to make an API call for each item that I want to create a session for, not ideal but also not that bad.

Thanks for your help!

@rasmuslos commented on GitHub (Mar 31, 2024): > I'm not sure what you mean by create a new local session. The same endpoint is used for create/update and it expects the full playback session object each time because it is just overwriting that record in the db. I have some ideas on setting up a better system for that but as of now you need to manage and pass in the full object for those offline sessions. Ok, i was wondering because with the current system I have to make an API call for each item that I want to create a session for, not ideal but also not that bad. Thanks for your help!

adam commented

2026-04-24 23:59:51 +02:00

@advplyr commented on GitHub (Mar 31, 2024):

You only need to do that for sessions they are connected to the server for if you want to make real-time progress updates. The local listening session endpoints are for offline listening sessions. So you wouldn't be able to create the listening session via the API because they were offline when you created it.
Alternatively you can use it to sync a listening session you created via the API if for example they lose network connection part-way and they listened for an extended period of time offline that couldn't be synced

@advplyr commented on GitHub (Mar 31, 2024): You only need to do that for sessions they are connected to the server for if you want to make real-time progress updates. The local listening session endpoints are for offline listening sessions. So you wouldn't be able to create the listening session via the API because they were offline when you created it. Alternatively you can use it to sync a listening session you created via the API if for example they lose network connection part-way and they listened for an extended period of time offline that couldn't be synced

adam commented

2026-04-24 23:59:51 +02:00

@rasmuslos commented on GitHub (Apr 1, 2024):

I want to use them for items that the user listened to that they have downloaded. I will keep track of the time listened and when the item is finished the tracked progress can be uploaded to the server, either after the playback stopped, or if no internet connection is available at the next possible time.

So i will only really be creating sessions and because I don't store the entirety of an item metadata on device the app has to make an additional call to the API to get all metadata fields to create the sessions.
This is purely to keep allow the server to keep track of the time listened, when the user has downloaded an audiobook the progress is already updated using the api/me/progress endpoint.

@rasmuslos commented on GitHub (Apr 1, 2024): I want to use them for items that the user listened to that they have downloaded. I will keep track of the time listened and when the item is finished the tracked progress can be uploaded to the server, either after the playback stopped, or if no internet connection is available at the next possible time. So i will only really be creating sessions and because I don't store the entirety of an item metadata on device the app has to make an additional call to the API to get all metadata fields to create the sessions. This is purely to keep allow the server to keep track of the time listened, when the user has downloaded an audiobook the progress is already updated using the `api/me/progress` endpoint.

adam commented

2026-04-24 23:59:52 +02:00

@advplyr commented on GitHub (Apr 22, 2024):

Fixed in v2.9.0

@advplyr commented on GitHub (Apr 22, 2024): Fixed in [v2.9.0](https://github.com/advplyr/audiobookshelf/releases/tag/v2.9.0)

Sign in to join this conversation.

Branches Tags

master

book_tags_genres_dedupe

episode_download_fallback

Issue-4540-SortBy-StartedDate-and-FinishedDate

episode_meta_tagging

fix_authorize_race_condition

redirect_transcode_requests

progress_updated_sort

fix_ereader_socket_event

fix_change_empty_root_password

fix_podcast_session_track_index

fix_set_token

session_modal_user

localize_durations

fix_oidc_create_user

jwt_auth_refactor

fix_scanner_deleting_single_file_books

fix_mediaprogress_updatedat_2

experimental_next_client

podcast_episode_duration

episode-timestamps-clickable

book_author_secondary_sort_title

podcast_useragents

pathexists_user_access

fix_pathexists_join

book_author_secondary_sort

clean_duplicate_mediaprogress

sanitize_html_description

trix_prevent_attachments

check_path_api_fix

fix_mediaprogress_updatedat

increase_express_json_limit

fix_dockerfile_nunicode

search_episodes

audiobook_tools_update

episode_secondary_sorts

hls_stream_url_update

new_session_track_endpoint

audiobook_tools_enhancements

watcher_rescans_update

player_track_tooltip

fix_exclude_prefixes_crash

socket_item_events

fix_podcast_episode_scanner_promise

new_stats_controller

count_cache_for_userpermissions

parsing-opf-v3

validate_migration_files

fix-quick-match-all-crash

fix-chapter-end-sleep-timer

stringify_sequelize_query

remove-col-ambiguity

fix_next_prev_edit_description

details_trim_whitespace

fix_content_url_basepath

fix_logger_fatal

progress_bar_visibility

batch-edit-populate-map-details

feed_generator_updates

bookmark-modal-updates

migrate-library-item-in-scanner

migrate-new-library-items

migrate-podcasts-new-library-item-2

migrate-podcasts-new-library-item

fix-remove-episode-from-playlist

playback-session-use-new-library-item

refactor-library-item

fix-heatmap-caption

feed-episodes-upsert

share-media-player-media-session-api

remove-old-playlist

remove_old_collection_object

plugin-implementation-demo

feed_migration

refactor-feeds-from-item

fix_remove_authors_no_books

v2.17.3-fk-constraints-migration

migrations-first-upgrade

sqlite_2

feature/nuxt-target-server

waveform

sqlite

playlists

video

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/audiobookshelf#1844