Bug or by design (is this already being discussed feature)

[Larreyvol1]

Just found that certain releases have already been requested earlier, but are not found based on the naming of the release.
In this specific example it was found when the srrdb link was copied as the name for the thread, which then found the earlier request.
Once this is then updated by removing srrdb and only having the name of the release left the earlier topic changes.
Example: https://www.srrdb.com/release/details/Atjazz-For_Real_EP-(INNERVISION07)-WEB-2006-ATRium

 

[9s6YGGKbfVTZ]

All releases that have "(" and ")" in them have this problem.

 

[Larreyvol1]

But my example does not have and in it right, so there's more which impacts it.

 

[aGGyunit]

It's not about the AND
It's about:
(
)

Those 2 characters only.

 

[Larreyvol1]

Why does it then differ between https://www.srrdb.com/release/details/Atjazz-For_Real_EP-(INNERVISION07)-WEB-2006-ATRium and Atjazz-For_Real_EP-(INNERVISION07)-WEB-2006-ATRium, as both include these two characters?

 

[aGGyunit]

No idea, but the search and the "is this discussed" box both suffer from various issues with ( ) or really long release names (and some other issues).
I have no answer as to why this is. Maybe the @admin @Scnlog can look into this.

Just understand that it's broken and has been since the beginning.
That was being discussed over in the forum feedback topic: https://scnlog.me/forum/threads/forum-feedback.24/post-51384

So if using the SRRDB link makes it work correctly, that would explain the few times people requested the actual srrdb link instead of the release.

 

[somegrue]

I can't reproduce the problem for this release name; it comes up in both the search and the widget both with and without the srrdb prefix. Re-reading my earlier investigation, I traced the bug to bracket-underscore sequences specifically, which this one doesn't have. *shrug*

 

[9s6YGGKbfVTZ]

It's interesting what user wizotoo have found here: https://scnlog.me/forum/threads/forum-feedback.24/post-132008 -the search works; only if you cut release name at the 2nd "-".

 

[somegrue]

It's interesting what user wizotoo have found here: https://scnlog.me/forum/threads/forum-feedback.24/post-132008 -the search works; only if you cut release name at the 2nd "-".

It's the expected behaviour, based on my previous tests.

New_Order-Low-Life_(Definitive)-24BIT-96KHZ-WEB-FLAC-2023-OBZEN

"Life_(Definitive)" is the problematic substring; minuses more or less work as whitespaces. Searching for any or any combination of

New_Order
Low
24BIT
96KHZ
WEB
FLAC
2023
OBZEN

should be fine, like so:

New_Order Low 24BIT 96KHZ WEB FLAC 2023 OBZEN