MPRIS2: the trackID is not updated

[Matthieu Baerts]

I've been working with the source trying to get a feel for the project. I "partially" fixed one of my issues, the music player not updating the cover when songs change. I got the icon to update whenever a new cover is not found, but still haven't gotten the tool tip text to update.

static gboolean _on_got_cover (CDSharedMemory *pSharedMemory)
{
 CD_APPLET_ENTER;
 if (pSharedMemory->bSuccess)
 {
   ...
  }
  else
// I added the 3 following lines
  {
   cd_musicplayer_apply_status_surface (myData.iPlayingStatus);
  }
...
}

[Matthieu Baerts (matttbe)]

@JoeBaloney: Thank you for this bug report! :)

Which version of the dock are you using? With which music player?
I think I already fixed a bug about this kind of problem (there was a problem with Amarok) and there were a bug with Pithos (http://www.glx-dock.org/bg_topic.php?t=6438 and bug #1039272 ).

I don't have this bug with Rhythmbox and Clementine. It can be interesting to get some useful messages in order to know if there is a bug with the dock or the player.
Can you launch the dock with this command and post here all messages that you'll have when a new song is starting to play:
  $ cairo-dock -l debug --colors | sed -n "/musicPlayer\// {N;p;}"

Can you also launch this command (the dock has to be started before):
  $ dbus-monitor > ~/dbus-monitor.log
Then change the song (if possible a new artist and a new album) and press 'Ctrl+C' on the terminal. Then post the content of the 'dbus-monitor.log' file here.

Have fun ;)

[Matthieu Baerts (matttbe)]

It seems you're not using the email address linked to your Launchpad
account and I guess this is why your message is not available here.

Here is the previous message (can you add the log file if it's possible?)

2012/9/17 JoeBaloney

> Okay, I looked at that bug report. (I had searched earlier for
> musicplayer, but got no results) and after looking in the dbus log, I am
> not seeing any trackids.
> I am using Audacious 3.2.1, Ubuntu 12.04 x86_64 with cairo-session. Cairo
> from bzr 3.0.99 beta 1
>

[Matthieu Baerts (matttbe)]

> after looking in the dbus log, I am not seeing any trackids.
Yes, it seems the trackid is always the same (you can also use d-feet to quickly and easily check DBus messages).

According to the MPRIS2 specifications, the 'trackid' is required and should be linked to an unique track:
 > If there is a current track, this must have a "mpris:trackid" entry (of D-Bus type "o") at the very least, which contains a D-Bus path that uniquely identifies this track.
  http://specifications.freedesktop.org/mpris-spec/latest/Player_Node.html#Property:Metadata
  http://specifications.freedesktop.org/mpris-spec/latest/Player_Node.html#Simple-Type:Track_Id

Can you report this bug to Audacious devs? It seems they don't use Launchpad: http://redmine.audacious-media-player.org/projects/audacious/issues

Thank you :) (and feel free to report/patch any other bugs or ideas ;) )

PS: @ fabounet: should we also check if the artist/album/title have changed to avoid this kind of problem even if this bug is not due to the dock?

[Matthieu Baerts (matttbe)]

I added a workaround on BZR (rev 2545: https://bazaar.launchpad.net/~cairo-dock-team/cairo-dock-plug-ins/plug-ins/revision/2545/musicPlayer/src/applet-mpris2.c )
But I hope it will be removed soon :)

[Fabounet (fabounet03)]

"should we also check if the artist/album/title have changed to avoid
this kind of problem even if this bug is not due to the dock?"
I'd rather not, it's not our job to fix others bug.
Plus it's a endless and hopeless battle, for non-critical bugs, the
correct way is to report bugs upstream and hope they fix it asap.

2012/9/17 Matthieu Baerts <email address hidden>:
>> after looking in the dbus log, I am not seeing any trackids.
> Yes, it seems the trackid is always the same (you can also use d-feet to quickly and easily check DBus messages).
>
> According to the MPRIS2 specifications, the 'trackid' is required and should be linked to an unique track:
> > If there is a current track, this must have a "mpris:trackid" entry (of D-Bus type "o") at the very least, which contains a D-Bus path that uniquely identifies this track.
> http://specifications.freedesktop.org/mpris-spec/latest/Player_Node.html#Property:Metadata
> http://specifications.freedesktop.org/mpris-spec/latest/Player_Node.html#Simple-Type:Track_Id
>
> Can you report this bug to Audacious devs? It seems they don't use
> Launchpad: http://redmine.audacious-media-
> player.org/projects/audacious/issues
>
> Thank you :) (and feel free to report/patch any other bugs or ideas ;) )
>
> PS: @ fabounet: should we also check if the artist/album/title have
> changed to avoid this kind of problem even if this bug is not due to the
> dock?
>
> ** Changed in: cairo-dock-plug-ins
> Status: New => Invalid
>
> ** Changed in: cairo-dock-plug-ins
> Assignee: (unassigned) => Matthieu Baerts (matttbe)
>
> ** Also affects: audacious (Ubuntu)
> Importance: Undecided
> Status: New
>
> --
> You received this bug notification because you are a member of Cairo-
> Dock Team, which is subscribed to Cairo-Dock Plug-ins.
> https://bugs.launchpad.net/bugs/1052162
>
> Title:
> MusicPlayer: the cover is not added when songs change
>
> Status in Cairo-Dock: Plug-ins:
> Invalid
> Status in “audacious” package in Ubuntu:
> New
>
> Bug description:
> I've been working with the source trying to get a feel for the
> project. I "partially" fixed one of my issues, the music player not
> updating the cover when songs change. I got the icon to update
> whenever a new cover is not found, but still haven't gotten the tool
> tip text to update.
>
> static gboolean _on_got_cover (CDSharedMemory *pSharedMemory)
> {
> CD_APPLET_ENTER;
> if (pSharedMemory->bSuccess)
> {
> ...
> }
> else
> // I added the 3 following lines
> {
> cd_musicplayer_apply_status_surface (myData.iPlayingStatus);
> }
> ...
> }
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/cairo-dock-plug-ins/+bug/1052162/+subscriptions
>
> _______________________________________________
> Mailing list: https://launchpad.net/~cairo-dock-team
> Post to : <email address hidden>
> Unsubscribe : https://launchpad.net/~cairo-dock-team
> More help : https://help.launchpad.net/ListHelp

[Matthieu Baerts (matttbe)]

@Ted: I think it will be better to directly use Launchpad to add new comments here (or send mails with your e-mail address linked to your Launchpad account) ;)

2012/10/3 Ted <>:
This is the response from the Audacious developer concerning the trackid requirement in MPRIS2:

-------- Original Message --------
Hi Ted,

I am aware of this "bug", but it is unfortunately a "wontfix", or more
precisely a "cantfix".

The thing is, MPRIS v2 was written apparently without much consideration
for playlist-based players like Audacious. Unlike Amarok, Rhythmbox,
Banshee, etc., where there is a database holding all the tracks, in
Audacious, a song is identified only by its position in the playlist,
which can change without warning. Hence, we can't provide reliable
track identifiers.

From what you said, I gather that cairo-dock is waiting until "trackid"
changes to check for changes in the metadata. That's not a good idea
anyway, since metadata can change even within the same track. (Think of
internet streams, or of the case where a user edits the tag on a file
while it is playing.) MPRIS v2 metadata uses the D-Bus properties
system, so a more natural and more reliable way to watch for metadata
changes is to connect to the "PropertiesChanged" signal.

I hope this helps.

-- John

[Matthieu Baerts (matttbe)]

@John: thank you for this answer!

Yes, our musicPlayer applet is connected to the "PropertiesChanged" signal but it checks if the trackid has changed in order to know if it has to notify the user and to not update informations if it's not needed.

Following MPRIS2 spec, if there is a current track, this must have a "mpris:trackid" entry (of D-Bus type "o") at the very least, which contains a D-Bus path that uniquely identifies this track.
This is why this applet only checks the trackid. It's just to not check if the artist, title, album, cover, etc. have changed. (now we just check if the title has changed too to avoid these kind of bugs)

But about the trackid, it's maybe better to add something even if it's not the id (e.g. something like a md5 sum of URI, or the address of the pointer). Clementine devs use the position of the song in the current playlist.

> Think of internet streams, or of the case where a user edits the tag on a file while it is playing.
You're right! If the trackid is not modified (e.g. if it's not a signature made with the metadata), it's a problem :-/ (and it's maybe useful to check if the artist has changed too to modify the icon's label if it's needed)

[Daniel Letzeisen (dtl131)]

http://redmine.audacious-media-player.org/issues/106