mirror of
https://github.com/Radarr/Radarr.git
synced 2026-03-02 22:57:34 -05:00
500 Internal server error when getting Manual import popup #8957
Labels
No labels
Area: API
Area: Database
Area: Db-migration
Area: Download Clients
Area: Extras
Area: Import Lists
Area: Indexer
Area: Metadata API
Area: Notifications
Area: Organizer
Area: Parser
Area: Scanning
Area: Tooling
Area: UI
Area: Unit Tests
On Hold: MetadataAPI Blocking
On Hold: MetadataAPI Blocking
Priority: High
Priority: Low
Priority: Medium
Status: Accepted
Status: Cannot Reproduce
Status: Confirmed
Status: Help Wanted
Status: In Progress
Status: Indexer - need invite
Status: Info Needed
Status: Investigating
Status: Logs Needed
Status: Maybe One Day
Status: Needs Triage
Status: On Hold
Status: Ready for Review
Status: Unlikely
Status: Waiting for OP
Status: Won't Fix
Type: Bug
Type: Documentation
Type: Duplicate
Type: Enhancement
Type: External Bug
Type: Feature Request
Type: Regression
Type: Support
Type: Support.
conflict
lidarr-pull
no-conflict
not-pulled
readarr-pull
readarr-pull
sonarr upstream
sonarr-pull
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/Radarr#8957
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
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 @simonc56 on GitHub (Dec 8, 2024).
Is there an existing issue for this?
Current Behavior
Since version
5.15.1.9463I can't manually import movies from Activity > Queue anymore.Server returns error 500 response.
Frontend displays to user : 'Could not find file 'path/to/file.mkv'.
Import button is disabled.
ℹ️ Downgrading to
5.14.0.9383fixes the issue.My opinion is there is a mess with filepaths in last update.
I think radarr tries to find the file in a wrong path.
Expected Behavior
In version
5.14.0.9383and before, the server returns response 200 with movie data (path, relativePAth, folderName, name, size,...).The popup shows the file to be imported with corresponding values Movie, Release Group, Quality, Language, Size populated.
I can click the import button.
Steps To Reproduce
Downgrading to 5.14 fixes the issue :

Environment
What branch are you running?
Master
Trace Logs? Not Optional
Trace Logs have been provided as applicable. Reports will be closed if the required logs are not provided.
trace- that are relevant and show this issue.@mynameisbogdan commented on GitHub (Dec 8, 2024):
Looks like
/media/downloads/importis a symlink to/media/tera/downloads/films.Should be fixed with
3449a5d3fe.@mynameisbogdan commented on GitHub (Dec 8, 2024):
Even if it's not fixed by that commit, maybe revise your symlinks and if that fails then come back and provide some info about your setup here because you didn't disclosed anything about it because it's possible to be a bug.
Currently I'm inclined to say it's some permission issues mixed with symlinks.
@simonc56 commented on GitHub (Dec 9, 2024):
Thank you for your help.
The commit
github.com/Radarr/Radarr@3449a5d3fedid not fixed it.How I fixed it
Radarr was reading an absolute symlink with fullpath (from host point of view). But the volume mounted in radarr container is not "aware" of this fullpath.
So I changed my workflow so that the symlink (created by rtorrent script) is now a relative path.
Now, radarr can read it. Every chunk of the path is readable from the container point of view.
Why this bug appeared
Before version 5.15.1.9463, radarr didn't try to follow symlink.
But now it follows symlink so they must be valid.
Update is this commit :
@mynameisbogdan commented on GitHub (Dec 14, 2024):
I would not consider this a bug, but actually bringing to the user attention that there's an issue. As you can see in 5.14.0 and earlier you would get the size of the symlink (159 B in your example) and Radarr would improperly import the file with bad media info and would never update it if the absolute path was never actually available.
This might be an inconvenience at first, but I think fixing a bad setup is more beneficial in the long run.