mirror of
https://github.com/advplyr/audiobookshelf.git
synced 2026-05-30 23:40:40 +02:00
[Bug]: The device table seems to be getting endlessly populated by the iOS app Plappa #2710
Assignees
adam (Adam Melkus)
Clear assignees
adam (Adam Melkus)
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: starred/audiobookshelf#2710
Reference in New Issue
Block a user
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?
Originally created by @purple-emily on GitHub (Apr 11, 2025).
What happened?
There are 52,743 entries in my database.
There are a few "Unknown" entries listed:
What did you expect to happen?
A single entry for my phone?
Steps to reproduce the issue
Audiobookshelf version
v2.20.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
Additional Notes
No response
@Vito0912 commented on GitHub (Apr 11, 2025):
Plappa is a third-party app. This problem is likely due to their approach. So this issue should be reported to plappa instead
As an app developer, if you send a session, you can pass a device ID. The device ID does not appear to be constant for Plappa, which results in additional devices being added.
@LeoKlaus commented on GitHub (Apr 11, 2025):
Plappa doesn't provide a device ID at all, so I'm assuming the random ID is generated server side.
Should the device ID be considered mandatory?
@Vito0912 commented on GitHub (Apr 11, 2025):
The ID is not mandatory. It's probably good to provide one, but there shouldn't be any direct consequences if you don't (as you see. Nobody noticed xD). Every session will create a new device, and aside from potential "performance" issues (bc growing table), there should be no problem since the device is not used for anything else (afaik).
https://github.com/advplyr/audiobookshelf/blob/26309019e74e18b53e7029560ae4c927af9c8465/server/objects/DeviceInfo.js#L93
The device ID will simply be the autogenerated ID.
TLDR: No, but it does not hurt to provide one.
@purple-emily commented on GitHub (Apr 11, 2025):
So essentially that’s what’s happening. Plappa seems to be initiating a new session every few seconds and this creates a new entry making the device table grow rapidly. @LeoKlaus
@Vito0912 commented on GitHub (Apr 11, 2025):
Thanks for pointing that out. That does look odd indeed. I haven't been paying attention to the timestamp
As far as I know, (everything from now on is speculation without actually trying), one just creates the session (with deviceId which should create a new device) and then uses the generated sessionId to update that session.
It currently looks like a new session is created every 10 seconds, which seems very odd. @purple-emily, can you look in the setting under "Recent Sessions" to see what's displayed there?
@LeoKlaus commented on GitHub (Apr 11, 2025):
Just to clarify, plappa does not create a new session every ten seconds. The session and its ID stay the same until the app is restarted or playback is stopped.
@Vito0912 commented on GitHub (Apr 11, 2025):
@LeoKlaus I installed the app in the meantime and can reproduce the same behavior.
I am not sure which API endpoints you use, but they are used somewhat differentlyI found the "issue." You use:
/api/session/local/api/me/progress/batch/update/api/authorizeThe first two are an untraditional way of doing it, but there is nothing "wrong" with this (in theory).
(Nothing to do with the actual problem, just something I defintily want to point out bc of data usage)
However, you also call
/api/authorizeevery 10 seconds. If I may ask, why is that?The authorize endpoint returns the whole user. The user contains every progress ever listened to and bookmarks.
For my user (who has been using ABS for about a year), this amounts to 284KB being sent every 10 seconds, which seems very excessive.
Regarding the first two endpoints:
Is there a reason why you used these instead of
/sync? I cannot see the payload you send as I currently do not have the right software on hand, but I assume that you are just overwriting the session (not actually updating it, if you see it that way) and thus a new device gets generated (because you probably—again, just speculation—send the session with the ID but no device, which overwrites the session and therefore a new device gets generated).Also iirc
/api/session/localupdates the progress of the items anyways. So you don't need the second api callIf you want to chat about the API, I am open to help
@LeoKlaus commented on GitHub (Apr 11, 2025):
Thank you for taking the time to look into this.
The ABS integration for plappa was kinda rushed as plappa was originally intended to only support Jellyfin and Emby. Originally, plappa only supported progress syncing and when moving towards sessions, I left in the progress sync as some parts of the app still use progress instead of sessions for progress tracking. AFAIK, the authorize endpoint is the only one that returns progress for all items at once, though loading with every sync is excessive.
Simply put, I'm looking at a lot of tech debt that would require an entire rewrite of at least the API handling, but I haven't found the time for that so far.
The sessions are posted to the
/api/session/local-allin this format:My understanding is that this should update the existing session, not create a new one. If all that's needed to fix this for now is a static device id, I could add that fairly quickly (depending on how long Apple takes to approve the update).
I'll make sure to reach out once I find the time to rewrite the API handling in plappa, there are certainly parts of the ABS api I don't quite understand.
@Vito0912 commented on GitHub (Apr 11, 2025):
It's doing both, in a way. Some code, like checking if the device exists or creating a new device, runs again, and not all attributes are updated (that's why I call it overwritten). But the way you are doing it is the intended method.
As far as I know, you just have to add "deviceId" to the "deviceInfo" object to fix the creation of devices. I imagine some users definitely have millions of devices now ^^ xD. Also, I don't think you have to be quick. As far as I understand, this has been the case since the beginning of the abs part of the app, so yeah. I am not sure how a static id would interact with different users (but having the same deviceId). Probably no problem, but who knows.
Indeed, there is sadly no nice way. This is also a big bummer for my client that I am programming. Not even all progress for one library is possible (or not even all progress without the user and bookmarks).
/api/mealso returns that data (It only returns the server and not the server details).If it's just about retrieving the new progress from the server for the listening item, there is
/api/me/progress/<LibraryItemID>to get only the progress for that item.