Hi.
Picard 2.9 uses about 14% of the CPU at idle
Hm, well spotted.
Same here:
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 --single-instance parameter?
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%.
edit:
2.8.5 is between 0% and 0.5% for meâŚ
1 Like
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: --stand-alone-instance
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.
1 Like
Done.
6 Likes
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.
3 Likes
This sounds suspiciously like the pipe handler for the instance, which is done differently for Windows as I recall.
1 Like
Great.
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.
1 Like
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:
- alpha version? probably not
- beta version? A small percentage of curious users will.
- release candidate? A larger percentage of users will.
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.
3 Likes
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.
1 Like
Sweet, thank you for the update.