music-app takes too long to show available music

The music app defers media indexing and scanning to the mediascanner (a plugin for Grilo), and if I'm not mistaken thumbnailing is done by the thumbnailer, which recently gained the ability to cache thumbnails.

Jamie, could you try with image #96 if that improves things?

Album art caching has worked since Friday or so.

I did try #96 and it still seems awfully slow. I don't know what is causing the slowness, but I can't find any thumbnails (I think this may change in #97 with thumbnails being storing in ~/.cache/com.ubuntu.music). ~/.cache/mediascanner only is ~3.4M in size with 7.9G of music. ~/.local/share/com.ubuntu.music is only 640K.

All music tabs are slow to come up, showing 'Loading' and then after that goes away, it still takes a long time to fill things in. The Songs tab is probably the most performant tab.

I should also mention that show 'top' reveals it is qmlscene for the music-app that is taking 100% of the CPU when the app is starting and that it continues to peg the CPU for a while (the music-app process seems to be stopped when the screen blanks, and after I unblank the screen the app pegs the CPU again-- it usually finishes before the scond screen blank).

I agree with jdstrand. Since an update yesterday the music app no longer plays when the screen is blanked. On reactivation of the screen the music-app fires up again.

Also there is an intermittent flip flop between phone speaker and headphone jack when plugged in.

Judders when scrolling through songs and cover art animation clunky.

The resolved album art from mediascanner is stored in .cache/media-art does the music click app even have access to that directory?

The music-app does have access to that directory because it uses the "unconfined" apparmor template which has wide open permissions. The apparmor profile is com.ubuntu.music_music_1.0.196 and I verified there are no denials and that the profile is wide open (/var/lib/apparmor/profiles/click_com.ubuntu.music_music_1.0.196).

However, ~/.cache/media-art is empty. What app is doing the thumbnailing, the music-app or the out of process mediascanner? If the music-app, the thumbnailer is written to write the files to somewhere in ~/.cache/com.ubuntu.music-- the path is determined based on the apparmor label. That said, ~/.cache/com.ubuntu.music does not exist here and creating it doesn't seem to make a difference.

Btw, I just tested this on image 99.

Note that the music app does not access .cache/media-art directly: it talks to Grilo (for which mediascanner is a plugin) using its QML bindings.

Jamie, to answer your last question, the music app does not do any thumbnailing. It used to do so up until about a month ago, but then it started using Grilo/mediascanner and it leaves the work to them and thumbnailer.

Regarding grilo/mediascanner> ok, but note whenever the music app is confined, we need to make sure it can handle read-only access to the ~/.cache/media-art directory, otherwise this needs to be made app specific.

I've proposed a merge that should reduce the time it takes for the grilo model to load greatly. This should cut the load time down 30% or so. Additionally, I'm toying around with the idea of not loading the Songs tab until it is selected. Doing so greatly reduces the time it takes the app to load and it also only adds a small amount of time while loading the Songs tab when first selected.

Fix committed into lp:music-app at revision 234, scheduled for release in music-app, milestone 1.0