GNOME Bugzilla – Bug 757326
Deleting files in home directory, Downloads directory, etc, causes 100% CPU utilization and UI freeze
Last modified: 2018-01-10 14:46:12 UTC
GNOME Music automatically scans certain directories for new music tracks. I regularly download ISOs of operating system install images to the Downloads directory, which is automatically scanned by GNOME Music. When a new ISO image is added to a directory monitored by GNOME Music (Downloads in this case), CPU utilization jumps to 100% and the UI becomes unresponsive (with GNOME offering to kill the application). This would appear to be due to scanning the ISO for music files. I would recommend modifying GNOME Music to avoid scanning ISO files in general.
GNOME Music uses tracker to find new content, reassigning
Does the CPU utilization still jump to 100% if gnome-music is not running (and only tracker is running in the background)? Is this triggered by a specific ISO?
The ISO file (or that it's an ISO) is not relevant here. What AFAICS is happening here is: 1) Browsers usually download files to a temporary file, when the download is finished, the file is renamed to be the right one. 2) If this temporary file is visible to tracker (that's at least the case with ephy/webkit), tracker will catch the business and notify about the addition+removal through GraphUpdated 3) The grilo tracker plugin sees the removal of "something" (the temporary download file), and emits GrlSource::content-changed without further checks of its previous type. 4) gnome-music handles this deletion in: https://git.gnome.org/browse/gnome-music/tree/gnomemusic/grilo.py#n128 It just appends the ID corresponding to the deleted temporary file (unknown till then to gnome-music). 5) Eventually, gnome-music emits the change like this: https://git.gnome.org/browse/gnome-music/tree/gnomemusic/grilo.py#n164 Which just invalidates a lot of stuff, and trigger many rechecks. 6) Everything is queried again for all views at once, albumart is looked up again, etc etc. This is where high CPU usage and UI freezes happen. IMO, the bug is shared here between grilo and gnome-music: - Grilo could perform further checks on the removed files (the rdf:type(s) being removed of the file being removed are also notified through GraphUpdated) - gnome-music does not need to invalidate that much. Running through the different listmodels looking up for the file that matches the given ID (if any) will be surely faster and/or friendlier to perform in the background than a full invalidation of all data queried so far. Moving back to gnome-music, although perhaps another bug to grilo should be filed.
As an update, I'm now running gnome-music 3.20.2. I can reliably trigger this bug by simply putting a file in my home directory, waiting for a bit (long enough for the file to be noticed by tracker), and then removing the file. GNOME Music then gets in either an infinite or very-long loop. Running gnome-music with the --debug option shows this output: 10:28:58 DEBUG ||||MediaPlayer2Service._get_media_id(<MediaPlayer2Service>, <Grl.Media object at 0x7f1ef358ce58 (GrlMedia at 0x55a5e51ffde0)>)[mpris.py:359] 10:28:58 DEBUG |||| returned '/org/mpris/MediaPlayer2/TrackList/109957' repeated millions of times. For the record, I have about 6000 songs total, not a huge amount.
Also, for the record, this happens regardless of the type of file that is deleted. I deleted a text file named "foo" in my home directory and triggered the bug.
Updating to major severity because this happens to the point that the application is unusable, locking up after every song.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnome-music/issues/44.