Browsers connect but fail due to not passing correct information

[gbcox]

This came up in this discussion: https://bugs.kde.org/show_bug.cgi?id=399249

Basically, browsers take control of rescrobbled when playing a video or music, i.e. youtube - but fail because they didn't by default consider scrobbling in their mpris implemention. However, what happens is that they grab control of rescrobbled as an active player. Playback needs to be stopped to release control so another player can take the active slot. I discussed this in the above bug report on elisa. I'm not sure if there is anything that can be done on the rescrobbled side about this. The browser is a valid mpris connection, it just doesn't support scrobbling. rescrobbled soon discovers this, and I suppose it could just release the browser from the active player slot if it encounters that error, freeing it up for another mpris player that supports scrobbling. Once the next selection plays however in the browser it would be wash, rinse, repeat unless you somehow banned the browser for the remainder of the rescrobbled current session.

[InputUsername]

Yeah, I think this is a limitation in the way browsers provide metadata via MPRIS. Most browsers/websites just report song titles in the form Title - Artist as the MPRIS title field while leaving artist/album empty. My personal solution has been to only whitelist the music players I use and ignore everything else, not sure if that's a reasonable option in this situation?