|
Sort Order:
The behaviour certainly seems the same, at least in that those particular requests take a good while before the server decides to return the error. It takes maybe 10 - 15 minutes for Picard to finally finish [could not load foo-foo-foo-foo]-ing all of the above. Oddly, as I said, if you take out any bits of the request, chosen at random, the request works: http://musicbrainz.org/ws/2/release/f5378fe3-f999-4357-9c3f-6cb0ca0c8bbd?inc=work-level-rels Side note: mentioned in MBS-3122 is the size of the returned data... all those repeated aliases for Bach really seems redundant and bloaty. I guess the secondary artist data couldn't be moved out to a second single top-level <artist> at the <release> level, and cut all those out? More of these problematic ones: Another release that won't load in Picard: musicbrainz.org/release/9c5c043e-bc69-4edb-81a4-1aaf9c81e6dc I think the easiest way to fix this in a general sense will be to change the way work-level-rels works; to not return links back to other recordings (or at least provide this as an option). I'd planned to spend some time thinking about it in more detail to propose a solution for Picard's purposes, but haven't really got around to it See my comments on this on the mailing list at http://lists.musicbrainz.org/pipermail/musicbrainz-devel/2011-November/004579.html I'm away for a few weeks and have not had time to log separate related tickets on actions that we can perform to mitigate this. Only short-term workaround is to turn off track relationships in Picard. Seems to be the same kind of problem as MBS-3841? Faster XML serialization is in review at http://codereview.musicbrainz.org/r/1755/ All URLS from the description respond with a 200 now. They still take up to a minute to fully produce a response, but they don't time out. I just tried one of the urls in the list and I got a 502 Confirmed that if you remove work-level-rels it works I think there are a number of things we could consider: I personally think 1 is the only really viable option right now. I'm curious about 2 for sure, but that'll need some more thought. 3 and 4 break the web service as far as I'm concerned, and I would only like to look at them as a very last resort. Note that there's another optimization in review atm, which might help this: http://codereview.musicbrainz.org/r/1738/ The thing about work-level-incs is that they were added later maybe without considering the effect they had so it wouldn't be unreasonable to take another look at them and not remove them but trim the extra information they output, in a earlier comment voiceinsideyou seems to be coming to the same conclusion, and I always consider voice to be be the voice of the people. The last optimization you mention isn't going to have much impact, we need a solution that deals with the queries that return drastically more information then the norm rathert tahn just shaving some time of all queries (although of course that is also welcome) We're blocked on this again, so I'm moving it back to decision required to get it out of my work queue. It's scheduled for discussion in todays agenda. It seems I have the same problem. I use picard 1.1 on Linux Fedora 17. It constantly fails to load Error (from log) is: E: 139665277085504 00:23:29 u'Error downloading http://musicbrainz.org:80/ws/2/release/c2d8a8cd-5843-4298-8794-cfed0ccf0433?inc=release-groups+media+recordings+puids+artist-credits+artists+aliases+labels+isrcs+artist-rels+release-rels+url-rels+recording-rels+work-rels+recording-level-rels+work-level-rels+tags If I try to load the specified URL in browser, I have the same error. If I shorten the list of requested information, for example: http://musicbrainz.org:80/ws/2/release/c2d8a8cd-5843-4298-8794-cfed0ccf0433?inc=release-groups+media I have successful reply from the server. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Bug
Decision Required
Normal
Error 502 Bad Gateway loading certain releases from the webservice
My guess is that this might be related to some of the issues I raised in MBS-3122 (which unfortunately is not very actionable in current state); in particular work-level ARs going back to OTHER recordings than the ones on the release.
My guess is that if you remove work-level-rels from those; they will probably all work.