GNOME Bugzilla – Bug 541469
UI often hangs when changing tracks while cover art is fetching
Last modified: 2020-03-17 08:24:40 UTC
Steps to reproduce: 0. Enable cover art fetching. 1. Begin playing a track. 2. While cover art extension indicates that it's still doing something, skip to next track. Expected result: Next track starts playing immediately. Actual result: Banshee UI hangs for awhile, old track keeps playing. After many seconds, next track finally begins to play. I can't quite nail this down...sometimes it works fine, but with the majority of my tracks it hangs. It seems to be related to whether or not they already have cover art. Disabling the cover art extension makes the problem go away.
Yeah I had to disable the fetcher, too, banshee hanged almost every time song changed (the fetcher seemed to hang earlier, too).
I think the source of the problem is the SQL query used in the beginning of CoverArtJob.Run(). It takes 2s of CPU time to run on my system. It's used on every track change to check if it should try to fetch some cover art.
*** Bug 540526 has been marked as a duplicate of this bug. ***
Snorp committed a fix so that the cover art refresh isn't triggered by the play/skip count getting incremented or rating changed, and I committed two fixes, one to set the job as lowest priority, and another fixing a big performance regression I introduced ~ a week ago in a SQL query. Fixed!
1. Tools->Cover Art->Download Cover Art 2. Try to change to next track Hang.
That being said, snorp's fix makes this bug much less likely to show up.
(In reply to comment #5) > 1. Tools->Cover Art->Download Cover Art > 2. Try to change to next track while fetching occurs > > Hang. Can anybody else reproduce this with r4254 or later?
(In reply to comment #7) > Can anybody else reproduce this with r4254 or later? No. Even if I clear my album-art cache, the cover art fetcher is too damned fast. :P I don't even get any feedback that it's downloading anything.
We identified the slow query in IRC today and Gabriel is working on a fix, last I checked.
(In reply to comment #7) > (In reply to comment #5) > > 1. Tools->Cover Art->Download Cover Art > > 2. Try to change to next track while fetching occurs > > > > Hang. > > Can anybody else reproduce this with r4254 or later? > Can reproduce using 1.2 on Hardy.
Hearing reports about this downstream: https://bugs.launchpad.net/bugs/340436. I've noticed that "Downloading Cover Art" takes a long time when it is triggered by rescanning my library, even on recent SVN checkouts. Would --debug-sql output be useful here or is there otherwise any information others or I could provide to track this down?
Banshee is not under active development anymore and had its last code changes more than three years ago. Its codebase has been archived. Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect reality. Please feel free to reopen this ticket (or rather transfer the project to GNOME Gitlab, as GNOME Bugzilla is being shut down) if anyone takes the responsibility for active development again. See https://gitlab.gnome.org/Infrastructure/Infrastructure/issues/264 for more info.