Please test new Picard Windows builds

Tags: #<Tag:0x00007f11cafcf318> #<Tag:0x00007f11cafcf098> #<Tag:0x00007f11cafcef58>


Testing feedback - Positive note

That is a HUGE improvement as to how artwork is handled. I’m a greedy ID-10T who downloads all available art. I don’t embed, just drop loose files.

In v1.4.2 Picard would often choke and stall on large artwork downloads. In v2.0.5dev1 it was comically fast.

Here is an evil one to test with. This includes 288MB of artwork! Heaps of unedited 25MB PNG files! The old v1.4.2 just gave up on this after seeing the first 25MB file. I left it running overnight and nothing… but 2.0.5 worked well.

Testing feedback - Bug Found

In my options I have the option ticked to “Preserve timestamps of tagged files”. I just tagged a group of FLAC files and found that all the time stamps have been changed.

Testing deeper and I find when the files are on the same Win10 PC as Picard then the timestamps are preserved. When the files are on a Win7 PC being accessed over the network via SMB then the file stamps are not preserved.

Yuk - just tested back on v1.4.2 and it turns out that was also knackering time stamps when working over the network. So this bug is not new.


Thanks for testing

I reopened PICARD-1110 for this and gave this another test. See my last comment there, it seems to be a nasty issue :frowning:


Just to confirm - all my tests are Windows to Windows. Tested the same with Win10 to Win7 and Win7 to Win7. All patched, legal, Pro editions. Files sitting on a simple Win7 Pro PC shared over SMB Workgroup using username\password control.

I noticed you said your tests are with “windows guests”. In the above scenarios the Desktop users have login to the PC with a username and password. Then a DIFFERENT username and password is used when connecting the the SMB share via the network.

Funny to see the timing issue mentioned. Doesn’t surprise me as I’ve been working with SMB since the Windows for Workgroup days and it has always been a bit of a loonatic.

Happy to test for anything specific as\when required.

(Quick check with MP3TAG and that behaves itself and timestamps stay as expected)

Not as if this is massively urgent as no one noticed before :smiley:


That was supposed to read “windows clients”. That has nothing to do with you user account.


Ah - okay. I threw in my extra notes there as I know some people only use SMB in guest mode without passwords. (Which brings other issues)


True. SMB issues are difficult, because you have so many variations with different protocol versions and also the alternative Samba implementation. I kind of had hoped this issue is related to rather old systems. But since this is easily reproducible between Windows 10 systems that’s unfortunately not the case.