pymedusa / Medusa

Automatic Video Library Manager for TV Shows. It watches for new episodes of your favorite shows, and when they are posted it does its magic.
https://pymedusa.com
GNU General Public License v3.0
1.8k stars 276 forks source link

Downloads same episode more than once #10869

Open mmhere opened 2 years ago

mmhere commented 2 years ago

Medusa sometimes downloads the exact same episode (same provider, quality, all details exactly identical) more than once.

As far as I can tell, this seems to be because the downloader proceeds slower than Medusa expects, Medusa times out awaiting a successful download, then responds by sending the same episode to the downloader again.

Is there an assumption somewhere about what the download rate is? Or does Medusa "learn" the download rate over time, try to adjust for multiple gets, but maybe sometimes gets it wrong?

This happens most often with episodes that are larger than normal, say because the quality selected was higher than usual, or when a season finalé is extra long and so takes longer too obtain.

Is there such a download rate assumption? Or does it learn and adjust this over time?

If there is such an assumed download rate, could it be exposed in the UI somewhere?

My modem is not the speediest thing in the world, so if I could tell Medusa what the expected rate is, perhaps Medusa could adjust?

This also happens if there are several things in the DL queue on the downloader side, and I swizzle things around because I choose to have some other episode finish first.

In the end, Medusa some times sends the same file to the dowloader more than once [it does not always do this] resulting in the same bits being downloaded more than once. The modem gets very tired.

medariox commented 2 years ago

Do you have debug logs that show both snatches?

mmhere commented 2 years ago

I'll post a log snippet here (about 57KB) if that's OK.

First, from the GUI "history" panel, these summarized events are relevant;

__from the "History" panel in GUI__

manual get, by me in the GUI:
22-08-11 18:30 For All Mankind - s03e10    Snatched 1080p WEB-DL NZBFinder 7.60 GB

download still running, system chooses same exact release to DL, again:
22-08-11 19:09 For All Mankind - s03e10    Snatched 1080p WEB-DL NZBFinder 7.60 GB

Then a minute later this, again:
22-08-11 19:10 For All Mankind - s03e10    Snatched 1080p WEB-DL NZBFinder 7.60 GB

So I was monitoring the availability with Forced Search, I saw the one I wanted, and I got it around 18:30. DL began, and was gonna run for a long time.

While the DL was still running, Medusa grabbed the identical item at 19:09, and then again shortly thereafter at 19:10.

Original DL was still running, so I had three in the downloader queue at that point. I nuked the two newest additions.

In the attached debug log that was being captured at the time, I merely grepped for the show in question in this time range, thus throwing away all other stuff. I sanitized user and file details with "REDACTED". I hope the resulting log info doesn't omit too much useful info (by grepping for the show name on each line), but I'm not comfortable posting the full details.

t3.medusa-grepped.txt

medariox commented 2 years ago

Just to be clear: these are NZB snatches, not torrents, right?

mmhere commented 2 years ago

nzb only, yes.

failed release processing is also enabled, but there were no DL failures here.

mmhere commented 2 years ago

Also, this behaviour has been occurring for quite some time, although it is not very frequent.

In this example I provoked the system, perhaps, by requesting a manual snatch ahead of time.

I have, however, seen double snatches occur under full automation -- that is, when the system decides to get something, the download takes a long time, and then the system gets the identical item a 2nd time a little bit later. This occurs, although infrequently, under full automation -- say overnight when no one is watching. The downloader happily obliges creating two downloaded files where the 2nd one is named with an extra serial number.

mmhere commented 2 years ago

Also, if you rejigger the queue order in the downloader, this can cause out of order completion so that Medusa sees something it may have expected sooner, in fact come in a bit later.

This is why my initial query was about what logic and timing Medusa uses to decide a DL request "took too long" so that it goes and gets it again. If there is some sort of timeout or assumption about DL rate, it would be nice to have that exposed in the GUI so those of us with slower connections can help Medusa set completion/time expectations.