[Bug]: 2.13.x introduced something that breaks the user linking on the mobile app

[FreedomBen]

What happened?

After upgrading from 2.12.3 to 2.13.4, the mobile app no longer recognizes that the local user is the same as the remote user, and thus we get the message saying that progress will not be synced (and it really isn't).

What did you expect to happen?

Progress continues to sync with local media as it did before.

Steps to reproduce the issue

1. Upgrade to 2.13.4
2. Download an audiobook for offline/local playback
3. Observe the message saying that progress won't be synced because the book was downloaded by a different user (even though it wasn't)

Audiobookshelf version

v2.13.4

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

Nothing relevant in the logs

Additional Notes

Downgrading back to 2.12.3 fixes the issue

[FreedomBen]

Well damn, standby on this one. I'm currently working on narrowing down the exact version that introduced the bug and after downgrading and working my way back up, it's now working on 2.13.4. I'll play with it a bit more but if I can't reproduce then I'll close this.

[FreedomBen]

Ok now after doing a full library scan, it's back. I need to re-test the other versions now with also doing a full scan, so the debugging continues...

[FreedomBen]

Confirmed: bug is not present in 2.12.3, but is present in 2.13.4. Will continue the narrowing process.

[nichwall]

2.13.x included cleaning up old data models from before the SQLite database, so may be related to something there. I assume the issue does not go away on 2.14.0 (released 3 days ago)?

[FreedomBen]

Had to suspend debugging effort because my hard drive filled up. Btw, BTRFS really doesn't do well when full. The read/write speeds slowed down to absurd levels, which made it impossible to boot from the drive. I booted with a live disc and started cleaning stuff up, but it took days to move 20 GB of data. Finally back up so will resume debugging as I have time.

[FreedomBen]

Ok, confirmed that the bug was introduced in 2.13.0. It is not present in 2.12.3.

And damn, there's a lot of changes between the two... I'll look through the changes and see if anything stands out, but I'm not super optimistic.

v2.12.3...v2.13.0

[mikiher]

There were certainly many changes around the user model in 2.13.0.

Are you still observing the issue with the latest server version (2.16.2)?
Also, for the record, which client version are you using?

Can you please take a screenshot of the message you're seeing on the client and put it here?

[vb0]

This bug is happening to me since a while too. Can reproduce on the latest server and app, at least as far as they get automatically updated: 2.16.2 with 0.9.76-beta

For what is worth the server has just one user (and the client connects only to this server, is a really tiny setup).

[mikiher]

Thanks for the details. And are you logged in as root or some other user?

[vb0]

I have just one account overall, that is also "Account Type: root".
(also I had only one user, and the same, ever since I installed it -early 2023- BTW the software is absolutely great, never had any trouble whatsoever, even this is minor, but just wanted to help the OP to get it fixed and confirm the issue).

[nichwall]

Some discussion over here as well advplyr/audiobookshelf-app#1320

Do you know when the last time you signed in to the server was? There was an issue a while ago (may have been during the SQlite migration in 2.3.x, but I think it was a few server versions afterwards when the issue popped up and I can't find the relevant discussions) where the old user ID was incorrectly being checked by the app against the new user ID. Resetting the app/deleting the server connection fixed it at that time and users are currently reporting the issue resolved when they reset the app in this same way. I'm not sure if this is the same issue, but it may be related.

Edit to add: a later app update added the checking against the old user ID back in to fix it, so the server may no longer be providing the old user ID

[vb0]

Good idea, I actually logged in again not a long time ago (this issue was there both before and after), but I didn't reinstall/wipe storage for the app. Now I did it and the message is gone, but I'm reluctant to say it's fixed because last time I tried to "fix" this I removed all downloads, then downloaded just one audiobook (just as now too) but it took some time for the message to appear again. In any case I'm using this daily, if it comes back again I'll update here.

[mikiher]

OK, here's my analysis of what's happening:

The book was downloaded to local storage with an oldUserId (probably a long time ago?). The oldUserId was stored locally in the book's localLibraryItem.serverUserId, in order to match against the server's oldUserId (see code here):

    isLocalMatchingUser() {
      if (this.isLocalOnly || !this.localLibraryItem || !this.user) return false
      return this.localLibraryItem.serverUserId === this.user.id || this.localLibraryItem.serverUserId === this.user.oldUserId
    },

Since server release v2.13.0, the user record returned from the server during login no longer contains oldUserId, so this.localLibraryItem.serverUserId === this.user.oldUserId is now false instead of true.

@advplyr, maybe this can be fixed with some local db "migration" in the app, but this will probably be an overkill.

My recommendation would be to remove the local item and re-download it. This might be a bit inconvenient but will most probably solve the sync issue.

[mikiher]

So for those who want a quick resolution without the technical details:

After upgrading to server release > v2.13.0, delete the book from local storage and re-download it, and the sync issue will go away.

A future version of the mobile app may resolve this without needing to re-download, but the fix might not happen due to its complexity, so probably don't count on it.

[advplyr]

Ah yeah I removed the old user id in v2.13.0. It's been almost 18 months since we stopped using the old user id and I didn't think about old downloads.

I don't think it is worth the effort of fixing this one since re-downloading fixes it.

[nichwall]

I think the distinction is how the user signs in as well, because there have been a few people who have mentioned "redownloading did not fix it", but I'm not sure if they mean redownloading the book, redownloading the app without clearing cache, or something else.

Users who completely sign out (remove server from app, sign in again and redownload media) have reported the problem as fixed.

Edit to add: I think the other problem is people not updating their servers, so they (and we) don't realize they were on an old server version more recently. Probably less common, but I think all reports are people who have been using ABS for a while and more likely to fall in the "did not update server" category.

[advplyr]

You're right, that is a bit more problematic. The saved connection on the device also stores the user id which could be an old user id if set up before July 2023.
The server still allows connecting with old user ids.

Do we know that removing the connection and adding it again fixes it for future downloads?

[nichwall]

The steps I have told people to do (in several GH issues and on Discord since it happened originally with the database migration, and some in more recent weeks) are to reset the app to be safe, and then sign in from a fresh state since at the time I wasn't exactly sure if there was a migration issue or if it was the app getting into a weird state. Every time someone reset the app, they reported the problem being fixed. The main complaint was needing to redo any downloads, which they did not consider as a good fix for less tech-saavy family members.

I believe just removing the server connection and signing in again would achieve the same thing if the old user ID is part of the connection.

[advplyr]

I thought with the db migration users had to set up a new connection and we went through that process of asking users to set up a new connection

[nichwall]

I think a number of people just didn't do it because we added the "old user ID check" to the app, so yes a lot of people signed out/in, but other people just didn't do it, which would also explain why it was difficult to track down.

[mikiher]

OK, so can we just state here clearly what are the resolution steps, based on the discussion above, for the benefit of the bug's reporters?

[mikiher]

The server still allows connecting with old user ids.

Is there a good reason for allowing that after v2.13.0?

[advplyr]

I'm hoping to push the mobile app release this afternoon. Maybe I can see about adding in a message notifying users with old IDs to set up a new connection. That would be easier than building out a script that does it automatically and we could give a week or 2 before forcing it in a server update.

[Pwnz74]

I got server version: 2.17 redownload did not worked for me after removal of local item. It did not even work on 2.16.
Use using root both App and server.

[nichwall]

I got server version: 2.17 redownload did not worked for me after removal of local item. It did not even work on 2.16.
Use using root both App and server.

You need to delete the connection to the server (from the Switch User/Server menu) within the mobile app, or reset the app data/cache. The user ID is linked to when you originally logged in to the server.

Edit to add: the problem is with the user ID from before 2.4.0, released about year and a half ago.