When a file is manually replaced, for example after converting from an mp4 to an mkv; radarr decides to delete everything in that movies folder: posters, backdrops, subtitles, NFO files, leaving only the new video file; even though none of these were created or managed by Radarr ever.
This causes Emby to have to rescan/reidentify the item, re-downloading all the extra data, and it’s now lost all custom metadata that was stored in the nfo, particularly the original date added to emby and it now has no subtitles.
How can I prevent this?
Ah, okay. Yes, I got the same results as you, even if you do it the opposite way, add a movie through Radarr, and it will replace the other movie and wipe the other data.
Through my testing, it does seem to only wipe it if Radarr thinks there’s a movie there already. I don’t think this solves your problem, but if you empty the movie folder, scan and refresh radarr, then add the data back, it gets picked up. It only wipes the data when it is replacing it, which is probably intentional because different files might have different metadata? I’m not sure.
It might be possible with a custom script.
Before that, take a look at the “Import Extra Files” option under Settings -> Media Management.
Thing is this is all automated processes, so manually scanning files between changes isn’t really a fix.
Looks like I’ll be setting up a script to move all the deleted files out of radarrs recycling folder and back into the media folders on a regular basis.
This is stupid. Radarr didn’t create the files, nor import them; yet it takes it upon itself to delete a bunch of data created/provided by other systems, because it can’t find a file it did actually manage. I was hoping for a setting I’d somehow missed.
Also; yeah, extra files are enabled, but that only effects newly imported media from a download client; not files discovered/removed from the media folders. (I’ve tested with it off too, no change)
Before you spend too much time on that, you can create an issue on the Github page. Seems fairly active. Might get a better response there.