mirror of
https://github.com/Radarr/Radarr.git
synced 2026-03-02 22:57:34 -05:00
Different Behavior Between Manual Import and Regular Import when {Original Title} or {Original Filename} are in Naming Scheme #9232
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#9232
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 @SF4L on GitHub (Jul 23, 2025).
Is there an existing issue for this?
Current Behavior
With the Naming Scheme:
{Movie Title} ({Release Year}) - [{Original Title}]or{Movie Title} ({Release Year}) - [{Original Filename}]Automatic Import works as expected:
Pulp Fiction (1994) - [Pulp.Fiction.1994.1080p.BluRay.DTS.x264-DON].mkvManual Import:
Pulp Fiction (1994) - [].mkvExpected Behavior
I would really love it if it was possible to keep the original filename in the resulting filename when using Manual Import.
So my output when clicking the orange dude would also be:
Pulp Fiction (1994) - [Pulp.Fiction.1994.1080p.BluRay.DTS.x264-DON].mkvNote: this is the current behavior of Sonarr, at least in version 4.0.14.2939.
Steps To Reproduce
{Movie Title} ({Release Year}) - [{Original Title}]or{Movie Title} ({Release Year}) - [{Original Filename}]Environment
What branch are you running?
Master
Trace Logs? Not Optional
radarr.trace.5.txt
radarr.trace.9.txt
From Manual Import:
radarr.trace.5.txt:2025-07-23 23:06:21.9|Debug|QualityParser|Trying to parse quality for 'Demolishing.and.Building.Up.The.Star.Theatre.1901.DVDRip-TAFA.x264-HANDJOB.mkv' radarr.trace.5.txt:2025-07-23 23:06:22.0|Debug|OtherExtraFileService|Deleting Extra from database for movie file: [36604] Demolishing and Building Up the Star Theatre (1901) - [Demolishing.and.Building.Up.The.Star.Theatre.1901.DVDRip-TAFA.x264-HANDJOB].mkv radarr.trace.5.txt:2025-07-23 23:06:22.0|Debug|MovieFileMovingService|Attempting to hardlink movie file: /media/downloads/torrents-server/share/Demolishing.and.Building.Up.The.Star.Theatre.1901.DVDRip-TAFA.x264-HANDJOB.mkv to /media/Movies/Demolishing and Building Up the Star Theatre (1901) {tmdb-129863}/Demolishing and Building Up the Star Theatre (1901) - [].mkv radarr.trace.5.txt:2025-07-23 23:06:22.0|Debug|SubtitleFileService|Deleting Extra from database for movie file: [36604] Demolishing and Building Up the Star Theatre (1901) - [Demolishing.and.Building.Up.The.Star.Theatre.1901.DVDRip-TAFA.x264-HANDJOB].mkv radarr.trace.5.txt:2025-07-23 23:06:22.0|Debug|DiskTransferService|HardLinkOrCopy [/media/downloads/torrents-server/share/Demolishing.and.Building.Up.The.Star.Theatre.1901.DVDRip-TAFA.x264-HANDJOB.mkv] > [/media/Movies/Demolishing and Building Up the Star Theatre (1901) {tmdb-129863}/Demolishing and Building Up the Star Theatre (1901) - [].mkv]From automatic import:
radarr.trace.9.txt:2025-07-23 23:04:17.1|Trace|ConfigService|Using default config value for 'copyusinghardlinks' defaultValue:'True' radarr.trace.9.txt:2025-07-23 23:04:17.1|Debug|MovieFileMovingService|Attempting to hardlink movie file: /media/downloads/torrents-server/radarr/Demolishing.and.Building.Up.The.Star.Theatre.1901.DVDRip-TAFA.x264-HANDJOB.mkv to /media/Movies/Demolishing and Building Up the Star Theatre (1901) {tmdb-129863}/Demolishing and Building Up the Star Theatre (1901) - [Demolishing.and.Building.Up.The.Star.Theatre.1901.DVDRip-TAFA.x264-HANDJOB].mkv radarr.trace.9.txt:2025-07-23 23:04:17.1|Debug|DiskTransferService|HardLinkOrCopy [/media/downloads/torrents-server/radarr/Demolishing.and.Building.Up.The.Star.Theatre.1901.DVDRip-TAFA.x264-HANDJOB.mkv] > [/media/Movies/Demolishing and Building Up the Star Theatre (1901) {tmdb-129863}/Demolishing and Building Up the Star Theatre (1901) - [Demolishing.and.Building.Up.The.Star.Theatre.1901.DVDRip-TAFA.x264-HANDJOB].mkv]Summary
In summation:
*Working:
Naming Scheme:
{Original Title}:Not working:
Naming scheme:
{Movie Title} ({Release Year}) - [{Original Title}]Why I think it's important - matching for Plex/Jellyfin. Maybe not relevant, but still probably worth sharing:
The most common case for errors is when the year in the filename/original title is a little bit off. So you get Love (2016) {imdb-tt4190832}/Love.2015.720p.MUBI.WEB-DL.AAC2.0.x264.mkv.
Plex Agent matches it with a way more popular movie (Gaspar Noe's Love from 2015), even though Radarr's manual import correctly moved it to the folder with the right IMDB ID - corresponding to the arthouse short called Love from 2016, not Gaspar Noe's 2015 film.
But if I have it named Love (2016) {imdb-tt4190832}/Love (2016) - [Love.2015.720p.MUBI.WEB-DL.AAC2.0.x264].mkv, it will match with the arthouse short as intended, because it ignores the 2015 in the filename since it's in square brackets.
The IMDB in curly brackets helps, A LOT, but when there's conflicts/contradictions between ID and filename, sometimes the filename wins in the Plex scanner agent. Idk why. But I promise it happens, I'm not making this up
And why naming schemes don't work perfectly:
Take this release, for example:
Feast.III.-.The.Happy.Finish.2009.1080p.BluRay.NSM.Unrated.Plus.Comm.DDP.5.1.x264-MaGThere's no catch-all way to preserve theNSM Unrated Plus Commhere with Edition Information or anything else, but I personally feel it's quite important to capture. Often there are dozens of different BluRay sources available, good filenames/release names indicate the exact source (which is otherwise lost in Radarr, since when it's gone from the filename, it's not in the metadata).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.@bakerboy448 commented on GitHub (Jul 23, 2025):
@bakerboy448 commented on GitHub (Jul 23, 2025):
To clarify from your discord convo.
This bug itself closed as the usecase isn't supported, but the referenced bug would cover the database not containing the relevant data on manual import - which would likely resolve this issue if it was a supported use case
@SF4L commented on GitHub (Jul 24, 2025):
Hm, I personally think the bug report is moreso that "manual and automatic import hardlink/move behave differently on the same file" which I think is a bit different than the original issue that was reported.
There was no warning anywhere in Radarr when I made this naming scheme (which I have been using for ~10 years, and it was working flawlessly for ~7 of them), and there isn't for me today:
Can I clarify why there is no interest in supporting this use-case? It doesn't seem particularly troublesome (it's implemented in Sonarr), and it's a bit odd that there's currently no way to accomplish both of the following when manually importing (I reiterate: it works just fine when everything goes smoothly with automatic import):
I understand TRaSH guides' scheme gives you more than just the original filename (in most cases), but if Title/Filename are allowed all (and I don't understand why they wouldn't be, some people might care about preserving the only thing that can't be retroactively retrieved from the MediaInfo) - then why would Manual and Automatic Imports treat them differently?
Here is just one examples where I'm grateful to have the original filename:
Feast.III.-.The.Happy.Finish.2009.1080p.BluRay.NSM.Unrated.Plus.Comm.DDP.5.1.x264-MaG.mkvThis mentions the specific BluRay the release was encoded from, which is super valuable as there's a ton of different releases out there. I don't believe TRaSH's Naming Scheme accounts for that - unless you do a custom Edition Tag, which means you need different ones for each possible edition (please correct me if I'm wrong here).
There are a lot of times where the filename can be useful, for a lot of people. It would be really awesome if Manual Import didn't break it.
And the reason I want to combine it with Movie (Year) is two-fold.
The Plex Agent does use the filename in its logic somewhere, even if you give it the IMDB hint. If your filename conflicts with another movie (for example, there are multiple movies made with the same title in the same year, or it's just a really weirdly named file for whatever reason) it will break. I did some pretty extensive testing on this in the past.
With
Movie (Year) {imdb-1234}/Movie (Year) - [Filename, and whatever other crap you want to have in square brackets].mkvthe Plex Agent never breaks, unless the film itself doesn't have Metadata on watch.plex.tv, in which case no folder/file name is gonna save you. I fully believe this format should be supported.@bakerboy448 commented on GitHub (Jul 24, 2025):
Already answered with Manual Import not populating the correct fields. it has nothing to do with original title or original filename
Plex is not recommending that naming - only the bare minimum needed for it to work.
it's also implemented in radarr; doesn't mean it shouldn't exist.
@SF4L commented on GitHub (Jul 24, 2025):
Do you mind expanding on this a little bit? What fields is Manual Import not correctly populating?
If that's the case, then it's not recommending TRaSH's Naming Scheme either. Plex explicitly states that it ignores everything in square brackets. What's the argument here? The point is, it's explicitly not recommending Movie (Year)/Filename.mkv, which is apparently the only way to currently get Filename in the rename using Manual Import. And I know with 100% certainty that
Movie (Year)/Filename.mkvorMovie (Year) {imdb-1234}/Filename.mkvdoesn't match successfully as often asMovie (Year) {imdb-1234}/Movie (Year) - [Filename].mkvI'm having a little bit of trouble parsing this. What is implemented in Radarr? What shouldn't exist?
When you automatically or manually import a file with the analogous naming scheme (
{Series CleanTitle} - S{season:00}E{episode:00} - {Episode CleanTitle} - [{Original Filename}]) in Sonarr, you can get 'Show Name - S01E01 - Episode Title - [Filename].mkv' - exactly what you'd expect. When you manually import in Radarr, you getMovie (Year) - [].mkv. When it automatically imports in Radarr, you getMovie (Year) - [Filename].mkv.@bakerboy448 commented on GitHub (Jul 24, 2025):
see the issue this is a duplicate of as previously mentioned several times.
Plex is off topic for Radarr.
Original FileName / OriginalTitle AND other attributes
Again the issue is related to a bug with manual import as already duplicated...it is acknowledged as a bug.
there's no further discussion needed on this and your combative behavior and off topic comments is unecessary.
@SF4L commented on GitHub (Jul 24, 2025):
I've read it several times. I'm probably being dumb, but I'm not seeing what I'm supposed to be seeing.
That topic is talking about manually renaming content outside of Radarr, which is a bad idea, and I know it's a bad idea.
I see one comment here related to manual import: https://github.com/Radarr/Radarr/issues/6547#issuecomment-896301723:
Manual Import not noting an original file path -- if that is the case -- could be a bug, but that's not what the GHI discusses.No further discussion or mention of this, just references to other issues that dupe it. That issue has been marked stale several times. I thought filing out a bug report with specific examples and more details as to the actual issue at hand (manual + automatic import behaves differently) may be useful. My apologies for wasting your time if it's not.But while we're both here...
Sorry, was this an answer to the question about "What is implemented in Radarr?" or "What shouldn't exist?" If the latter, I'm curious why you think it shouldn't exist. It can be really useful, for the reasons I've tried to outline in this post.
It just doesn't seem like the issue is fully understood :/ I'm just trying to make sure the issue is clear. If it is, then that's fine - I'm not convinced based on the content of the issue that's been duplicated, and the discussion (or lack thereof) there. I don't see any mention of different behavior for automatic and manual import there, for example.
What combative behavior? I'm genuinely not trying to offend anybody, just trying to explain the issue and why it may be important to some people. I don't think I've said anything rude or offensive, my bad if my comments are being construed as such.
That's...fair, I suppose.
(perhaps we should adjust the wording of "Full integration with Kodi and Plex (notifications, library updates)" from the major list of features on GitHub if that's the case?) Is that constructive? I feel like we all know why the vast majority of people use the *arr stack...
@bakerboy448 commented on GitHub (Jul 24, 2025):
it's open and thus still a bug. Stale bot's comments should all be marked offtopic and are legacy / ignore them
Manual Import is not populating the original file information thus OriginalTitle and OriginalFileName are blank. This is the duplicate and what has been explain.
THERE IS NOTHING TO DISCUSS. THE BUG IS A DUPE.
@SF4L commented on GitHub (Jul 24, 2025):
Got it. Thank you.
@bakerboy448 commented on GitHub (Jul 25, 2025):
Tracing the code Builder drops original filename to nothing if there's multiple tokens as designed. Original title would work if and only if it's a scenetitle. If the filename is not a scenetitle then original title fallback to getting the original file name which is blank as multiple tokens are being used
@SF4L commented on GitHub (Jul 25, 2025):
I would still love to hear the logic behind this design (IMO it is suboptimal), but I'm happy to move on.
That makes perfect sense as to why it's happening, thanks for the clarification. I'll just drop the best summary I can here, for visual aid. In summation:
*Working:
Naming Scheme:
{Original Title}:Not working:
Naming scheme:
{Movie Title} ({Release Year}) - [{Original Title}]Why I think it's important - matching for Plex/Jellyfin. Maybe not relevant, but still probably worth sharing:
The most common case for errors is when the year in the filename/original title is a little bit off. So you get Love (2016) {imdb-tt4190832}/Love.2015.720p.MUBI.WEB-DL.AAC2.0.x264.mkv.
Plex Agent matches it with a way more popular movie (Gaspar Noe's Love from 2015), even though Radarr's manual import correctly moved it to the folder with the right IMDB ID - corresponding to the arthouse short called Love from 2016, not Gaspar Noe's 2015 film.
But if I have it named Love (2016) {imdb-tt4190832}/Love (2016) - [Love.2015.720p.MUBI.WEB-DL.AAC2.0.x264].mkv, it will match with the arthouse short as intended, because it ignores the 2015 in the filename since it's in square brackets.
The IMDB in curly brackets helps, A LOT, but when there's conflicts/contradictions between ID and filename, sometimes the filename wins in the Plex scanner agent. Idk why. But I promise it happens, I'm not making this up
And why naming schemes don't work perfectly:
Take this release, for example:
Feast.III.-.The.Happy.Finish.2009.1080p.BluRay.NSM.Unrated.Plus.Comm.DDP.5.1.x264-MaGThere's no catch-all way to preserve theNSM Unrated Plus Commhere with Edition Information or anything else, but I personally feel it's quite important to capture. Often there are dozens of different BluRay sources available, good filenames/release names indicate the exact source (which is otherwise lost in Radarr, since when it's gone from the filename, it's not in the metadata).