touch-packages team mailing list archive

[Michi Henning <michi.henning@xxxxxxxxxxxxx>]

I had a bit of a tinker with your simplified example, thanks for that!

The reset of the list happens each and every time we return an error
from the thumbnailer. This is new; with the previous thumbnailer, you
never saw any errors because the thumbnailer delivered a fallback image
when something went wrong.

This behavior is going away (currently in silo 45), and the music app
needs to handle errors for thumbnails that cannot be produced and
provide its own fallback art in this case.

I know next to nothing about qml but, from reading some of the docs, it
looks like you can delegate the image loading to a Loader that returns
default art when something goes wrong.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to thumbnailer in Ubuntu.
https://bugs.launchpad.net/bugs/1542175

Title:
  Problems and crashes with local music collection

Status in Ubuntu Music App:
  New
Status in thumbnailer package in Ubuntu:
  New
Status in unity8 package in Ubuntu:
  Invalid

Bug description:
  We have just made a change to the thumbnailer that provides a 12x
  speed-up for extracting cover art from local music files with embedded
  artwork. I'm seeing serious problems with the song list in the music
  app with this new thumbnailer. I have tried very hard to find fault
  with what the thumbnailer is doing, but I don't think we are to blame.
  I need help getting to the bottom of this; I can't debug it myself.
  But I'm fairly confident that either the music app or the
  implementation of song list widget is doing something wrong.

  I've attached an archive that contains 1000 songs, each of which has
  embedded cover art. (It's the same boring image for all of them.)

  I'm seeing the problem on Mako, rc-proposed, build 359, which includes
  the new music app, I believe.

  The modified thumbnailer is available in silo 31. Please let me know
  when you no longer need the silo, so I can release it again. (We are
  really short on silos at the moment; it might be best to grab the
  vivid arm debs from the silo.)

  To reproduce the problem, install the silo, then:

  - Kill the music app
  - Clear out the Music folder
  - untar the song collection into the Music folder
  - run "thumbnailer-admin clear" to empty the caches
  - monitor the device with top and wait for the media scanner to finish indexing
  - Start the music app and go to the song list

  I'm seeing really weird behavior. Initially, the song list flickers a
  few times, redrawing itself each time. After a few seconds, it settles
  down. Now start scrolling slowly. It might work for some distance but,
  after a few songs, the song list is reset to the top (first song) and
  redraws itself.

  Now scroll down again, quickly. Again, the song list resets to the
  top.

  Each time this happens, the song list is populated with a bunch of
  extra songs. Each time I scroll down, it works fine for the region
  that was cached previously, and then things blow up as soon as the
  scroll moves into the as-yet unexplored part.

  Looking at the thumbnailer, I'm not seeing anything unusual. We
  deliver thumbnails as we should. But I notice that, for some reason,
  while scrolling in the song list, the music app also sends requests
  for artist art to the thumbnailer? Why? There is no artist in sight.

  Some of the songs in the collection have an empty artist field and the
  thumbnailer returns an error for that (because asking for artist art
  without an artist doesn't make sense). But there can be other errors,
  such as errors returned by the remote server.

  It looks like the song list resetting is related to the error return
  from the thumbnailer. Every time the thumbnailer reports that
  something could not be extracted, the song list misbehaves.

  If the already-thumbnailed list gets too long, you can run

  thumbnailer-admin clear

  to empty caches. (There doesn't ever seem to be a problem in the
  region of the list that has been cached already.)

  I'm also getting occasional crashes from the music app while trying
  all this. And, every now and then, I find a message such as

  DelegateModel::cancel(): index out of range 34 0

  in the music app log. (I have no idea whether that is related.)

  I'd really appreciate if someone can look at this urgently. We want to
  land the improved thumbnailer but, while things are in this state, we
  can't. As best as I can tell, the problem might be related to
  incorrect error handling when the ThumbnailerImageResponse returns a
  request with status "invalid", either in the music app, or somewhere
  in the qml machinery.

To manage notifications about this bug go to:
https://bugs.launchpad.net/music-app/+bug/1542175/+subscriptions