Some metadata lost during re-scan

Some information about the downloaded file may be lost during the rescan following conversion. The exact info that is lost is dependent upon the specific video that is downloaded combined with your Media Management naming configuration, including formats for Standard Movie Format (Radarr) or Standard Episode Format (Sonarr). In some cases nothing is lost. In advanced configurations, the loss of this information could even induce looping, where Radarr/Sonarr continuously re-downloads the same file.

If the conditions are right, the following information might be lost:

~~Release Group~~ (Fixed beginning with #55)
~~Custom Formats~~ (See Final Note below)
~~Custom Format Score~~ (See Final Note below)

I'm having a hard time figuring out how to manually put this data back, even via API.

This bug has existed for a long time, but the good news is that beginning with Release 2.4 #51 the chances of this are greatly reduced due to the quick drop out added with the resolution of issue #49 .

Workarounds

One workaround is to add the metadata into your file naming format. During rescan Radarr/Sonarr should then pick it back up.

Radarr

For example, if you are using custom formats that are based upon audio and video media info, you could use:

{Movie Title} ({Release Year}).{MediaInfo AudioCodec}.{MediaInfo VideoDynamicRangeType}.{Release Group}

as your Radarr Standard Movie Format.

Alternatively, and to catch everything, you could add the {Custom Formats} token to your renaming format as long as you've checked the Include Custom Format when Renaming checkbox in each custom format.

Sonarr

In Sonarr's Standard Episode Format you could add the {Preferred Words} token as long as you've check the Include Preferred when Renaming checkbox in each release profile.

Final Note

I have discovered with my work on Release 2.5 (#67) that I was fundamentally misunderstanding Custom Formats. They cannot be set directly by the user on a given video file. They are detected (aka assigned) by Radarr/Sonarr based on the rules in the format. Think of them as automatically applied labels.

The important thing for me is that they are updated only at certain points in a video's lifecycle, and can change at different times even if the video itself doesn't change. This mostly seems to be based on the name of the video changing due to the naming rules you have configured.

Example

Let's say you are monitoring the movie Trolls Band Together (2023).

Based on your Custom Formats and scoring in your quality profile, the file Trolls.Band.Together.2023.2160p.WEB-DL.DDP5.1.Atmos.DV.HDR.H.265-FLUX.mkv is selected for download. This might have applied and formats because you used TRaSH Guides tutorials.

The file is downloaded, but because of the way you configured Radarr's file naming rules, it is renamed to Trolls Band Together (2023).mkv. The two formats may disappear at this point because you've lost the DDP5.1.Atmos text and the DV.HDR text from the filename. However, sometimes they are preserved. (I don't fully understand the rules around this).

This will happen if you use my script because it flat out deletes the original file along with the database entry that contained all the metadata that the format evaluation logic uses. That leaves only the file name of the newly remuxed file to work from, and if you don't have those key bits in the filename, the formats are gone.

...along with the format scores. This is critical, because the scores are used by Radarr/Sonarr to determine when to upgrade an existing file. If a +100 is attached to the format and that format disappears, you've lost points and Radarr could search for and find the exact same file again and re-download it, starting the whole process over again, looping forever. 😢

What to do about this

The good news is that this seems to have improved with the latest versions of Radarr and Sonarr. I think (without direct evidence) that they are now scanning the video on import and using the embedded metadata to assign custom formats, not just the file name.

If I'm wrong, the Workaround above is still valid, and unfortunately, about the only thing that can be done to solve this.

TheCaptain989 / radarr-striptracks