Yes, I downgraded it. This has been flagged as high for years, but without any reports on this elsewhere, me not able to reproduce and nobody working on it. Not what I would call high priority really.

Downgraded to "Normal" priority, eh. Is this still an issue with the latest build of Picard? I haven't tried something like this again since.

It could be worth to try with memray. It can apparently catch c++ allocations too, so even Qt leaks could get caught.

https://bloomberg.github.io/memray/getting_started.html

I just had this happen to me while I was about to tag about 1000 albums, causing Picard to crash and lose a bunch of progress. Lesson learned I guess, hit Ctrl-S more often and do smaller batches. 16gb RAM.

Sorry, wrong issue

Duplicate of PICARD-2370

With the normal 2.6 build, constantly selecting and deselecting 8000 files/2000 albums only makes memory go up by 7MB every time, on my machine. It does go down occassionally but only by a little and above the starting memory

I only tested this with unmatched files so far, by loading the files with "Ignore existing MBIDs" activated. That way loading goes reasonable fast, but of course only tests a specific case.

is there a way to test this without waiting for 1000s of albums to load from MB?

Here it consistently went up and up, starting from 946MB and all the way up to 1.2GB. Tested on Ubuntu 20.04.2, Python 3.8.5, PyQt 5.15.2, Qt 5.15.2.

I can't really reproduce this here (Linux, Python 3.8.6, PyQt 5.15.0, Qt 5.14.2). Yes, memory usage can go up a few MB when selecting / deselecting files, but not continuously and only so much until it stops at some point. For me with 4k loaded files at around 500 MB. Removing files, adding different files again, changing selection does not increase this more. So at least on my system this doesn't look like a leak.

You tested on Windows?

Philipp, I believe there is a leak somewhere. I loaded 18k files and every time I select all of them, the memory goes up by ~10MB and doesn't go down when unselected. The difference isn't big enough to notice when trying with a few files. Not sure if its on the Qt side or the python though.

Thanks a lot. That matches the current expectations after this patch. I think with this we can at least consider the skyrocketing of memory usage as fixed.

> I'm not sure the %_recording_firstreleasedate% variable works correctly in this build though? I copied the script from my Picard install (same one from the patch notes) and sometimes it works correctly and sometimes it will only set the year of the first release date.

Thanks for nothing. There was no change I am aware of that should have an impact here. But I will double check and do some tests.

With that build at worst it takes less than a minute (10-30 seconds-ish). Memory usage is not as bad either, I haven't seen it go above 1GB. I'm not sure the %_recording_firstreleasedate% variable works correctly in this build though? I copied the script from my Picard install (same one from the patch notes) and sometimes it works correctly and sometimes it will only set the year of the first release date.

I'm loading roughly 8800 files, 400 that can still be looked up. There's about 2600 albums

Could you test the portable build at https://s3.eu-central-1.amazonaws.com/artifacts.picard.uploadedlobster.com/MusicBrainz-Picard-2.6.1.dev1%2B25.0142b9e0.20210402134252.exe how this behaves for you? Does it solve the issue?

In any case it should be way faster. Not super fast, but it should make a huge difference and it should finish in a reasonable time. If this works for you it would also interest me how long this now ran. The hope is it is in the range of seconds, but definitely not hours

Also mostly out of interest: How many files (roughly) did you have loaded when doing this?

This probably will be resolved by the fix for PICARD-2166