View Issue Details

IDProjectCategoryView StatusLast Update
0018368MMW 5Main Panelpublic2021-12-18 01:41
Reporterlowlander Assigned To 
Status closedResolutionreopened 
Product Version5.0.2 
Target Version5.0.2Fixed in Version5.0.2 
Summary0018368: Choose alternate should clarify it's on Wikipedia --> MusicBrainz updates fail to propagate quickly
DescriptionWhen viewing Artist info you can use Choose alternate in case the match is wrong. It's unclear to user that this is only on Wikipedia, not also on MusicBrainz. This exacerbated by having Edit in MusicBrainz in the same menu.
Steps To Reproduce1 Click 3 dot menu in Artist info panel in the Filelisting
2 Choose Choose alternate (Artist)
--> There is no feedback that this is only done on Wikipedia
Additional Information
TagsNo tags attached.
Fixed in build2515


related to 0018446 closedmichal Info panel: Improve 'Choose alternate' presentation to clarify associated actions 



2021-10-01 09:37

developer   ~0064926

Last edited: 2021-10-01 10:26

But Alternate artist IS from MusicBrainz (our copy of MusicBrainz data). New MusicBrainz record then has different associated Wiki page, so also new Wiki info is read.


2021-10-01 14:29

developer   ~0064935

In this case the Artist the user created in MusicBrainz is not shown as option. So if alternate looks on MusicBrainz there is an issue with finding the new Artist. So either way there is a problem as MM shows the wrong Artist info and has no way of correcting this.

1 Have a file with Artist Bone Pixie
2 Use Alternate Artist
--> Expect Bone Pixie:, but it isn't shown.


2021-10-01 14:39

developer   ~0064936

This artist already works, I can see the artist there.
We use our copy of MusicBrainz DB, which is synchronized regularly with the "official" one. When user inserts new artists to their DB, it cannot be shown immediately, it takes some time (hour(s)). But I probably can improve the time, requests are currently cached, so the result is returned from local cache even though new data are already on the server.


2021-10-01 14:56

developer   ~0064937

Cache timeout changed to 1 hour in build 2507. So every change on MusicBrainz server could be shown on our side within two hours. It cannot be much faster, it could significantly increase our MB server load otherwise.


2021-10-01 15:10

developer   ~0064938

Followed clear URL cache suggestion, but Bone Pixie is not found as alternate Artist.

1 Run Clear URL cache
2 Go to Artist page and show Info Panel
3 Click 3 dots > Choose Alternate (artist)
--> Expect Bone Pixie, but it's not shown


2021-10-01 15:19

developer   ~0064939

Last edited: 2021-10-01 15:48

It seems to be problem with indexing in our MB DB (I can see the artist there when searching by global search - Online, but it is not in other search results like alternate artists), assigned to Petr to solve on MB DB side.


2021-10-19 02:25

administrator   ~0065306

Last edited: 2021-10-19 02:30

We should probably also document this in the online help i.e. that both the MusicBrainz and Wikipedia entries need to be updated to have an effect.

Note: I raised the priority for Petr to triage. Users generally expect that if they make the edit that MM will reflect it immediately--I wonder whether in such cases a direct lookup would make sense.


2021-10-22 16:02

developer   ~0065441

Last edited: 2021-10-22 16:05

Updates made in are replicated to slave databases within hour after acceptance ... problem is with searching as they have 'search indexes live update' as experimental feature and manual search index recreate can take up to 12 hours so we cannot make it too often. About lookups requests directly to ... how we can detect our server is receiving wrong/old results and we need to place query to ? I understand user can be confused about that, but i do not see how to improve that. I can plan search indexes update once a week or once a month (keep in mind this update can take many hours), but it's not possible to make it once a day.


2021-11-04 06:12

developer   ~0065707

MB server reindex issue fixed.


2021-12-18 01:41

developer   ~0066410

Verified 2528

I have not seen this issue for past few version.