Radarr icon indicating copy to clipboard operation
Radarr copied to clipboard

Radarr V3: Losing all subtitles when format of the imported file changes through post processing script

Open dramirvf opened this issue 5 years ago • 8 comments

Radarr V3: :3.0.0.3785

I use SMA script to post process movies during import (Audio conversion / Metadata Tagging / Format Conversion). If the input and output format of the processed video file is the same, there is not any issues at all.

The issue is present only if the FORMAT of imported video is changed. I have set to keep all my movies in MP4 format. So the script converts MKV files to MP4. Unfortunately after the import is complete, I end up losing all the subtitles which had been along with the MKV file (Skipping format change, keeps them all with no issues).

It looks like Radarr detects a filename change (since the format is changed) and therefore removes the relevant subtitles because thinks they are no more valid.

I think there should be a flag on the API where Radarr gets notified through the script that the extras are still valid after format change and don't remove them.

AB#802

dramirvf avatar Oct 13 '20 22:10 dramirvf

I'm not sure how this is relevant to radarr? If you have post processing changing files, that post processing needs to handle it. Simple really, if the script detects a change is needed then delete the movie (keep files), make your changes, readd the movie and point it to the directory with the changed files.

austinwbest avatar Oct 13 '20 23:10 austinwbest

I've done just that in my script but it doesn't change the shortcoming.

It is most definitely relevant to Radarr and Sonarr. The post script isn't touching or modifying the extra files at all but because it does modify the video file a rescan is needed to keep the Radarr database up to date, and this causes Radarr to delete the extra files. I could simply not trigger a rescan in the post script, which may seem fine but then next time the end user does a rescan for any reason Radarr again deletes all the extras when it detects the video file modification.

The workaround I've implemented is to make backups of the extras, do a rescan, let Radarr delete the extras, and then restore the backups and issue another rescan so the extras are back in the database. This method while effective seems inefficient as it requires making copies of files and additional API calls

A way to issue a rescan from the API but let Radarr know the extras don't need to be wiped would be nice

mdhiggins avatar Oct 14 '20 01:10 mdhiggins

It's by design, if a file is found to be removed its associated files go too.

That is core logic that is unlikely to change & if it does it would likely be to preserve images & meta only (believe what it currently does)

Deleting the movie in radarr and re-adding it would not remove any files because it is considered new and not a change. It wouldn't have a change history to know the container went from mkv to anything else 🤔

austinwbest avatar Oct 14 '20 02:10 austinwbest

I understand the reason/design behind it, you wouldn't want subtitles that don't match up with a new media file and as a default behavior it definitely makes sense but for any post processing script that might change the media file those extras likely are still valid and you run the risk of deleting good data.

I think in situations where you know the extra files are still valid having a parameter in the rescan api command to associate them with the new file instead of wiping them would be a nice feature and would avoid workarounds.

The above example that's causing issue is because the post processing script re-wraps the file in an mp4 container from mkv and then triggers a RescanMovie command. At that time the original mkv has been deleted and an mp4 of the same name is left in its place and that is enough for Radarr to remove the extras. Similarly if the RescanMovie command is not run and the user manually presses the 'Update movie info and scan disk" button then all their subtitles get deleted. They might be initiating that to update some metadata on a file that's existed for some time and suddenly all their subtitles are gone which doesn't seem ideal.

Not sure if deleting and re-adding is the best option, you lose all the history and release information with that approach

mdhiggins avatar Oct 14 '20 05:10 mdhiggins

Fair point about those who want to keep the history

Unfortunately i dont think there will be the outcome you want. A trigger field like that could lead to people not using it right and then leaving files that shouldn't be.. Then opening bug tickets about that too. I would try to pitch that idea to Sonarr and see if you can get them to agree. Some things we try to keep pretty tight with upstream for the sake of pulling/merging & being consistent across the *arr apps

Rename & move extras to a _tmp, rescan, bring back extras and remove _tmp (think that is along the lines of what you said you where doing) would be the solution to keep history it seems

austinwbest avatar Oct 14 '20 12:10 austinwbest

@bakerboy448

Update: Radarr Version 3.0.0.4216:

Earlier, the author of SMA (Sickbeard_mp4_automator) (@mdhiggins ) had included some codes in the post-process script to backup external subtitles when container is being changed from MKV to MP4. It was working very good to keep external subtitles in a safe place to avoid from deletion by Radarr. But after the recent updates in Radarr, again all external subtitles are being deleted at the point of final refresh on the folder which is triggered by Radarr after manual import is complete.

dramirvf avatar Dec 01 '20 05:12 dramirvf

This issue has been automatically marked as stale because it has not had recent activity. Please verify that this is still an issue with the latest version of Radarr and report back. Otherwise this issue will be closed.

stale[bot] avatar Jan 08 '22 23:01 stale[bot]

For me this issue happens also if there is an mkv file being replaced by another mkv file. Not (only) when a container change is happening.

But as this is still an open issue I'm assuming this is being worked on (albeit probably low on the priority list)?

Piddox avatar Jun 18 '24 10:06 Piddox