Fix API including basepath in tracks contentUrl #3921
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Brief summary
API endpoints that return expanded Books and PodcastEpisodes include AudioTrack objects that have a
contentUrl
. ThatcontentUrl
was incorrectly including the basepath (/audiobookshelf). This PR removes the basepath from the API responses and prepends the basepath in the web client.Which issue is fixed?
No issue
In-depth Description
The mobile clients and 3rd party clients will be getting users server address and prepending it to the
contentUrl
returned from the API.If the
contentUrl
includes the basepath and the user includes the basepath in the address then it will result in track urls with/audiobookshelf/audiobookshelf/
.The mobile apps are currently falling back to transcoding if the user includes the basepath. This PR fixes that issue with no additional changes on the mobile apps.
How have you tested this?
Tested streaming on web client and mobile apps w/ subdir.