Medusa: Global Ignore words not working anymore
Describe the bug
After the upgrade to 0.30 my global ignore words are not being picked up anymore.
Expected behavior
With the new addition of filtering ignore words per show basis I would still expect that by default all Global Ignore words would still be applied
Screenshots
I have Strife as Global Ignore Word but shows up as valid downloads
Medusa (please complete the following information):
Medusa Info: | Branch: master Commit: 94fae847b6e7e443d74c59cb11bdbd37c464b363 Version: 0.3.0 Database: 44.12
-- | --
Python Version: | 2.7.15 (v2.7.15:ca079a3ea3, Apr 30 2018, 16:30:26) [MSC v.1500 64 bit (AMD64)]
SSL Version: | OpenSSL 1.0.2o 27 Mar 2018
OS: | Windows-10-10.0.17763
Locale: | nl_NL.cp1252
Rouzax
All 21 comments
You sure it's ignoring the global ignored words in backlog / daily search? Or it's a manual search visualize thing?
p0psicles
on 14 Mar 2019
hello.
i am having a similar issue. in my install it looks like the global ignore words are used for ignore words and required words as well. though adding exceptions works correctly on screen.
preferred words display correctly but are not taken into account in manual search. neither required nor ignored works seem to be taken into account in manual search.
i will keep an eye on log for examples from automatic searches. thanks.
- scott
scott451
on 14 Mar 2019
Manual search never takes into account any restriction, that's the whole point of the manual search: to give you the full overview of what's actually available. It only highlights the ignored/preferred releases with different colors and that may be broken. That doesn't mean that the ignored/preferred words are broken on a normal/backlog search. That's why we need debug logs of a non-manual search, to actually verify this bug and eventually take care of it.
medariox
on 14 Mar 2019
sorry i wasn't clear. the highlighting is no longer present in the visualisation of manual searches.
scott451
on 14 Mar 2019
It not showing my ignore words and it is not marking the entries as red in the search result list, which was previously the case.
Can't say for sure if it is actually adhering to the rules for snatches as that hasn't happened yet
Rouzax
on 14 Mar 2019
Since this issue seems confirmed, is there a hot fix planed for it to v0.30?
rafi-d
on 15 Mar 2019
Since it is an issue that doesn't affect functionality, it probably won't make it into the first hotfix release.
medariox
on 15 Mar 2019
You sure it's ignoring the global ignored words in backlog / daily search? Or it's a manual search visualize thing?
I've checked, and it seems NOT to ignore the global "Ignored words" in daily search.
Still, UI is related to functionality too, just a bit ... :)
PS/Edit:
Since you are looking into this area, just an idea on how to improve those lists of words: somehow make it possible to see which are GLOBAL and which are local/per show , maybe using bold (for global) vs _regular_ (for local) fonts?
rafi-d
on 16 Mar 2019
For now the api returns it as one list. But maybe for future sure
p0psicles
on 16 Mar 2019
For now the api returns it as one list. But maybe for future sure
Maybe you can simply use (for example) series.release_ignore_words AND app.IGNORE_WORDS separately, one after the other? I am using this to priorities local over global for 'key words' I am using with %keyword=value format.
The idea for the user to be able to know WHERE to go to change a word - edit-show, or global search-preferences.
rafi-d
on 16 Mar 2019
There has been a release in the mean time but this was not picked up.
Rouzax
on 11 May 2019
will be implemented with #6315
p0psicles
on 13 May 2019
But when?... :)
rafi-d
on 13 May 2019
When its merged :)
p0psicles
on 13 May 2019
@p0psicles
This was fixed with a recent release but it seems to be broken again, is that correct.
Rouzax
on 2 Feb 2020
Afaik we haven't changed anything in that area
p0psicles
on 2 Feb 2020
There has been a release in the mean time but this was not picked up.
He is right, it seems not to work also in 0.3.10 , I guess a regression has crawled in ... :(
Not sure if it is GUI related only or not, I don't see this effecting the downloads...
rafi-d
on 2 Feb 2020
There has been a release in the mean time but this was not picked up.
He is right, it seems not to work also in 0.3.10 , I guess a regression has crawled in ... :(
Not sure if it is GUI related only or not, I don't see this effecting the downloads...
On a side note, I see you have things like min and max sizes, is that something that is already supported?
Rouzax
on 2 Feb 2020
There has been a release in the mean time but this was not picked up.
He is right, it seems not to work also in 0.3.10 , I guess a regression has crawled in ... :(
Not sure if it is GUI related only or not, I don't see this effecting the downloads...On a side note, I see you have things like min and max sizes, is that something that is already supported?
Yes, fully supported by my own local modded version.. ;p
PS/edit:
The devs claimed my modification is not suitable/in-line to their current code design intention, and were not willing to integrate the PR I proposed here... Yet, I am completely satisfied with it, and they are more then welcome to make a better implementation in a year or two... ;)
rafi-d
on 2 Feb 2020
They probably are looking to integrate it more into the GUI.
Rouzax
on 3 Feb 2020
They probably are looking to integrate it more into the GUI.
That's probably one consideration.
Another is that it not "general"/flexible enough in their view, since my "concept" (due to lack of GUI) is to be as automatic as possible, so, taking the factors of episode run-time, resolution and compression type automatically to auto-tune/normalize the desired size limit to be snatched...
In my experience, this is working pretty good so far :)
rafi-d
on 3 Feb 2020
Related issues
elpedriyo
路
4Comments
lamplis
路
3Comments
sebeksd
路
3Comments
GritGub
路
3Comments
a10kiloham
路
4Comments
Most helpful comment
When its merged :)