You want to say: Search for a “CD Stub” or “Tag” is more important and useful then search for a catalog #?
1 Like
No, he’s saying that a CD Stub and a Tag are different kind of things than a Release, while a catalog number is a different way to find a release. Tag finds tags, not releases with those tags, while catalog number (or barcode) are specific ways of searching for a release 
Searching by catno is definitely useful (and one of the many options at the search page) but not at the same level.
4 Likes
Yeah yeah - necro-posting, but I think this is sensible place as it is an extension of the same question.
I want to find Releases within a series of cat numbers WPCR-8xxxx
I can do an advanced Release search for
catno:WPCR
That finds nothing. Okay, so it is trying to do an exact match.
So try a star on the end and I get LOADs of results. Too many.
catno:WPCR*
But why can’t I search for
catno:WPCR-8*
Escaping that dash doesn’t help
catno:WPCR\-8*
I am trying to find releases which start with a certain cat no, but that dash is a pain.
I tried this
catno:WPCR?8*
But that seemed to replace the number after the dash. Giving me results where the 8 is the second digit. But I am trying to find it in the first place.
Search Gurus - how do I search for cat nos with dashes in them? And can someone add examples of “odd” searches like this to the help page.
Edit: Errr… just answered my own question, but it doesn’t make sense.
Can someone add that to the search instructions? What other characters are ignored by a search? And if they are ignored, why do they not get plucked out of the search string? Not really logical to me to drop characters from a search string.
6 Likes
Thanks for reviving this IvanDobsky.
I also remain unsatisfied with the workings of search and matching cat. numbers.
But I was probably too lazy to continue on the matter and compose the right wordings and concrete examples.
2 Likes
My examples came from not giving up as I am a stubborn SoB. 
The trouble is there seem to be a lot of hidden tricks in the search that do not seem to be documented. If the search gurus could write down some of these items then it would help loads.
I often have albums I am trying to locate on a barcode, or a catno. And I didn’t realise that I could break my search by including a dash.
I guessed dashes would be a problem as they are stored in so many different ways due to the Unicode prettification crowd, but I didn’t expect them to be totally ignored.
Personally I had assumed that a search would swap all forms of dashes into one type for the search. Same with apostrophe’s. But that is also not clear.
Example, looking for “McDermott’s 2 Hours” I would have expected a search for McDermott’s would have put them first. Instead they appear on page three of the results. NONE of the other results have an s in them, so why do they appear earlier?
Is that the apostrophe being ignored? OR because I used the keyboard?
Edit: So why does this work:
McDermott’s 2*
But this fails?
McDermott’s*
And WTF is that first result when I add a space? LOLz
McDermott’s *
How does MHz * * * match that in any way? It should not even be in the list at all, and especially not the first result.
Surely these should all give the same results? 
1 Like
Barcodes usually are a no-go area for me too in relation to doing a search on them.
I never know if I should enter all numbers, take leading or trailing separated digits into account, use the same spacing as on the print, etc.
Some algorithm smarter than me would be great to have for barcodes too.
edit:
Maybe better ignore this comment of mine on barcodes.
I should teach myself and remember that entering at least the most significant middle digits of a barcode, and surrounding them with * like this 65465654654 works perfectly.
(there are asterisks surrounding the digits, but the forum uses them to turn the content inbetween to italic)
2 Likes
Surely a barcode advanced query search should be cleaner?
A RELEASE search as follows
barcode:3229261055728
That did give a single answer. But barcodes are normally clean sets of numbers without odd punctuation.
A wildcard on that also worked fine
That gave me lots of releases from the same French manufacturer, same decade, as I’d expect.
For anyone else reading this, we are playing with the advanced search at the bottom of the search page:
4 Likes
You should be able to find them by searching for WPCR8??? (not sure why does it display only 3 question marks when I inputted 4).
3 Likes
The forum will often eat ? or * symbols. Put a \ in front of any that go AWOL in the post and they’ll appear. (I needed to put the slash in front of the last ? in the following example)
I understand the ? alternative for search, but that doesn’t explain why the dash makes the search fail.
WPCD-8???? fails to find anything. It also fails if I put a wildcard in for the dash WPCD?8????
That doesn’t make sense.
1 Like
it is ignored, like spaces and other “separators”, I guess.
Which is intelligent in a way.
1 Like
Agreed for the indexing side. But I also agree with @IvanDobsky that it would be even more intelligent if the same filtering would be applied to search terms. So if the indexing is reading a cat. no. “ABC-123” and stores it in the index as “ABC123” that’s totally fine. But then when someone enters the search term “ABC-123” that should also be filtered the same way and trigger a search for “ABC123” in the index.
6 Likes
Afaik you could search for the dash in the old search and it wasn’t ignored (before it was changed to SOLR), although I’m not 100% sure.
1 Like
It doesn’t seem “intelligent” to ignore a random selection of characters from a search without telling the user why their search failed.
This is the point I was getting at. If the search is going to ignore a selection of characters, then they need to be stripped from the search string. NOT throw an error.
When I search ABC-123, the text should be stripped to ABC123 and passed to the search invisibly.
OR DOCUMENT IT!!
I don’t know how it helps anyone to have an invisible list of illegal characters that the user needs to drop for their search strings. These characters need to be dropped by the search routines.
Remember - normal people are trying to use this database and the search. Hidden geek rules about typing totally different strings into the search just cause confusion and mean less people use the database.
Make the search friendly please.
Ah - finally worked out what @outsidecontext is saying. So the DATABASE has stored the text in a stripped down way to make it easier for indexing. In that case the error is searching the index instead of the data. Catnos often have dashes, dots and spaces in them. They should be part of the search OR consistently ignored.
5 Likes
Oh that’s true.
In fact, all the characters, that are ignored for the making of the search indexes, should equally be ignored in your search string.
2 Likes
Exactly. THIS a key bug that needs fixing. When I put ABC-123 into the search, then the search code should drop the dash without telling me and search ABC123. Then there is more chance sensible results will appear.
4 Likes
The way the search handles (not) catalog numbers is completely bonkers.
I’ve tried to find https://musicbrainz.org/release/1fefe012-e227-4071-8486-79c73ab88d1c only by its catalog number: COCC-13058
Indexed release search:
- COCC-13058 (no results)
- COCC13058 (no results)
- *13058 (no results)
- COCC*3058 (returns a bunch of stuff but nothing remotely I was looking for)
Did I miss any combination or is the index broken for some entries?
Indexed release search with advanced query synax:
- catno:COCC-13058 (exact match)
- catno:COCC13058 (exact match)
- catno:*13058 (multiple results including what I was looking for, though it’s the last one)
- catno:COCC*3058 (exact match)
If I was a new user trying to contribute I certainly wouldn’t expect the default search to be that unreliable.
3 Likes
The default search, AFAIK, doesn’t take catnos into account at all, it’s searching for them as part of the title.
1 Like
Talking about making it easier to find stuff: 
Perhaps a mod could correct the misspelling of ‘catalogue’ that I made in the topic title some two years ago?
(It seems I am not allowed to do that myself)
1 Like
Great. 
Some tickets about punctuation in catalog number:
The example for SEARCH-34 provided by Paul Taylor no longer(?) works:
And as much as I personally like MBS-6740, it’s not a proper solution either. As argued by nikki, ordinary users won’t bother with advanced query syntax.
Done.
2 Likes
Funny we were talking about Search Bugs together only the other day. Now you have read this thread you can understand my response at the time.
MB search is just plain weird.