I am using Picard 2.3.1 on pre-release Ubuntu 20.04.
I don’t know which is at fault but when I push the save button Picard completely locks up
having to force shutdown of picard.
I am sending this info to the folks at ubuntu as well.
If you save a lot of files at once this actually can happen, as there is some preprocessing currently done before the actual saving happens which unfortunately blocks the UI. Just give it a minute or two and it should start saving and become responsive again (it will be a bit laggy during saving, though).
If this also happens if you only save a single file and does not recover from this please open an issue on https://tickets.metabrainz.org/browse/PICARD
1 Like
Should we consider putting some kind of message in the status line (and force a refresh before beginning the processing) that the program is processing and could take a few moments, and to please be patient?
1 Like
I remember the days of the Wait Cursor. I’ve picked up on this one before as it really shows up a lot on bigger boxsets. It is important to let the user know something is happening. Especially when working on large collection of files on a slow PC. You often see new users complaining about “Not Responding” messages which are just a requirement of patience.
The actual goal is to remove the UI blocking at all.
What are the days of the Wait Cursor?
That’s even better than my suggestion, which only addressed a symptom and not the real issue. I remember now that you’ve been looking into this for a while. Thanks.
I think he means when an application changes the cursor to a clock or hourglass to indicate that it is doing something. Unfortunately, sometimes the program would “hang” (stop processing or responding) while still displaying the clock cursor, which led the user to think that the program was still working when, in fact, it was not. Again, addressing a symptom rather than the problem.
1 Like
Yes. Exactly. Feedback on screen when the application is busy.
The trouble is this describes Picard now. It is easy to “catch it out” and confuse the processing queues. Big boxsets cause problems for Picard. And the user can make that problem much worse if they do not know it is processing in the background and move data around because they assume Picard has finished with it.
Obviously the ideal is to make sure that Picard never has faults and never has UI blocking - but currently we have a program that is easy to confuse with impatience and the lack of feedback makes this worse.
Almost certainly the OP just had a slower PC re-writing FLAC files slowly. They could not see that this was taking a long time. So they crash the program out instead. It is very likely if they walked away for 10 minutes then all would have been fine. I have seen this happen many times on the slower PC I process a lot of my audio files on. Now I know to just walk away and leave it alone…
I forgot to mention I am running this in Virtualbox just for testing. That Could be an issue.
It has never been a problem before but seems pulling files from windows is the problem.
I downloaded some new files and its working.
Maybe all will be better when 20.04 final gets installed to hard drive.