Did you set the metadata twice? I used the same image url in your log and produced a dummy test page:
http://xxyzzzq.github.io/sandbox/media-session/full-test-temp.html

I can only see the image request is redirected and then downloaded once.

It is an issue with MediaSession service routing.

When switching media src, here's what could happen:
1. The player is removed (not suspended) from MediaSession, so the session becomes inactive
2. No service should be routed at this moment, so MediaSessionTabHelper receives null metadata once.
3. Then when the player starts playing with the new src, the session becomes active again
4. The same services should be routed at this moment, so MediaSessionTabHelper receives the old metadata once again.

We were relying on Blink to cache the image, however since the png file on freemusicarchive.org is redirected into different URLs every time, the caching won't work.

One way to fix this issue is to cache the image in MediaImageManager.java by the URL before redirect, and maybe expire the cached image after the tab stops playing sound for a certain period.

I would advice against implementing a caching specific to media session. We should either rely on browser caching or find a solution that wouldn't need to rely on caching. I didn't review the MediaSession routing code so I'm not sure why the decision was made :)

Another solution:

We could queue a delayed task for unsetting metadata from MediaSessionImpl. If a new metadata is set before the task executes, we cancel the task and pass the new metadata to MSTH. Otherwise, the task will eventually execute and unset metadata in MSTH.

In this way we could avoid caching the image.

But the drawback is that the metadata unsetting is delayed and will affect other platforms, which is generally not good (as we discussed for delaying the media session state change).

A better fix is to keep MediaSession active while a media element is switch src. It will touch media element/WMPI. I'll see if it is doable.

fbeaufort@, does this still apply? is it related to the networking cache issue we discussed about?

It is indeed a networking cache issue (as the img resource is marked as no-cache) but I've found more:

With:

  navigator.mediaSession.metadata = new MediaMetadata(tracks[trackIndex].metadata);                                                          
  $audio.src = tracks[trackIndex].src; 

I can see artwork downloaded twice.


With:
                                                    
  $audio.src = tracks[trackIndex].src; 
  navigator.mediaSession.metadata = new MediaMetadata(tracks[trackIndex].metadata);      

Artwork is downloaded once!


I believe this should be fixed in MediaSession. WDYT?

https://codereview.chromium.org/2627103002/

Yeah! Re: https://codereview.chromium.org/2627103002/, should we simply update the notification when something actually changed?

The logic in MediaNotificationManager checks the difference internally. But there are other factors which will make notification to be updated.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/d9031fa168c6d3a3b2437f56eea99d3c2a16572e

commit d9031fa168c6d3a3b2437f56eea99d3c2a16572e
Author: zqzhang <zqzhang@chromium.org>
Date: Thu Jan 12 16:25:54 2017

[MediaNotification] Avoid fetching image twice when artwork doesn't change

When switching src or modifying metadata, the whole metadata will be
sent to MediaSessionTabHelper causing it to download the same image src
twice even if the artwork stays the same. This CL make MediaImageManager
to remember the src of the last downloaded image so that it can avoid
fetch the same src.

BUG= 672023 

Review-Url: https://codereview.chromium.org/2627103002
Cr-Commit-Position: refs/heads/master@{#443256}

[modify] https://crrev.com/d9031fa168c6d3a3b2437f56eea99d3c2a16572e/chrome/android/java/src/org/chromium/chrome/browser/media/ui/MediaImageManager.java
[modify] https://crrev.com/d9031fa168c6d3a3b2437f56eea99d3c2a16572e/chrome/android/junit/src/org/chromium/chrome/browser/media/ui/MediaImageManagerTest.java

I've tried it with Chromium (57.0.2981.0) and it works great on artwork images that are successfully fetched eg. HTTP [200, 300).
Sadly, when artwork returns HTTP 404 for instance, the artwork is still downloaded twice ;(

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/27ecb94bbf93d0324fd74ca1f689e806cae2df51

commit 27ecb94bbf93d0324fd74ca1f689e806cae2df51
Author: zqzhang <zqzhang@chromium.org>
Date: Mon Jan 16 12:05:06 2017

[Media>UI] Follow-up fix for avoiding downloading image twice

Previously the cached src for last media image will be reset when the
download callback returns a failure (404, image, etc.), thus the image
will be fetched another time when the session goes active. This CL
removes the reset in this case thus avoiding trying fetching the image
another time while already knowing it will fail.

BUG= 672023 

Review-Url: https://codereview.chromium.org/2629083004
Cr-Commit-Position: refs/heads/master@{#443871}

[modify] https://crrev.com/27ecb94bbf93d0324fd74ca1f689e806cae2df51/chrome/android/java/src/org/chromium/chrome/browser/media/ui/MediaImageManager.java
[modify] https://crrev.com/27ecb94bbf93d0324fd74ca1f689e806cae2df51/chrome/android/junit/src/org/chromium/chrome/browser/media/ui/MediaImageManagerTest.java

Verified in Chromium (57.0.2985.0)!
Yeah!