Appending the duplicate episode with quality and timestamp is normal behavior, downloading the duplicate is not however. It sounds like MR is properly identifying the existing episode (on disk) as being at the desired quality during sort but not when scheduling. Two things: what version of MR are you running? And can you send me a copy of your log files?avatarr wrote: I'm occasionally having an issue that sabnzbd downloads a duplicate episode (even when my desired quality is "high" and there is an episode with the .mkv extension already). It downloads the episode, goes to sort, and then identifies that the duplicate episode exists. At that point it then moves (renames) the file with quality and date / time info.
Correct, MR will replace an existing episode with a more desirable version. However this behavior only occurs when moving from one quality level to another. So using the situation you described above, MR would replace the avi with the mkv. When sorting a true duplicate (two copies at the same quality level), the current approach is to keep both copies. The original thinking behind keeping both was that if/when the user manually scheduled a duplicate for download, they might want both copies for some reason.avatarr wrote: Shouldn't it either be deleting the old one or not downloading the show at all since the desired quality of the show already exists? What happens when my feed pulls down an avi (medium) and later finds a high quality version? I imagine that it would delete the .avi version and replace it with the .mkv. I'm just confused as to why it's replacing a .mkv with another .mkv.
Hmm I don't think the problem lies with how you have MR configured. In my own configuration, I have 6 configured sources: 4 standard def and 2 HD feeds. I too have multiple configured to catch something that might fall through the cracks, and to test the sources supported by MR .avatarr wrote: After having typed all that, it occurred to me that the cause is most likely my use of two rss feeds from two sources. This apparently ends up queuing the download of one version from one RSS source and then another from a separate RSS source. In essence, it doesn't find the episode even though it's queued it for download already. Looking in my SABnzbd history, it shows the two versions of the show / episode in question being completed within 2 minutes of each other. What's the best way to prevent this from happening? I use them both in case one ends up having some shows / episodes that the other doesn't.
When scheduling items for download, MR makes every attempt to avoid scheduling duplicates. It checks the queue, nzb backup directory (if configured), and the filesystem before telling SABnzbd to start downloading something. Furthermore, this checking does attempt to work across sources. This means that any items identified for download from Newzbin will be checked against items that have already been identified for download from all other sources.
As I sit here and respond to your post I've been thinking about how MR handles duplicates and I think I agree with you: MR should just replace the episode rather than keep a duplicate copy. If the user manually scheduled a duplicate for download they likely want to replace a defective copy already on disk. If MR is the one scheduling duplicates, there's a problem. However, the user shouldn't have to deal with duplicate files. A nice warning message in the logs should suffice.avatarr wrote: It does bring up the question of allowing the control of what the script does when it finds duplicate episodes of the same quality. Yes, the bandwidth has already been used but it would be nice to be able to tell it to just nuke the file since it's already there. Then again, there might be a reason why you would want to know that it downloaded duplicate episodes (like, say, to bring ones attention to the fact that they're being downloaded and prompt the user to come up with a fix).
It sounds to me like there is a problem with the quality management system in MR. I recently released 0.6.0 which included several bug fixes to quality management. It is possible the issue you are experiencing has been fixed. If you aren't running 0.6.0 try upgrading and seeing if it solves your issues. If you are running 0.6.0, send me your logs and I'll see if I can figure out what's going wrong.
I'm hard at work on 0.7.0 at the moment. I'll take a ook at how MR deals with duplicates and make it just replace the existing episode and generate a warning.