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.
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.
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)
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.