Taken from PICARD-744 and an email exchange (so apologies for it being disjointed):
I have been tagging files saved on a network share - both computers running Windows 10 64-bit.
Network performance is pitifully slow. Both reading and writing. But network utilisation is not excessively high - about 250KB/s read when reading (wifi is 54Mbs) and 80KB/s read / 25KB/s write when writing.
I had to reset my connection and suddenly it burst into life again - at least 100 times faster, So it appears to get slower over time.
I wonder if it is a problem with handles because I can’t find any code in mutagen that closes files after the tags have been read.
I should add that all file activities on the same share go slowly. Restarting Picard does not make it go faster - it needs to be a reset of the wireless adapter.
It is unclear to me whether this is an issue with Windows, triggered by perfectly good code in Picard / Mutagen, or an issue with Mutagen or with Picard.
One theory I have is that Mutagen is not closing files properly after reading / writing – and indeed I cannot find the use of the python close function anywhere in mutagen.
I have a feeling that Windows does some fancy read-ahead / caching for files across a network which it doesn’t do when they are on a local drive, so not closing files might cause this issue – but Windows should clean up if you terminate Picard but closing Picard doesn’t make it spring back to life.
When you load Picard afresh, it uses 657 handles – I know that sounds like a lot but it includes every Python DLL and every other file used to run the application and it doesn’t look untypical.
When I add an album, the count goes up by one as it reads the existing metadata from the file. Having done a couple of albums and deleted them from Picard it went up to 860. Having done several 100 albums it was as high as 3800.
I am posting this here in the hope that someone has the skills and time to look into whether this is a Picard or Mutagen problem and if so to fix it.