Picard 2.9 uses about 14% of the CPU at idle
also spotted by macularguide and now myself.
in my case it’s hanging around 14%-20% CPU usage after simply booting it up and not doing anything. for context, a screen shot moments after closing Picard
We posting CPU graphs? It is only grabbing 5% of my CPU at idle…
Agree that something is a bit up there… this is the v2.9 Portable install, first start of a fresh install, and doing nothing…
On exit it does immediately quit and release my CPU.
Meanwhile at the exact same time the previous v2.8 edition of Picard was running, nine albums loaded with a heap of artwork loaded… as expected at idle it is idling…
Something odd has occurred…
Whatever it is is very stable and locked to the same CPU usage in a consistent way. Look at how flat all the graphs are.
Can you all try if CPU usage goes down when launched with the
Makes no difference for me
For what it’s worth, 2.9 (and b2 and b3) have slightly lower usage than beta version 2.9b1, which lingered even higher, around 12.5% for me, while the others use around 9.5%.
2.8.5 is between 0% and 0.5% for me…
Tried to run the Stand Alone as a --single-instance and it crashed (Win10)
Traceback (most recent call last):
File “tagger.py”, line 17, in
File “tagger.py”, line 1440, in main
File “tagger.py”, line 1398, in process_picard_args
File “argparse.py”, line 1771, in parse_args
File “argparse.py”, line 2519, in error
File “argparse.py”, line 2489, in print_usage
File “argparse.py”, line 2500, in _print_message
AttributeError: ‘NoneType’ object has no attribute ‘write’
Remove parameter and it runs. Whatever v2.9 is doing it is pretty stable with it. Only a small variation - 4.9% to 5.3%. Mainly ticking at a constant 5.1% at idle.
Now make it do some work - thrown in nine albums, ask for all art… and that CPU figure is still rock solid and does not go up during that task.
--single-instance was probably a typo by outsidecontext and should be:
Okay… will swap to that instead and test. But app shouldn’t really crash for a bad arg, should ignore it.
–stand-alone-instance is still the same consistent 5.1% CPU
Meanwhile used --debug as a quick info check
D: 09:19:40,480 tagger.__init__:320: Starting Picard from 'D:\\Users\\ivan\\AppData\\Local\\Temp\\_MEI182482\\picard\\tagger.pyc' D: 09:19:40,481 tagger.__init__:321: Platform: Windows-10-10.0.19045-SP0 CPython 3.8.10 D: 09:19:40,481 tagger.__init__:323: Versions: Picard 2.9, Python 3.8.10, PyQt 5.15.9, Qt 5.15.2, Mutagen 1.46.0, Discid discid 1.2.0, libdiscid 0.6.3, astrcmp C, SSL OpenSSL 1.1.1b 26 Feb 2019 D: 09:19:40,481 tagger.__init__:324: Configuration file path: 'D:/Users/ivan/Downloads/AudioVisual/MusicBrainz-Picard/Config.ini' D: 09:19:40,481 tagger.__init__:326: User directory: 'D:\\Users\\ivan\\Downloads\\AudioVisual\\MusicBrainz-Picard' D: 09:19:40,481 tagger.__init__:327: System long path support: False D: 09:19:40,481 i18n.setup_gettext:146: UI languagD: system D: 09:19:40,481 i18n._log_lang_env_vars:131: Env vars: D: 09:19:40,481 i18n.setup_gettext:154: Trying locales: ['en_GB'] D: 09:19:40,490 i18n.setup_gettext:160: Set locale to: 'en_GB' D: 09:19:40,490 i18n.setup_gettext:171: Using localD: 'en_GB' D: 09:19:40,490 i18n._load_translation:118: Loading gettext translation for picard, localedir='D:\\Users\\ivan\\AppData\\Local\\Temp\\_MEI182482\\locale', language='en_GB' D: 09:19:40,491 i18n._load_translation:118: Loading gettext translation for picard-countries, localedir='D:\\Users\\ivan\\AppData\\Local\\Temp\\_MEI182482\\locale', language='en_GB' D: 09:19:40,492 i18n._load_translation:118: Loading gettext translation for picard-attributes, localedir='D:\\Users\\ivan\\AppData\\Local\\Temp\\_MEI182482\\locale', language='en_GB' D: 09:19:40,494 i18n.setup_gettext:189: _ = <bound method GNUTranslations.gettext of <gettext.GNUTranslations object at 0x000001DD34156820>> D: 09:19:40,494 i18n.setup_gettext:190: N_ = <function <lambda> at 0x000001DD3269B550> D: 09:19:40,494 i18n.setup_gettext:191: ngettext = <bound method GNUTranslations.ngettext of <gettext.GNUTranslations object at 0x000001DD34156820>> D: 09:19:40,494 i18n.setup_gettext:192: gettext_countries = <bound method GNUTranslations.gettext of <gettext.GNUTranslations object at 0x000001DD34156760>> D: 09:19:40,495 i18n.setup_gettext:193: gettext_attributes = <bound method GNUTranslations.gettext of <gettext.GNUTranslations object at 0x000001DD341568B0>> D: 09:19:40,495 i18n.setup_gettext:194: pgettext_attributes = <bound method GNUTranslations.pgettext of <gettext.GNUTranslations object at 0x000001DD341568B0>> D: 09:19:40,506 webservice._network_accessible_changed:364: Network accessible requested: 1, actual: 1 D: 09:19:40,508 webservice.set_cachD:386: NetworkDiskCache dir: 'D:/Users/ivan/Downloads/AudioVisual/MusicBrainz-Picard/Cache/network/' current sizD: 1.7 MB max sizD: 100 MB I: 09:19:40,508 pluginmanager.load_plugins_from_directory:207: Plugin directory 'D:\\Users\\ivan\\Downloads\\AudioVisual\\plugins' doesn't exist D: 09:19:40,509 pluginmanager.load_plugins_from_directory:219: Looking for plugins in directory 'D:\\Users\\ivan\\Downloads\\AudioVisual\\MusicBrainz-Picard\\Plugins', 0 names found D: 09:19:40,516 ui/playertoolbar.__init__:90: Internal player: QtMultimedia available, initializing QMediaPlayer D: 09:19:40,548 ui/playertoolbar.__init__:97: Internal player: available, QMediaPlayer set up D: 09:19:40,862 tagger.main:1487: Looking for Qt locale en_GB in D:/Users/ivan/AppData/Local/Temp/_MEI182482/PyQt5/Qt5/translations I: 09:19:40,866 browser/browser.start:121: Starting the browser integration (127.0.0.1:8000) D: 09:19:40,938 config.event:259: Config file update requested on thread 19196 D: 09:19:48,008 ui/mainwindow.auto_update_check:1781: Skipping start-up check for program updates. Today: 2023-07-29, Last check: 2023-07-29 (Check interval: 7 days), Update level: 0 (stable) D: 09:19:48,009 config.event:259: Config file update requested on thread 19196
Also to add… left the more detailed Task Manager up and CPU time is constantly ticking up, but threads, handles, IO, Page Faults, Memory all stay fixed. It is not moving other resources around, just making the CPU work.
Guys, please create a ticket and add your screenshots to it, thanks.
Zas remind me how to create a ticket.
I’m back and finally able to look into this. Unfortunately things are more complicated then I had assumed. It seems to be Windows specific. I can’t reproduce this at all on Linux, but in my Windows VM a freshly started Picard is constantly using 25% CPU (the VM is pretty limited CPU power). On Linux it is actually 0%. I’ll investigate and see to get this fixed.
This sounds suspiciously like the pipe handler for the instance, which is done differently for Windows as I recall.
A thought that crossed my mind after looking how things are going with v2.9:
Have you considered using a ‘release candidate’ version in between beta and final versions of Picard?
It might be good to have that for a month or so before publishing it as the final version?
I doubt that would have made a difference in this case. We had three pre-releases for this cycle, a 4th one likely wouldn’t have made much difference.
My estimation is that quite a few people that are hesitant to install beta versions of software, will install a release candidate version.
It’s about the size of the testers user-base, which will depend on trust.
Would the average user install:
So a RC version would have a larger base of testers, which would be a good thing before releasing a final version that users will expect to be completely reliable.
Will there be a new version download available soon as I noticed on the bug tracker saying this is now fixed. I checked for a dev/beta version via update in Picard but found nothing yet.
A new version should be released today.
Sweet, thank you for the update.