[Enhancement]: Claim orphaned downloads when server address changes, but server itself is the same #1086

Open
opened 2026-04-24 23:48:05 +02:00 by adam · 8 comments
Owner

Originally created by @notoriousjere on GitHub (Nov 20, 2024).

Describe the Feature/Enhancement

Add the ability to claim orphaned downloaded files in cases where the server itself is the same as the one that the download belonged to, but it's address merely changed.

Why would this be helpful?

I recently migrated my docker-managed server from Computer A with IP address 192.168.1.6 to Computer B with IP address 192.168.1.7. I then changed the Static IP of Computer B to 192.168.1.8. For each of these changes, all of my locally downloaded books showed this message:

Media is linked to an Audiobookshelf serer on a different address (<address>). Progress will be synced when connected to this server address.

I had to delete all of my locally downloaded books and re-download them each time my server's IP changed, which is a process I feel the app could handle doing itself.

Future Implementation (Screenshot)

This could be a button shown on the dialog box. The button would kick off a process to match the orphaned book to the newly connected server (in my case, it'd be the same one it belonged to, but just had a different IP address). This process could succeed or fail. A warning to the user that the downloaded media would no longer be linked to the old server feels like it would apply here.

mockup

Audiobookshelf App Version

Android App - 0.9.77

Current Implementation (Screenshot)

share_844640594064513293

Originally created by @notoriousjere on GitHub (Nov 20, 2024). ### Describe the Feature/Enhancement Add the ability to claim orphaned downloaded files in cases where the server itself is the same as the one that the download belonged to, but it's address merely changed. ### Why would this be helpful? I recently migrated my docker-managed server from Computer A with IP address 192.168.1.6 to Computer B with IP address 192.168.1.7. I then changed the Static IP of Computer B to 192.168.1.8. For each of these changes, all of my locally downloaded books showed this message: > Media is linked to an Audiobookshelf serer on a different address (\<address\>). Progress will be synced when connected to this server address. I had to delete all of my locally downloaded books and re-download them each time my server's IP changed, which is a process I feel the app could handle doing itself. ### Future Implementation (Screenshot) This could be a button shown on the dialog box. The button would kick off a process to match the orphaned book to the newly connected server (in my case, it'd be the same one it belonged to, but just had a different IP address). This process could succeed or fail. A warning to the user that the downloaded media would no longer be linked to the old server feels like it would apply here. ![mockup](https://github.com/user-attachments/assets/48831b94-1a3a-4ba6-9b25-166e44d1e2dc) ### Audiobookshelf App Version Android App - 0.9.77 ### Current Implementation (Screenshot) ![share_844640594064513293](https://github.com/user-attachments/assets/5d8fe5cc-4bc8-43c9-a863-8bce6896cdeb)
adam added the enhancement label 2026-04-24 23:48:05 +02:00
Author
Owner

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

Related to https://github.com/advplyr/audiobookshelf-app/issues/209

@nichwall commented on GitHub (Nov 20, 2024): Related to https://github.com/advplyr/audiobookshelf-app/issues/209
Author
Owner

@brent-holland commented on GitHub (Nov 28, 2024):

This would be super helpful to keep syncing media with my laptop when I'm on a diff network

@brent-holland commented on GitHub (Nov 28, 2024): This would be super helpful to keep syncing media with my laptop when I'm on a diff network
Author
Owner

@bigbeka commented on GitHub (Jun 8, 2025):

I came across the same issue. Is this a planned feature/enhancement?

@bigbeka commented on GitHub (Jun 8, 2025): I came across the same issue. Is this a planned feature/enhancement?
Author
Owner

@TheTerrasque commented on GitHub (Jul 14, 2025):

I just got hit by this issue too. I don't understand, how is this even a problem? Server lists library, says book X is at progress Y, you open that book on app and moves to that progress, then report progress as it's played / read. Where does it even come in that you also read the same book on a different server before? Why does that matter at all?

@TheTerrasque commented on GitHub (Jul 14, 2025): I just got hit by this issue too. I don't understand, how is this even a problem? Server lists library, says book X is at progress Y, you open that book on app and moves to that progress, then report progress as it's played / read. Where does it even come in that you also read the same book on a different server before? Why does that matter at all?
Author
Owner

@nichwall commented on GitHub (Jul 14, 2025):

I just got hit by this issue too. I don't understand, how is this even a problem? Server lists library, says book X is at progress Y, you open that book on app and moves to that progress, then report progress as it's played / read. Where does it even come in that you also read the same book on a different server before? Why does that matter at all?

Servers are defined by their connection profile, which is the user and address used to connect to the server. If you connect to the server using a different IP or domain name, you are using a new connection profile because servers do not have a unique identifier. At the time, users were defined by username and could have name collisions across servers (such as "root" or "admin", or if you and your friend each have a server and used the same username). Users are now defined by the UUID in the SQLite database. More information in https://github.com/advplyr/audiobookshelf-app/issues/1401

As to why it matters, the app supports multiple users and connecting to multiple different servers.

@nichwall commented on GitHub (Jul 14, 2025): > I just got hit by this issue too. I don't understand, how is this even a problem? Server lists library, says book X is at progress Y, you open that book on app and moves to that progress, then report progress as it's played / read. Where does it even come in that you also read the same book on a different server before? Why does that matter at all? Servers are defined by their connection profile, which is the user and address used to connect to the server. If you connect to the server using a different IP or domain name, you are using a new connection profile because servers do not have a unique identifier. At the time, users were defined by username and could have name collisions across servers (such as "root" or "admin", or if you and your friend each have a server and used the same username). Users are now defined by the UUID in the SQLite database. More information in https://github.com/advplyr/audiobookshelf-app/issues/1401 As to why it matters, the app supports multiple users and connecting to multiple different servers.
Author
Owner

@brent-holland commented on GitHub (Jul 14, 2025):

If that's the case, one should be able to edit the connection profile associated with a local book via the app. You could have an 'edit server / user' and let them pick an entry from the 'switch server/user' page.

Just today I set up a new router, and I've been sufficiently annoyed by this issue that I explicitly gave my laptop the same IP as is normally provisioned on my parents network (starlink, I have no control over this). It's very annoying to lose progress on a book and basically have to redownload it to fix syncing...

@brent-holland commented on GitHub (Jul 14, 2025): If that's the case, one should be able to edit the connection profile associated with a local book via the app. You could have an 'edit server / user' and let them pick an entry from the 'switch server/user' page. Just today I set up a new router, and I've been sufficiently annoyed by this issue that I explicitly gave my laptop the same IP as is normally provisioned on my parents network (starlink, I have no control over this). It's very annoying to lose progress on a book and basically have to redownload it to fix syncing...
Author
Owner

@TheTerrasque commented on GitHub (Jul 14, 2025):

As to why it matters, the app supports multiple users and connecting to multiple different servers.

That doesn't explain why this is a problem. The server holds the state, why would locally cached state from a different connection profile even be relevant?

Just today I set up a new router, and I've been sufficiently annoyed by this issue that I explicitly gave my laptop the same IP as is normally provisioned on my parents network (starlink, I have no control over this). It's very annoying to lose progress on a book and basically have to redownload it to fix syncing...

I ended up uninstalling and reinstalling the app to nuke the local metadata cache and make it fetch all from the server again. Tedious, but since the app is so confused, I figured that was the easiest fix. Server has progress data anyway, so nothing really lost.

@TheTerrasque commented on GitHub (Jul 14, 2025): > As to why it matters, the app supports multiple users and connecting to multiple different servers. That doesn't explain *why* this is a problem. The server holds the state, why would locally cached state from a different connection profile even be relevant? > Just today I set up a new router, and I've been sufficiently annoyed by this issue that I explicitly gave my laptop the same IP as is normally provisioned on my parents network (starlink, I have no control over this). It's very annoying to lose progress on a book and basically have to redownload it to fix syncing... I ended up uninstalling and reinstalling the app to nuke the local metadata cache and make it fetch all from the server again. Tedious, but since the app is so confused, I figured that was the easiest fix. Server has progress data anyway, so nothing really lost.
Author
Owner

@iconoclasthero commented on GitHub (Oct 14, 2025):

I just got hit by this issue too. I don't understand, how is this even a problem? Server lists library, says book X is at progress Y, you open that book on app and moves to that progress, then report progress as it's played / read. Where does it even come in that you also read the same book on a different server before? Why does that matter at all?

Servers are defined by their connection profile, which is the user and address used to connect to the server. If you connect to the server using a different IP or domain name, you are using a new connection profile because servers do not have a unique identifier. At the time, users were defined by username and could have name collisions across servers (such as "root" or "admin", or if you and your friend each have a server and used the same username). Users are now defined by the UUID in the SQLite database. More information in #1401

As to why it matters, the app supports multiple users and connecting to multiple different servers.

Isn't there a unique UUID (Library Item ID?) associated with the downloaded book ("UUIDs should be cryptographically random with collisions so improbable they’re effectively impossible within the lifespan of the universe for one instance of ABS") that would have a vanishingly small chance of colliding across even 4 separate ABS server instances (I don't have access to any libraries but my own, but just e.g.)?

Books per Instance Total UUIDs Approx. Collision Probability
10,000 40,000 1.7×10⁻³¹
100,000 400,000 1.7×10⁻²⁹
1,000,000 4,000,000 1.7×10⁻²⁷
10,000,000 40,000,000 1.7×10⁻²⁵

The OP's suggestion of a button to claim (move) the media for (to) a different server provided the UUIDs match seems like a reasonable way to verify that they're the same item by both UUID and the fact that the user wants to actually move them over. If the UUIDs don't match then it could error out or perform additional validation.

Digression:
I'm not sure how many people "if you and your friend each have a server and used the same username" applies to. I suspect that the number of people with access to > 1 server is << 1%. But in that case, the UUIDs shouldn't match and that could be the end of the story unless someone wanted to go to greater lengths to write code to match up on Title/Author. In which case, I would personally want the user profile of both servers to reflect the progress on that particular book...

@iconoclasthero commented on GitHub (Oct 14, 2025): > > I just got hit by this issue too. I don't understand, how is this even a problem? Server lists library, says book X is at progress Y, you open that book on app and moves to that progress, then report progress as it's played / read. Where does it even come in that you also read the same book on a different server before? Why does that matter at all? > > Servers are defined by their connection profile, which is the user and address used to connect to the server. If you connect to the server using a different IP or domain name, you are using a new connection profile because servers do not have a unique identifier. At the time, users were defined by username and could have name collisions across servers (such as "root" or "admin", or if you and your friend each have a server and used the same username). Users are now defined by the UUID in the SQLite database. More information in [#1401](https://github.com/advplyr/audiobookshelf-app/issues/1401) > > As to why it matters, the app supports multiple users and connecting to multiple different servers. Isn't there a unique UUID (Library Item ID?) associated with the downloaded book ("UUIDs should be cryptographically random with collisions so improbable they’re effectively impossible within the lifespan of the universe for one instance of ABS") that would have a vanishingly small chance of colliding across even 4 separate ABS server instances (I don't have access to any libraries but my own, but just e.g.)? | Books per Instance | Total UUIDs | Approx. Collision Probability | |--------------------:|------------:|------------------------------:| | 10,000 | 40,000 | 1.7×10⁻³¹ | | 100,000 | 400,000 | 1.7×10⁻²⁹ | | 1,000,000 | 4,000,000 | 1.7×10⁻²⁷ | | 10,000,000 | 40,000,000 | 1.7×10⁻²⁵ | The OP's suggestion of a button to claim (move) the media for (to) a different server provided the UUIDs match seems like a reasonable way to verify that they're the same item by both UUID and the fact that the user wants to actually move them over. If the UUIDs don't match then it could error out or perform additional validation. Digression: I'm not sure how many people "if you and your friend each have a server and used the same username" applies to. I suspect that the number of people with access to > 1 server is << 1%. But in that case, the UUIDs shouldn't match and that could be the end of the story unless someone wanted to go to greater lengths to write code to match up on Title/Author. In which case, I would personally want the user profile of both servers to reflect the progress on that particular book...
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/audiobookshelf-app#1086