There is no aria final fantasy vi in aliases.
There is aria alias but final fantasy vi is a parent work.
You would like parent work titles and aliases be taken into account in work search too?
I like it that the results are now more specific to the search, personally, it is why I used to use the direct search often.
I think searching parent works would be a boon, it would solve the problem nicely.
Does new search not do partial matching for aliases? “rahva” used to find https://beta.musicbrainz.org/artist/9be7f096-97ec-4615-8957-8d40b5dcbc41/aliases but it no longer does.
I just searched artist index for fred _and was a bit surprised it return _Fred Astaire, Fred Frith, Fred de Fred and Fred Steiner before any artists just called Fred
https://musicbrainz.org/search?query=fred&type=artist&method=indexed
I then tried an advanced search just on artist:fred and the first first_ Fred_ didn’t come until bottom of the page.
https://musicbrainz.org/search?query=artist%3Afred&type=artist&limit=25&method=advanced
I know it was decided to boost popular artists over less popular ones (which doesnt seem very musicbrainz which is why I never did it), but shouldn’t exact name matches should come before partial matches (a search for Fred is a better match to Fred then to Fred Astaire)
I’d expect Search Results - MusicBrainz to find Maria Drozdova - MusicBrainz (same surname, only one letter difference - turns out it’s the same artist too).
It might work now that I’ve used her on an AC, not sure - it definitely didn’t work earlier though, 0 results.
Searching for “XXme” doesn’t find an artist entered as “XX:me”. Not really sure if that’s a major bug or something easy to fix, but I imagine that kind of behaviour will fool people into believing that the thing they’re searching for doesn’t exist in the database.
Also, this should probably be updated at some point.
Hi,
not sure if this is SOLRs fault, but:
Search for releases where script is not set
does not seem to work anymore
Same query on mb-beta
is the same
These queries are used on the statistics page.
Searchable via https://musicbrainz.org/search?query=-script%3A*&type=release&limit=25&method=advanced
We will be switching to a consistent syntax as above to find all unset fields.
While I felt the old search was a bit odd to use, giving me dozens (sometimes hundreds) of unrelated results, including results that I can’t even figure out how or why they could be included…
The new search could maybe be expanded a little. For example:
I searched confederate railroad, but I misspelled it. My search, confederate railrold, gave me zero results.
While zero results is technically correct, a loosening of the criteria could be useful. Especially when considering simple name variations (john vs jon or smith vs smithe).
I’ve noticed 2 bugs with the new search system.
When searching by specific release date, search results include releases where only year is specified in release date field. Previously such releases were not included (and I believe they shouldn’t be). Example of query: https://musicbrainz.org/search?limit=100&method=advanced&page=1&query=date%3A2018-06-30+AND+status%3Aofficial&type=release
Something is wrong is paging. If you run the query above and try to switch from page 1 to page 2 and back several times, you will see that content of each page is not permanent. Or you can simply refresh the page several times - in 50% cases it will display different records.
Have you got some tests for this new search. If not you really need some otherwise you’ll find that as you try and improve things for one type of search you will inadvertently make the results worse for another search.
If I search for Chris de Burgh I get 60+ hits. If I search for Chris deBurgh I get one hit (the correct one).
I am not sure what’s wrong with giving correct results? The de burgh search finds more results simply because of the fact that those results match the terms. The correct result is still number 1 either way.
The de Burgh search appears to return any name which includes a portion of my search string - unless I enclose it in double inverted commas. That’s probably what it is programmed to do. I have no problem with that.
What I found strange was that it gave me just the correct name when I searched for what was in effect an incorrect name.
My local tax bill hasn’t been paid for years. They keep sending the tax bill to the wrong person. A simple misspelling of my name voids my obligation to pay them. Correct address. Phonetically acceptable version of my name. But it is spelled wrong.
Correct results are awesome.
But a simple spelling discrepancy between de burgh and deburgh shouldn’t be excluding other spelling discrepancies.
Think about it; if I search the spelling included on a news article, and I get no results. My first instinct is not to try other spellings since I am reading a news article that has that spelling. I am going to add a new artist entry.
But, if I got a list of results that are not exact, but are at least close, my first instinct is to open them to see if there could be a misspelling - especially if some of the other information is filled in (disambiguation, dates, places, etc).
In my ideal world, at Big Rock Candy Mountain, I can set a sliding level switch anywhere from “exact search term” to “very very fuzzy search term” and have the results morph in front of my eyes.
In relation to MB Release
In a search of Releases for Jérusalem:
ONE
The new search and the old search both return Releases by Artists named Jerusalem higher in results than Release titles that contain Jérusalem.
See:
https://musicbrainz.org/search?method=indexed&page=6&query=Jérusalem&type=release
&
https://musicbrainz.org/search?method=indexed&page=7&query=Jérusalem&type=release
Do others expect, in a search of Releases, to have all Release titles that contain Jérusalem to appear before Releases that do not contain Jérusalem in the Release title?
Current and old search both appear to be over-weighting appearance of this search term, or a variant of it, in an irrelevant field.
TWO
Current search is returning Releases with Jerusalem in title before Releases with Jérusalem in title.
See
https://musicbrainz.org/search?query=Jérusalem&type=release&limit=25&method=indexed
Search appears to be placing results that match on number of words in Release title higher than results that match spelling (diacritical marks) of Release title.
Is this desired behaviour?
Which is what I eluded to a few posts earlier.
New search is far nicer than the old search which gave hundreds of unrelated results. But there should be a way to loosen how tight the results are.
Instead of 1 exact result with the new search or 100 unrelated results with the old search, maybe 10 results is better - a combination of the 1 exact match and 9 possible matches.
I had some cases where I entered an artist search (from relationship editor) with typos or switched some letters… and get no results at all.
Or for some longer names (with 3 or more parts) I only got a result when nearly the whole name was typed in. Even when it was unique previously.