Sonarr deleting files after H265 encode

Help & Support
#1

Sonarr version (exact version): 3.0.6.1342
Mono version (if Sonarr is not running on Windows): 6.12.0
OS: unraid
Debug logs: not enabled at the time
Description of issue: Sonarr deletes any file that is transcoded to h265. While trying to find a solution to this I keep seeing over and over that “sonarr doesn’t delete files”… so I’m hoping that that will not be the response to this as it clearly does in this case. When I transcode a file AFTER sonarr has moved it from the completed downloads to the appropriate season folder, sonarr deletes it. The history on every single file says

Name
/media/Mainstream/Chucky/Season 01/Chucky - S01E01 - Death by Misadventure.mkv
Reason
Sonarr was unable to find the file on disk so it was removed

Is there a way to stop this or do I need to transcode before the import? Or am I just completely missing the point?

Edit I’m going to try and clarify exactly what is happening in the process

  1. Sonarr sends the download request to deluge
  2. Deluge downloads the file
  3. Sonarr grabs the completed download and moves it to the correct series/season folder
  4. Tdarr monitors that folder and transcodes anything NOT already in H265 to H265
  5. Sonarr then gives me that history log of not being able to find the file
  6. “Sonarr doesn’t delete or move the file” but somehow EVERY SINGLE FILE ends up in the location designated for sonarr_recycle.

If sonarr is not moving that file there, how do they all go to the ONLY location that sonarr uses to remove files?

sonarr_recycle
sonarr_recycle1117×627 34.3 KB
– all the files it moved there yesterday that were converted to H265

#2

the only circumstances in which sonarr deletes a file is when;
a) its being replaced by sonarr. ie a better quality was downloaded so the original is deleted and the new version is copied over.
b) you clicked on delete (episode, season, or series) - but this also has a confirmation.

removed from the database as being there, not from the drive - its sort of implied in the error message that sonarr cant even find the file so how would it delete it?

its always done this as well. if you manually delete all the files (from outside of sonarr) then the next time sonarr re-scans the drive it will see that they are missing and add an entry that they were deleted (no longer exists).

when you recode them do you keep the name the same as the original file and just replace it, or do you delete the original and just put the new file (with a new name) in the same folder?

the “correct” process would be to convert them in another folder, one outside of the root/series/season, then tell sonarr to import them from there - which would then delete the originals, and import the new file.

i used to do what youre doing and sonarr never deleted the original, i always had to do that myself. i now do it the “correct” way and the import process cleans up for me.

re-scans are every 12 hours i think so it shouldnt be difficult to put a new 265 file in there (the way you have been doing it) and enable debug to collect good debug logs to try and find out whats actually going on.

you should also investigate any other processes you have because its highly unlikely that sonarr is deleting them. im not going to say its impossible, but you need to look for alternative reasons and not just hope its something weird in sonarr.

i mean surely you have downloaded x265 formatted files, not just had to convert everything, so shouldnt sonarr have deleted those by now if it had some weird bug in regards to x265 files?

edit 1: btw. sonarr has a trash bin so perhaps enable that and point it somewhere outside your root media, and download, paths - and see if your x265 files end up in there?

edit 2: do you know how long after you put the x265 files into the folder that they end up deleted? hours, days?

edit 3: also, where do your downloads get saved to? sonarr will complain about importing from a root folder so i doubt this is the case but if you do download to the same location as the files are stored then its highly likely that the download clients cleanup process is whats deleting your files over time.

#3

Sonarr is not deleting the file

You’re modifying the file under Sonarr’s nose and thus on the twice daily rescan it no longer sees the file and notes it’s missing / removes from DB.

Either don’t modify the name or adjust your process to call sonarr to refresh twice or manually import it.

You don’t need to transcode in a different folder

#4

no you dont, but the import button on the series page does not trigger an import event, the import button on the wanted page does, so its simpler to tell people to put it into a different folder, outside of the root path, that way their manual import follows the same “path” as a download/import would.

unless someone has decided that was worth changing and “fixed” it?

#5

Manual import from the series page displays all unmapped video files in the series folder.

Once imported - not sure if it’s an official import event or not, would need to see.

Perhaps you’re thinking of v2 behavior and not v3?

#6

nope. raised a v3 ticket for it a while back and was explained that they are different for a reason - and from the little i remember it made sense, just wasnt what i was expecting to happen is all so im wary when getting people to do stuff around imports, just in case.

that process should work - or at least i cant see anything obvious that could cause a mass deletion. not unless your temp file is somehow named for the whole season, eg s01e01-24, but that also implies that sonarr was scanning the folder at the same time tdarr was converting, and sonarr only scans once every 12 hours (iirc) so that doesnt seem reasonably possible.

does tdarr have logs? can you tell what time it was converted and replaced the file vs when it was deleted?

if you move all those x265 files in the recycle bin out to somewhere else and import them from there will they all disappear at the next conversion?

#7

i can only think that sonarr got new files somehow. is tdarr doing something to update sonarr? like an API call saying hey, ive got new files here so import them, and theyre the same file so when sonarr deletes the “original”, it then tries to import the “new” file, which no longer exists - and fails?

this is why we want debug (trace might be better for this) logs - it will show exactly what happened, and why.

i would have expected sonarr to have validation code to stop someone doing something like that though.

if possible maybe see if you can configure tdarr to use a different/specific folder for the conversions and see if that stops the deletions?

#8

I’m having this same problem, it appears based on this old thread this is actually intended behavior. When Sonarr see’s the video file has changed its deleting all the “matching” files from the old video file.

I just tested this on a virgin docker install of Sonarr and this is reproducing it for me every time.

1.Go to Settings -> Media Management -> Importing -> Check/Enable Import matching extra files, then add “srt” to the list field directly below.
2. Find a download on your indexer that has a video file and a srt file. Download it and let Sonarr do its thing. In this example lets say its episode1.mp4 and episode1.en.srt
3. Now use any encoding software (handbrake, ffmpeg, etc) and just remux the file from mp4 to mkv. (The main thing is the file name and/or extension needs to change, so Sonarr recognizes it as a ‘new’ file.)
4. Now go into the series on Sonarr and click “Refresh & Scan”, after its done the srt will be gone because Sonarr sees its “matching” video file is gone and delete all “matching” files.

This makes sense to me when Sonarr is upgrading a file, it should delete the matching files for the old file since they likely won’t match anymore. It would be nice if there was a way to tell it only to delete matching files when Sonarr is changing the video file and ignore all other changes to the video file or something like that.

#9

The issue is Sonarr sees the file as deleted before it knows there is a replacement file, but even if it knew about the file it doesn’t know if that file is the same (it uses the name for that).

As of the latest develop releases Sonarr will now detect that a file has been changed if the file size changes (and then refetch mediainfo), which would help in this scenario as they aren’t treated as deleted.

#10

Would this work independently from the ’ Analyse video files’ option?

#11

Yes, but that setting would need to be enabled for Sonarr to update an stored media info.

#12

Ok I understand what you mean but there seems to be another issue. Sonarr doesn’t auto run that import. is there anyway to have that happen? Would it be possible to write a script that tells Sonarr to rescan the files of a specific series after transcode completes? if not would there be a way to run a automatic import of the downloads folder? I know drone is gone but that’s the only other way I think it could work. Is there something I’m just miss-understanding? Above is a response from leko they state that the file needs to be renamed in someway but mine aren’,t is that why sonarr fails to see the file updated? I feel like the easiest solution would be just to delay the removal of a deleted item in sonarr for a user set amount of time. After that set time if the file was replaced it won’t unmonitor the series but if it was not replaced it would unmonitor.

#13

By default Sonarr scans the series folder every 12 hours, if the file is there it’ll be picked up, if it’s somewhere else then you can use the API to do it.

Yes, link to the outdated API docs as there aren’t currently newer ones: https://github.com/Sonarr/Sonarr/wiki/Command#rescanseries

Use /api/v3/command instead of /api/command.

Where are the files? If they’re in the series folder then you can either tell Sonarr to rescan the series or wait for it to pick it up (that with not changing the file name will not delete the extras).

If they’re outside the series folder the you can use this command via the API: https://github.com/Sonarr/Sonarr/wiki/Command#downloadedepisodesscan

#14

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.