Comment 4 for bug 1241185

Since you want to mark this bug as "Won't fix", can you point me to some docs for music-hub? I can only find some info about QtMultimedia.MediaPlayer related to music-hub, but that QML API is apparently missing the functionality described in this bug report.

I'm already using QtMultimedia.MediaPlayer, and while that allows me to keep playing the current song when the display turns off or I switch to another app, which is already a huge improvement over the state from ~1.5 years ago when I tried this the last time, it's still not even close to "good enough".

When the current song ends, the MediaPlayer.onStatusChanged signal is not executed immediately, but only after I switch back to my app or unlock the phone. As far as I can tell, that signal is the only place where I could start playback of the next song. So it's just silent after the current song ends, clearly a very bad user experience.

You should either allow apps to run the slot connected to that signal whenever it is fired (which might be pretty difficult to solve and opens up a lifecycle policy exploit), or add a queue API to QtMultimedia / some other QML namespace. (On a related note, a signal like "playbackAboutToFinish" could allow implementing gapless playback in the future.)

If you do the queue thing, make sure to support programatically deleting from the queue before the media is played: I want to implement "play next song from my app's queue, or if the user has not enqueued any songs, play next song from album". If I am supposed to use the music-app queue, I have to enqueue all the remaining songs on the current album when playback starts. If a user then adds something to the app queue, I must be able to remove everything from the music-hub queue, add the user-provided song, then add every song following the newly enqueued song on its album.