View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0018368 | MMW 5 | Main Panel | public | 2021-09-30 20:57 | 2021-12-18 01:41 |
| Reporter | lowlander | Assigned To | |||
| Priority | urgent | Severity | major | Reproducibility | always |
| Status | closed | Resolution | reopened | ||
| Product Version | 5.0.2 | ||||
| Target Version | 5.0.2 | Fixed in Version | 5.0.2 | ||
| Summary | 0018368: Choose alternate should clarify it's on Wikipedia --> MusicBrainz updates fail to propagate quickly | ||||
| Description | When 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 Reproduce | 1 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 | https://www.mediamonkey.com/forum/viewtopic.php?f=33&t=100188 | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 2515 | ||||
|
|
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. |
|
|
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: https://musicbrainz.org/artist/2c452ec6-fb85-49e2-9965-06ab271caebc, but it isn't shown. |
|
|
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. |
|
|
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. |
|
|
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 |
|
|
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. |
|
|
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. |
|
|
Updates made in MM.org 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 MM.org ... how we can detect our server is receiving wrong/old results and we need to place query to MM.org ? 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. |
|
|
MB server reindex issue fixed. |
|
|
Verified 2528 I have not seen this issue for past few version. |
