I’m deveIoping a “Classical Workparts” plugin for Picard, which gets the “parent” works for a given recording by using XML lookups. I seem to be getting a lot of these “unavailable” responses in the last few days when doing these XML lookups via Picard. About 10% of the time. Until recently I was having no such problems. If I do a “refresh” it will sometimes pick up the missing data and sometimes just hang and I have to terminate the app. Any ideas what might be causing this and what to do about it? Also, any way I can find out what is causing the app to stop responding?
Have you implemented code in plugin to ensure you don’t hit the MusicBrainz request rate limit. The problem with MuisicBrainz apis is you cannot get the hierachy of works linked to a recording as part of getting a recording so it becomes very expensive to get this type of infomation in a timely way.
Picard automatically builds in a 1 second delay. I can see that happening correctly in the log.
Sort of fixed by adding a re-try loop (with a max number of re-tries). But if I can understand how to avoid/minimise the problem, that would be better.
Can you give an example request you are making? Other than that this is likely the MB server having issues, I also had some of those Service Temporarely Unavailable messages today while tagging some files. Someone from the server team can probably tell more.
return album.tagger.xmlws.get(host, port, path,
partial(self.work_process, part_level, workId, tries),
xml=True, priority=True, important=False,
queryargs=queryargs)
I meant the URL for the request
Aw. I thought you were just checking that I was using the XMLwebservice.
The URLs causing errors were many and various.
This is a great album for testing purposes: https://musicbrainz.org/release/ec519fde-94ee-4812-9717-659d91be11d4?tport=8001
Yesterday it was resulting in numerous lookup errors, but for different lookups each time. I added a re-try loop (max 6 lookups) and most of the works were found eventually - only one exceeded the max. I ran it again this morning and there were no errors at all. In fact I haven’t received any error messages at all today, so maybe it was a temporary server issue.
The plugin (development version) can be found at https://github.com/MetaTunes/picard-plugins/tree/master/plugins/classical_workparts
I am still getting the problem with Picard hanging sometimes (last debug line = “WSREQ: Last request to (u’musicbrainz.org’, 80) was 1001 ms ago, starting another one”). It may be that this is a problem with the plugin, but it only happens on certain releases - usually towards the end of the album lookups. This one - https://musicbrainz.org/release/ea2c0ebb-fa18-46ed-9414-e1c9e208d1b8 - just caused a hang like that.
This one, which I entered a few days ago and was fine at first, - https://musicbrainz.org/release/e875beb2-32fe-4bd2-90a7-bf495c136a34 - was causing multiple errors yesterday but none today. However, it is still hanging as described above.
Errors occurring again this evening, for example:
E: 19:22:39 Network request error for http://musicbrainz.org:80/ws/2/work/009b2276-f259-3f13-9112-7f1df8e6962a?inc=work-rels: Error downloading http://musicbrainz.org:80/ws/2/work/009b2276-f259-3f13-9112-7f1df8e6962a?inc=work-rels - server replied: Service Temporarily Unavailable (QT code 301, HTTP code 200)
I’m not sure how much it helps, but we do have a ticket about HTTP code 200 being logged on some Service Temporary Unavailable responses: https://tickets.metabrainz.org/browse/PICARD-809
The re-try loop seems to cater for 99% of situations. I think I found the cause of the “hanging”. I have a recursive call in my code which works fine in Python, but not always in Picard. If I limit the recursion depth to 16 then it seems to work. (BTW it is not infinitely recursive and limiting the depth to a greater number, say 32, seems not to work). Curious.