I have an album for which I have the catalogue number.
It’s: GLO 5252
Yet I can’t find the album on MusicBrainz using this reference.
I tried using several search selection fields such as ‘release’, ‘recording’, ‘label’, etc.
None of them will find this album.
Yet it does exist in the database, and it seems to have the correct catalogue number.
What am I doing wrong?
And, is there a reference table to be found somewhere that explains what the selectable search fields such as ‘release’ ‘release group’, ‘label’, ‘tag’ etc. etc. query exactly?
This search will find it (as will the same search with a space and quotes, catno:“GLO 5252”). Annoyingly, just entering GLO 5252 on the catalog number search in the search page won’t work, because it breaks on spaces (sigh).
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.
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.
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.
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?
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)
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????
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.
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.
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.