I wanted to add some additional info.

The callback for the 'next/previous' controls is the exact same one I use on the main screen (the buttons left and right of the big orange play button). If you tap those, they do load the next station and plays it.

When I tap the notification's next/previous buttons while the app is in the foreground (behind the notification shade) it works, too.

But if I tap either of them while the app is in the background it doesn't work. It loads the station, the metadata/mediasession notification is updated, but the stream doesn't play. I checked the events and the audio element *does* report it's playing (onPlaying event is fired). 

Only when I return to the app, the music starts playing (read: actually making sound)

Need to test the issue NPO Rado stations. Could some one from MTV Team please look into the issue and provide an update.
Thank You.

Routing to Media team fro triaging.

OP, do you use iframes to play the radios?

@comment6: No it's an audio element embedded in the page. It's created by javascript.

See the app.audio class. I control most of it through methods in app.sections.home, those call app.mediaplayer and that controls app.audio (or app.chromecast, depending on selected output).

I attached a zip with the unbundled, un-uglified sources (note: I use gulp to preprocess everything. It's also set up to become a cordova project but this isn't required or used at this time).

Deleted: cordova-icerrr2.zip 1.1 MB

cordova-icerrr2.zip 1.1 MB Download

I look at it in different angles and couldn't find an obvious issue. It seems that the playback should be starting. One thing I was wondering if you might be creating a new <audio> but it seems like you are not. If you are, try to just recycle the same <audio>. There are a ton of stuff happening when pressing next and I wonder if there is something happening there. FWIW, https://googlechrome.github.io/samples/media-session/audio.html is working so the feature itself isn't broken: it's either an edge case or a problem with the website.

+fbeaufort@ who may have an idea :)

Thanks I'll try to contact fbeaufort, I think I follow him on G+ :)

I've been thinking about it and it I came up with two possible causes:

1) I think I pause the audio before I switch stream. It seemed the sensible thing to do. Maybe audio.play() is not allowed/working in the background?

2) When the stream pauses, I disable preload (I think it's preload="none") because if I don't then the audio will just keep buffering the stream - since it's a radio stream it never stops buffering and ends up using a lot of data. Maybe this causes the stream not to start?

PS: I know that at least javascript is executing because it does refresh the "now playing" info and album art (both ajax calls that take a little while) when I press play..

1. there are limitations for playback in the background but if you use an <audio> that previously played in the background, it *should* be fine. I have not checked. I think that for sure if you call play() in the event handle of the media session event handler, it should work.

2. I don't think preload should have any impact.

With Chrome Canary (65.0.3288.3), I can reproduce this issue.

When the app is in foreground, there's no problem. I can hit next multiple times in the media session notification.

When the app is in background, I get a MEDIA_ERR_DECODE which causes the media session notification to disappear. For info, here's the error from about:media-internals: 

    Failed to send audio packet for decoding: timestamp=8208000 duration=24000 size=698 side_data_size=0 is_key_frame=1 encrypted=0 discard_padding (ms)=(0, 0)

> 1) I think I pause the audio before I switch stream. It seemed the sensible 
> thing to do. Maybe audio.play() is not allowed/working in the background?

If you re-use the same <audio>, you should be able to play it in the background. However, if you create another one, it will not work. It may work if you do this inside the 'nexttrack' event handler though but I guess it may not happen given the amount of JS running (probably async) when the action happens.

> 2) When the stream pauses, I disable preload (I think it's preload="none") 
> because if I don't then the audio will just keep buffering the stream - since 
> it's a radio stream it never stops buffering and ends up using a lot of data. 
> Maybe this causes the stream not to start?

I don't think this should be a problem if you call play() explicitly.

I'm afraid there isn't much else we can do here. I am going to un-assign myself and will close this bug later unless we get more actionable information such as a reduced test case.

Ok I found the issue. It's the way I implemented the fadeIn() function (using requestAnimationFrame). That doesn't get called in the background I guess.

So the stream actually works but I set the volume to 0 and then requested an animation frame. Bah. So I guess I have to find some other way to do it.

At least, I just commented out the fadeIn() call and the playback works so it's still an assumption but I'm pretty sure :)

Oh well. Thanks for all the effort and investigating! I guess this issue can be closed.

I'm glad you figured it out.

The NextAction date has arrived: 2017-12-20