Enable debug logging in Medusa settings, reproduce the error (be sure to disable after the bug is fixed)
Branch/Commit: Dev
OS: Win 10
What you did:
Ran manual PP on a file. Existing file is 1080p Web-DL. New quality is 1080p HDTV.

What happened: Manual post processing logs reported Processing failed: File exists. Marking it unsafe to replace. Reason: New quality is lower than current Preferred. Ignoring quality
What you expected: Logs should state New quality is not a preferred quality and a higher allowed quality already exists.
Logs:
Postprocessing results
Processing folder G:\tmp\download
PostProcessing Path: G:\tmp\download
PostProcessing Dirs: []
PostProcessing Files: [<files>]
PostProcessing VideoFiles: [<video_files>]
PostProcessing RarContent:
PostProcessing VideoInRar:
Processing <video_file> (Torrent)
Retrieving episode object for <series> <episode>
Looking up quality for <video_file>, got Unknown
Looking up quality for <video_file>, got Unknown
Trying other methods to get quality for <video_file>, got 1080p HDTV
Looks like <video_file> has quality 1080p HDTV, using that
Snatch in history: False
Manually snatched: False
Current quality: 1080p WEB-DL
New quality: 1080p HDTV
Proper: False
This episode is a priority download: False
File <existing_file> is larger than <video_file>
Checking if new quality 1080p HDTV should replace current quality: 1080p WEB-DL
Processing failed for <video_file>: File exists. Marking it unsafe to replace. Reason: New quality is lower than current Preferred. Ignoring quality
Problem(s) during processing, failed the following files/folders:
[<video_file> : Processing failed: File exists. Marking it unsafe to replace. Reason: New quality is lower than current Preferred. Ignoring quality]
so you want to change the reason text? is that a bug? isn't a feature?
It's a bug since its reporting incorrectly. If it was just a recommendation to change how it read it would be a feature.
You said: New quality is not a preferred quality and a higher allowed quality already exists.
To get that log:
1) New quality IS in preferred. So is wrong to say "New quality is not a preferred quality"
2) When preferred set, doesn't matter the allowed quality. So why say "higher allowed quality already exists"
So i still don't get why "New quality is lower than current Preferred. Ignoring quality" is wrong
if new_quality in preferred:
if current_quality in preferred:
if new_quality > current_quality:
return True, 'New quality is higher than current Preferred. Accepting quality'
elif new_quality < current_quality:
return False, 'New quality is lower than current Preferred. Ignoring quality'
@fernandog look at the posted quality settings and the log
New quality: 1080p HDTV
1080p HDTV is in allowed not in preferred.
Current quality: 1080p WEB-DL
1080p WEB-DL is also in allowed not in preferred
So "New quality is lower than current Preferred. Ignoring quality" is wrong because the current is not a preferred quality, its an allowed quality.
So now you are question the rule, not the log?
ask @medariox as its his rules. I only added the reasons
No the rules are performing correct in that an allowed quality should not be replaced by another quality (we should be downloading at most one preferred and one allowed with settings configured as above) but the log states an incorrect reason for failing to post process the download. This means that either the logging is incorrect or the logic that lead to that logging is incorrect.
Just FYI, here are the wrong logs that would need to be changed: https://github.com/pymedusa/Medusa/blob/develop/medusa/post_processor.py#L886-L890
@medariox thanks, I'll PR the correction this afternoon
@medariox thanks for explaning/pointing the issue. i didn't understand from lab explanation
Most helpful comment
Just FYI, here are the wrong logs that would need to be changed: https://github.com/pymedusa/Medusa/blob/develop/medusa/post_processor.py#L886-L890