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

@FreedomBen commented on GitHub (Oct 8, 2024):

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 commented on GitHub (Oct 8, 2024): 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.

adam commented

@FreedomBen commented on GitHub (Oct 8, 2024):

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 commented on GitHub (Oct 8, 2024): 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...

adam commented

@FreedomBen commented on GitHub (Oct 8, 2024):

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

@FreedomBen commented on GitHub (Oct 8, 2024): Confirmed: bug is _not_ present in 2.12.3, but _is_ present in 2.13.4. Will continue the narrowing process.

adam commented

@nichwall commented on GitHub (Oct 8, 2024):

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)?

@nichwall commented on GitHub (Oct 8, 2024): 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)?

adam commented

@FreedomBen commented on GitHub (Oct 16, 2024):

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 commented on GitHub (Oct 16, 2024): 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.

adam commented

https://github.com/advplyr/audiobookshelf/compare/v2.12.3...v2.13.0

@FreedomBen commented on GitHub (Oct 18, 2024):

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.

@FreedomBen commented on GitHub (Oct 18, 2024): 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. https://github.com/advplyr/audiobookshelf/compare/v2.12.3...v2.13.0

adam commented

@mikiher commented on GitHub (Nov 4, 2024):

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?

@mikiher commented on GitHub (Nov 4, 2024): 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?

adam commented

@vb0 commented on GitHub (Nov 4, 2024):

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).

@vb0 commented on GitHub (Nov 4, 2024): 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). ![image](https://github.com/user-attachments/assets/4db5f699-6a5b-47b0-998c-6bb59b55efec)

adam commented

@mikiher commented on GitHub (Nov 4, 2024):

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

@mikiher commented on GitHub (Nov 4, 2024): Thanks for the details. And are you logged in as root or some other user?

adam commented

@vb0 commented on GitHub (Nov 4, 2024):

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).

@vb0 commented on GitHub (Nov 4, 2024): 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).

adam commented

@nichwall commented on GitHub (Nov 4, 2024):

Some discussion over here as well https://github.com/advplyr/audiobookshelf-app/issues/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

@nichwall commented on GitHub (Nov 4, 2024): Some discussion over here as well https://github.com/advplyr/audiobookshelf-app/issues/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

adam commented

@vb0 commented on GitHub (Nov 4, 2024):

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.

@vb0 commented on GitHub (Nov 4, 2024): 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.

adam commented

@mikiher commented on GitHub (Nov 5, 2024):

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 commented on GitHub (Nov 5, 2024): 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](https://github.com/advplyr/audiobookshelf-app/blob/a163a6af88627ac034d8616a3df87191eb4db075/pages/item/_id/index.vue#L287-L290)): ```js 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.

adam commented

@mikiher commented on GitHub (Nov 5, 2024):

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.

@mikiher commented on GitHub (Nov 5, 2024): 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.

adam commented

@advplyr commented on GitHub (Nov 5, 2024):

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.

@advplyr commented on GitHub (Nov 5, 2024): 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.

adam commented

@nichwall commented on GitHub (Nov 5, 2024):

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.

@nichwall commented on GitHub (Nov 5, 2024): 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.

adam commented

@advplyr commented on GitHub (Nov 5, 2024):

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?

@advplyr commented on GitHub (Nov 5, 2024): 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?

adam commented

@nichwall commented on GitHub (Nov 5, 2024):

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.

@nichwall commented on GitHub (Nov 5, 2024): 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.

adam commented

@advplyr commented on GitHub (Nov 5, 2024):

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

@advplyr commented on GitHub (Nov 5, 2024): 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

adam commented

@nichwall commented on GitHub (Nov 5, 2024):

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.

@nichwall commented on GitHub (Nov 5, 2024): 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.

adam commented

@mikiher commented on GitHub (Nov 5, 2024):

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 commented on GitHub (Nov 5, 2024): 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?

adam commented

@mikiher commented on GitHub (Nov 5, 2024):

The server still allows connecting with old user ids.

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

@mikiher commented on GitHub (Nov 5, 2024): > The server still allows connecting with old user ids. Is there a good reason for allowing that after v2.13.0?

adam commented

@advplyr commented on GitHub (Nov 5, 2024):

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.

@advplyr commented on GitHub (Nov 5, 2024): 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.

adam commented

@Pwnz74 commented on GitHub (Nov 28, 2024):

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.

@Pwnz74 commented on GitHub (Nov 28, 2024): 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.

adam commented