I’ve found Picard(1.3.2) will freeze when saving (and moving) .flac files. I can’t narrow down what are the causes, but 60% of flac files will freeze the UI. It
I’m not sure if this is a bug yet, where can I check logs related to this? I’ve fiddled with the settings of not removing tags in flac, changing tag versions. and even embedding images, but no consistent cause can I see.
Does it un-freeze when its done saving?
I’ve personally run ~5700 FLAC files through Picard, some of the multiple times, and have never had it freeze (other than maybe briefly when actually writing a file—not actually sure, as I don’t try to do anything with Picard while it’s saving). Though I don’t have it move my files. (And I’m on Linux, which I’d guess—just from the small market share—you’re not).
Not saying it doesn’t happen to you, of course, but it’s got to be something that only affects a subset of users.
Saving large files, especially to slow storage locations, can indeed freeze the UI sometimes. I am not sure why, it does not really make sense to me since saving happens in a separate thread. I think there is a bug report for this, but I can’t search for it right now.
I am personally experiencing this often when saving FLACs to a NTFS drive under Linux.
Thanks for replying guys,
It does come back after hanging, it seems to hang on particular albums, but always FLAC files.
I am also running it from a external NTFS drive under Linux, so perhaps a EXT4 format would be better? I only have one drive that size though, so will need to find smaller drives if I’m going to move music off to re-format to ETX4.
@derobert If I may ask how is your system setup? And what settings do you have for the tags and album art?
Hah yee of little faith 
Has anyone compared running NTFS under windows with the same load. Would it run better on windows if the file system is NTFS perhaps?
I’ve noticed this on both platforms. It seems that the UI becomes laggy when there is a lot of data to write: For example, when saving many files at once, or when embedding cover art in several large files.
Does the lag only affect Picard, or your whole system? Writing files to NTFS over USB 2.0 on Linux can cause high CPU utilization.
My FLAC files are stored on ext4, on a RAID10 array of 3xSATA HDDs. So quite a bit faster than your external drive. System is an i7 with 16GiB of RAM (so even several-disc albums fit entirely in disk cache). I put all the cover art, at full/original size, in each file (so adding art can easily double the size of the album).
So, I’d guess that’s why you’re seeing freezes and I’m not. Plus I’d not really think of Picard not responding the input while obviously writing a file as freezing.
[They’re then checked in to a git-annex repository, and sync’d across several machines and backed up to Amazon Cloud Drive]
Side note:[quote=“paulka007, post:4, topic:140217”]
I am also running it from a external NTFS drive under Linux, so perhaps a EXT4 format would be better? I only have one drive that size though, so will need to find smaller drives if I’m going to move music off to re-format to ETX4.
[/quote]
Well, you already should have a second drive, as a backup!
But anyway, if you can resize the NTFS partition, you could set up LVM in the now-free space, and put ext4 on that. Then copy the files, and then add the NTFS partition to the LVM setup. Then grow the ext4 partition to use the full disk. If you have less than 50% free, you could do this in several steps (shrinking the NTFS and adding another partition each time), but it starts getting more and more ridiculous. Note that the downside is that only Linux will be able to read this.
And of course you should have a backup before trying that.
Even if the performance is the same, ext4 (or btrfs) would give you nice things like longer file names and broader character support.
Just popping in to say I AM SORRY for the size of album art that I upload!
I didn’t think anyone would do this!
…carry on 
Disk is fairly cheap… as long as you’re not uploading uncompressed BMP files or something…
Eventually, I hope to get btrfs to properly deduplicate it, too. (Right now the ioctl doesn’t want to split extents, which makes it not deduplicate)
Even worse is that I keep old versions of the files. So I’ve got at least two copies of everything—the original from the ripper, then the version after running through Picard. Some I have three or four copies of, from retagging.
'[quote=“derobert, post:6, topic:140217”]
a RAID10 array of 3xSATA HDDs. So quite a bit faster than your external drive.
[/quote]
I think that’s the problem, Also running i7 with 16Gb RAM, but a much slower USB2.0 external drive. Funny thing is when picard freezes my disk read writes numbers are still pretty low, and I can continue to browse with a file manager, which made me think it wasn’t simply a speed thing.
Thanks, good to know. Everything else is fine, just picard. CPU also drops actually when saving, It sits at 25-30% when scanning and looking up, but >10% when saving.
What paulka007 describes is in line with my own experiences. I once tried to debug this but without results 
Maybe somebody with more experience in the multithreading implementation could find something, but that’s actually a part of Picard I have not really touched myself.
Which kernel version? mmap over fuse/ntfs was broken between 4.2-4.5
-4.2.6-040206-generic-
Upgraded to 4.7.5 will let you know what happens, but everything does seem alot more responsive!
(That kernel was a security risk anyway 
…unsupported for the last 10 months)
Thanks, getting write speeds of 10-20MB/s much better than before!
Anything else I might upgrade?