100's of errors "DetectSample"

Help & Support
#1

Sonarr version (exact version): 3.0.8.1517
Mono version (if Sonarr is not running on Windows): 6.12.0.122
OS: Ubuntu 20.04
Debug logs: https://0bin.net/paste/-WBHmfpU#pCFLfL7dAQPC-BBjrg+zSJExvd+ZQXYD6Lf8O1jo+7W
Description of issue:

Over the last few days (not sure when exactly) I started to get hundreds of “DetectSample” errors in the logs, and some (not all) of my downloads would be stuck in “Activity”, asking me to manually import. If I do so, most of them (but not all) are bad files that won’t play.

I don’t know if it is coincidence, but a few days ago (and perhaps when this started), I accidentally removed ffmpeg from my system. I reinstalled it. Unsure if it is related.

If there suddenly are just a bunch of shit files out there to be downloaded… is there an option to auto-reject files detected as “samples”?

PS. I know I should have debug on and I did not for the logs I pasted. I’ve turned on debug now, but I will have to wait until some shows try to d/l and it happens again. I thought maybe the info logs would be helpful in the meantime.

Thank you.

#2

Sonarr version (exact version) : Version 3.0.8.1507
Mono version (if Sonarr is not running on Windows) : 6.12.0.122
OS : Ubuntu 20.04.4
Debug logs : https://pastebin.com/rhahN19LBBjrg+zSJExvd+ZQXYD6Lf8O1jo+7W
Description of issue : Similar issue, all of the downloads today are marked as samples due to a runtime of 0. Manual import to get around it, but just weird. I updated to the latest versions but had the same problem. Pretty much the same OS as well. Though I am running this in docker.

#3

I am in Docker as well.

Did you check that the manually imported file will actually play? In my case, at least most of the “sample” files won’t play on any player I’ve tried, including Plex transcoding.

Which makes me wonder if it is simply an issue with what’s being released. But then I have to think there must be a way to have Sonarr automatically reject these rather than having them sit waiting for a manual import.

PS. It happened again while I had debug on. New log at https://0bin.net/paste/ACXe7dFz#aRbFl1YEl25z-Kqpd78bEVkWfi/s7vD4y5Y3TPlfrvO

#4

In this case it appears Sonarr can’t get the run time from the video file (via mediainfo), either there is some issue with mediainfo or perhaps it’s an old mediainfo version, it’d be best to contact the maintainer of that particular docker image you’re using and make sure media info is up to date.

If mediainfo is already up to date there might be something with the video file that mediainfo isn’t handling properly.

#5

So a good point, I hadn’t tried these files yet. I just assumed it wasn’t file specific since it was multiple different videos across different release groups, all the most recent ones downloaded. None of them play within plex or with vlc. They all do have real file size, but I’m guessing something is new or broken with their encoding.

I don’t think this has anything to do with mediainfo, unless there are some new codecs that are being used.

#6

Poking at one of the files it seems the metadata is missing, just weird that it’s multiple files, even a redownload of a different release today.

This is ffmpeg/ffprobe result:

[mov,mp4,m4a,3gp,3g2,mj2 @ 0x55facdfe7a80] Format mov,mp4,m4a,3gp,3g2,mj2 detected only with low score of 1, misdetection possible!
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x55facdfe7a80] moov atom not found

so this is likely not really a sonarr issue at all, just something going on with the things we are downloading, new DMCA campaign? lol

#7

I tend to agree, except that it is a bit suspicious that nobody is complaining about this beyond me and you that have rather similar systems. We’re both using Docker on Ubuntu, for example.

But I’m seeing the same as you: multiple files (but not all) that are corrupt all of the sudden.

The only reason I see this as a Sonarr issue, is that it should be able to handle what it detects as “samples” with some elegance.

#8

You know what, it is easy enough to test.

I also run a friend’s setup, which is very similar to mine, but he’s had none of these same issues. Of course, he watches different shows. But for sure he hasn’t messed with his ffmpeg like I (accidentally) did so that rules that out.

So I just uploaded to his system a NZB that failed on mine, and it fails in the exact same way on his.

I would suggest it must be an issue with the uploads. Something’s changed with more than one release group’s encoding/methodology or, as you suggest, this is a DCMA type campaign or something to that effect.

My point still stands. @markus101 is there a way for Sonarr to handle the sample detection failures better? Just fail the d/l and move on.

#9

dozens more today. I can’t imagine this isn’t a widespread problem.

I did notice many of the failed releases are megusta releases, but certainly not all.

#10

Had more today as well, I just mark as failed and blacklist and it gets a good copy. Would be nice if sonarr did that automatically if it finds it is invalid.

#11

That’s the same workaround I’m using, but the whole point of automation software is… well… automation lol.

Since.100 people aren’t piping in though, I can’t help but to think it is something with our setup.

#12

Started happening to me as well this past Sunday and every day since. I have to manually download new versions in the morning to get them to import.

My assumption is that it’s the releases that I’m getting from usenet indexers, not sure if torrent users are experiencing the same thing

Running Sonarr 3.0.8.1507 in a docker in Unraid.
Never had any issues until Sunday night

#13

@markus101 that makes three of us.

You’re the expert, but logically it doesn’t seem like it would be a mediainfo issue since these files aren’t playing either. I had thought that some were, but I may have been confused and played a re-grab. Since looking more carefully, 0% of these files detected as samples play.

It obviously wouldn’t be a sonarr problem, but could there be a sonarr solution? Some option to auto reject and retry zero-length files? I would have thought that to be the default anyway, in case of a bad release!

#14

Our current position is if the download completes successfully any failures to import the video file require user interaction, there are many edge cases that could lead Sonarr to delete a valid file that we don’t want to undertake. This could change in the future, but not something we’re going to undertake right now.

Are all these bad releases coming from a single indexer (or a couple)?

#15

I’ve checked the last bunch of failed imports and they all seem to be coming from altHUB, I’ve turned that indexer off. We’ll see how it goes. Thanks for the insight @markus101

#16

Interesting. I use Althub as well and the friend that has an almost identical setup does not. He hasn’t had this issue but the one nzb I tested on his system was from Althub.

#17

Just FYI @markus101 and others: I haven’t had a single issue since removing Althub from my indexer list.

Curious how an indexer can have an this kind of effect? And what clued you into that?

#18

Good to hear, as for what clued me in, just a hunch based on the small number of users reporting it here, but not seeing it else where made it a lot more likely that a bad indexer (or two) is releasing crap.

#19

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