I am not addressing the developers today, but the people who manage the software development.
ERROR MESSAGE: The new version keeps freezing.
But that is not the problem, but the fact that with every version of Picard the problem becomes more and more severe.
I can’t see a plan, it just kind of responds to bugs, but the problems get bigger instead of smaller.
I would like to report bugs to you, but if the program turns completely gray and nothing works, what should I report great. It doesn’t work. It may not be that you need 4 GB of RAM to tag a file.
I am not able to tell you why it freezes, it simply freezes, the user can’t do nothing.
I don’t know if timeouts are too long or what exactly is going on because the program gives absolutely no feedback. it should bring more feedback so that even the DAU user can see where the problem is.
That is not the job of the programmers. that is a management problem.
Not trying to pour salt into wounds, and you may have a point, but Microsoft ended mainstream support for Windows 7 in 2015.
Can you name the last specific Picard version that you used that had no such issues for you?
It might be helpful to give the developers some clue what is causing this for you.
And if it is indeed related to using Win7, perhaps the listing of minimum requirements for Picard should be changed and explicitly exclude Win7.
P.S.
Hm, strange, I just did a search for Picard minimum requirements, and couldn’t find anything to begin with.
Not on the main download page, nor in the F.A.Q.
How many tracks is Picard working on? One album? Or a Thousand random tracks?
The “not responding” situation you are seeing is really Windows saying “Hang on mate, I am really really busy here”. Next time it does that to you just walk away for 20 mins. 30mins. Maybe longer if you have loaded up thousands of tracks.
Some things make Picard work really really hard. If you have lots of FLAC files that need headers re-written. Or if you are downloading a lot of high quality artwork. Or just trying to tag more than 50 tracks in one go. Or tagging onto a network drive.
I trigger this issue because I like to download all artwork for my releases. And that can sometimes mean 20 mins of downloading images for just one release as 30 or more 60MB PNG files download of a glossy booklet.
I agree with you that better feedback is needed. People are getting bored of me bringing up the same point I think. I want the GUI to tell me that it is working. The devs want to make a perfect program that never bogs down. Even a counter in the status bar showing “track xx of yy is being updated” would help so so much for us with these slower computers.
Note: you can confirm that “windows going grey” is caused by being busy by going to look at the folder of tracks being tagged. You will see the file dates are changing while the GUI is locked up busy. The “grey out” is not a crash, it is a windows feature.
I think (and hope) your enthusiasm and willingness to speak out should trump any feeling of annoyance
(and it looks like it does)
Back to the matter at hand: while you might raise a good point, the OP specifically states that all was good, but things are getting worse with newer releases.
So assuming that the OP didn’t change his regular mode of operation, this would not be related to retrieving album art or something like that?
If I shout and annoy people enough eventually a penny will drop. I used to be a dev. I know what it is like working on a fast PC with small datasets. And then someone comes along and uses a slow PC with a HUGE dataset that isn’t expected. Many people do this - and it works because Picard is so well written that it handles the unexpected.
I have demonstrated this a number of times with examples of this and related issues. It hits me often as I keep working on big boxsets.
Don’t bash Win7 - that will be a distraction here. Lets get the OP’s dataset. How big a number of files. Or what is special about those files to trigger this. I can trigger this in many ways which is why I wanted to reassure him that it is not only him.
That is not what I said. I have learnt how to change how I hand data to Picard. So I only do one album at a time. That means the “bogging down” issue is harder to spot.
Your question is misleading. And I will not be drawn in to the fight you want.
I don’t think the OP was complaining about “speed”, but that some datasets will cause Windows to go into its “Not Responding” mode which happens when the app is working very hard.
I notice it due to big boxsets. Especially ones with FLAC headers that need re-writing. And I notice it when higher quality art appears. And in the last year there is a lot of higher quality art being added, so that issue appears more. I am not going to repeat the stuff I have said before as people are getting bored of that.
I’m not in any fighting mood whatsoever.
I am only reading and referencing the initial post, where the OP states that older versions worked fine for him, and newer versions are getting worse and worse.
I am not saying your issues are invalid at all, but I am not sure they are 100% related to what the OP is saying here.
Anyway, I am outta here, I don’t think I’ve more useful things to contribute on this matter.
I use it on Windows 7 here and experience none of these problems. Then again, I tag one album at a time and the files are both read and stored by Picard on a local hard drive. All transfer of files to and from my NAS devices are done outside of Picard.
It freezes even with one single track. but for a short time.
I can see the notice: (not responding) on the top of the window.
What I am doing to be able to work on the computer while tagging is I set the affinity to only one processor core from 4, and I set the priority to “Background”. Then is is much slower, but it does not freeze any more.
And: certainly I want to submit huge folders to Picard without it freezing.
Yes that’s true with one album at one time it is not freezing very long, so it is a border case. But if you submit a folder with 35 albums its freezing forever.
it should not freeze at all. it should not use all resources that the computer can give. it should be somehow limited.
Nope it’s not. It is about software possibly having dependencies on versions of operating systems.
Picard will not run on Windows 3.11 (truth be told, I am guessing here)
Nor will it run on a $10 billion quantum computer.
In your opening post you stated that older versions worked fine, but more recent versions gotten worse and worse.
If you want to help developers narrowing down a possible cause, you should provide details about what version of Picard worked well for you, what versions degraded, and give some useful and factual details about the degradation.
I agree that it gave it huge loads…
But man, it picard, it is the king, he should manage huge loads…
I wished the GUI does not freeze while it is working. it should not use all resources for the job. or simply have a separate process for the GUI.
I am no windows developer, but I can remember when I was programing C++ that one must kill the objects when the objects are not needed any more else they fill up the stack and then you have a stack overflow. In my humble opinion this is happening right now.
You should not create new objects until you have not killed the old one. And create only a limited number, according to your stack.
I am willing to help you.
I use windows 7 full. And I use the last version of Picard.
I think you prolly want me to run it in a debugger, and supply you the symbols. Does it help you?
Sorry, I am useless for that. No coding talents here.
All I am doing here in this thread is learning if there actually is degradation in newer versions, and if there is, perhaps help bringing those to the surface so that the actual developers get an idea what they might do about it.
I for myself usually don’t load enormous amounts of albums in one run.
In my personal experience pretty much every new release of Picard has been an improvement on the previous one.
It might be good to try and split possible different issues here:
Has Picard gotten worse with new releases in the sense that in the past it handled huge loads without any problem at all, and recent versions don’t.
Picard has always had issues with huge loads, but something changed about how it handles that, and/or how it (doesn’t) inform users when there are problems with that.
Yes Ivan absolutely. I think Ivan has pointed the problem in a good way. I am not a English native, so it is difficult for me, but what i want to say is that even if I supply it one million files, it should take only as much it can handle without to freeze, and after kill all objects, clear the stack and then take the next files.
I want the GUI to tell me that it is working. The devs want to make a perfect program that never bogs down. Even a counter in the status bar showing “track xx of yy is being updated” would help so so much for us with these slower computers.