Hello,
When I scan an album with 10-15 songs, Picard closes 95% of the attempts.
If I scan the songs two by two, it works fine. But if I scan three by three or more, Picard closes.
The last lines of the debug mode do not show anything relevant:
I’ve tried on two computers with Windows 10 x64 and Picard 2.8.5
D: 01:00:58,871 webservice\ratecontrol._out_of_backoff:222: (‘acousticbrainz.org’, 80): oobackoff; delay: 500ms → 250ms; slow start; window size 2.000 → 3.000
D: 01:00:58,872 webservice\ratecontrol.get_delay_to_next_request:121: (‘acousticbrainz.org’, 443): Last request was 734 ms ago, waiting 1266 ms before starting another one
D: 01:00:58,872 webservice\ratecontrol.get_delay_to_next_request:121: (‘api.acoustid.org’, 443): Last request was 54 ms ago, waiting 279 ms before starting another one
Maybe something related to “ratelimit”?
If I follow a request from the log with my browser the response was:
“{“message”:“You have exceeded your rate limit. See the X-RateLimit-* response headers for more information on your current rate limit.”}”
Before ten seconds I refreshed and the API got me the data.
Picard has a rate delay mechanism - what the log messages are indicating is perfectly normal and NOT a reason for Picard to close. The delay for standard web sites is built into
Try launching Picard from a command prompt with the -d flag and see what messages are shown when it closes.
If the logs don’t show more info this will be hard to debug unless one can reproduce (which I can’t). @Genosystem Was the above log output captured from a command prompt? If not there is a chance that we’ll see more details if you start Picard from a command prompt with
Thanks for the details. Unfortunately getting to the root cause will be difficult in this case. The application so suddenly closing without any Python stacktrace showing might indicate some memory access issue. Things like that can sometimes be threading related (if parts of the code are not fully thread safe) or it could even be a bug higher up in Qt.
That this issue happens not always for you and that I can’t reproduce it at all is actually a strong indication that the issue is somehow related to threading. Issues like this often depend on the timing, which means it all is very system dependent.
I recently found some threading issues in regards to metadata updates and started working on a patch. Hard to say whether this is relevant here, though.
Also in the current development version there is a feature that allows the user to configure the number of parallel AcoustID fingerprinting operations. It would be interesting to see whether you still experience the issue when limiting the number of parallel fpcalc calls to 1. Currently up to 2 parallel fingerprining operations can happen. We want to put out a new beta release out soon, but no fixed date yet.
I wonder if it could have something to do with scanning the files on a network drive? @Genosystem do you still get the crashes if you copy the files to your local hard drive and process from there?
No, it’s a local HDD, but I’ve tried copying to an SSD and the bug still exists.
Thanks @outsidecontext, maybe something I install in both systems affects picard. When you release the version with configurable parallel threads, I will test it.
I sent you a PM with links to the alpha builds of Picard with the option of selecting the maximum number of threads to use when doing the fingerprinting, and you responded via PM with the results of your testing. Thanks for that.
For the record (and further discussion if necessary), would you mind posting your results here as well? Thanks.
Sure!
First, I tried the alpha version twice without changing the parameter, and it closed as usual.
But when I changed the parallel parameter to 1, it worked ten times in a folder with 71 songs.
Later, I did a test with a folder of 215 songs and no problems.
It seems that the problem was parallelism as we suspected.
Thanks a lot to both of you for getting the details and confirmation. This narrows it down and also provides some workaround. I added a ticket to track this:
I’ll look into it as soon as I have some time, but can’t promise anything right now. Issues like this are very tricky to track down. I have tried, but so far couldn’t reproduce a single crash on my systems. That doesn’t say much, though. If things are timing related even small changes sometimes completely change the behavior on a specific system. I have had cases where a similar issue was no longer reproducible after adding just a single line of debug output.
I am facing the same issue. I have disabled “fingerprinting”, but no change. Still randomly exits during scan. Only happens when scanning large number of files. 1,000+ crashes Picard without error message given. Thoughts appreciated!
