Bug 268282 - MPRIS dbus signals are providing incorrect information
Summary: MPRIS dbus signals are providing incorrect information
Status: RESOLVED FIXED
Alias: None
Product: amarok
Classification: Applications
Component: general (show other bugs)
Version: 2.4.0
Platform: openSUSE Linux
: NOR normal
Target Milestone: 2.4.1
Assignee: Amarok Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-03-12 11:44 UTC by Schelte Bron
Modified: 2011-03-19 16:21 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In: 2.4.1


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Schelte Bron 2011-03-12 11:44:51 UTC
Version:           2.4.0 (using KDE 4.6.0) 
OS:                Linux

The MPRIS interface on Amarok 2.4.0 has been messed up quite a bit. When
playback is paused, Amarok sends out a StatusChange signal containing 0 1 0 1,
which means it is Playing.  When resuming playback it sends a StatusChange
signal containing 1 1 0 1, saying playback is Paused.

The MPRIS2 interface does pretty much the same, sending a PropertiesChanged
signal containing a PlaybackStatus of Playing when Paused and Paused when
playback is resumed. On the first change it does not send a PropertiesChanged
at all.

The MPRIS CapsChange signal is also providing wrong information: 119 on pause
(i.e. CAN_PAUSE is true and CAN_PLAY is false), and 123 on resume (CAN_PAUSE is
false and CAN_PLAY is true).

It almost looks like these signals are describing the old situation instead of
the new one, as they are supposed to be doing. All the MPRIS signals used to
work fine with Amarok 2.3.0. MPRIS2 wasn't supported in that version.

Furthermore, the MPRIS2 CanPause property is always false. According to the
MPRIS2 specifications it should at least be true when playback is paused and
CanControl is true (which it is).


Reproducible: Always

Steps to Reproduce:
- In a console window, run: dbus-monitor sender=org.kde.amarok
- Pause and resume playback in Amarok
- Look at the signals reported by dbus-monitor

Actual Results:  
The signals report data that seems to match the situation before the change.

Expected Results:  
The signals should report the new situation.
Comment 1 Myriam Schweingruber 2011-03-12 13:23:02 UTC
Alex and/or Aurélien, could you have a look at this, please?
Comment 2 Alex Merry 2011-03-17 14:13:56 UTC
I can't reproduce any of this (using Amarok git as of Monday 7th March).  The status change signals are completely correct - 1-0-0-0 is emitted when pausing, and 0-0-0-0 when playing.

Even if I switch to random mode, so that I get 1-1-0-1 and 0-1-0-1, it all still works fine.  The caps change is also correct.

Can anyone else reproduce this on OpenSUSE, or on other systems?
Comment 3 Alex Merry 2011-03-17 14:15:57 UTC
I tell a lie: I can reproduce the issues with the MPRIS2 interface, but not the MPRIS1 interface.
Comment 4 Alex Merry 2011-03-17 18:55:04 UTC
Ah, I see, there was a commit on 17th Feb that fixed this for MPRIS1.
Comment 5 Alex Merry 2011-03-17 18:59:20 UTC
Git commit becb0debb81b1f1a608806131e51fdd31159b288 by Alex Merry.
Committed on 17/03/2011 at 18:56.
Pushed by alexmerry into branch 'master'.

Fix playback status for MPRIS2 interface

Make use of the playbackStatusChanged EngineController signal to find
when we should update the playback status property, otherwise we set it
too early and get the wrong value.

BUG: 268282
FIXED-IN: 2.4.1

M  +2    -0    ChangeLog     
M  +1    -5    src/dbus/mpris2/Mpris2DBusHandler.cpp     

http://commits.kde.org/amarok/becb0debb81b1f1a608806131e51fdd31159b288
Comment 6 Alex Merry 2011-03-19 15:19:13 UTC
The MPRIS1 fix is in 2.4.1beta1, but the MPRIS2 fix won't be there until 2.4.1beta2.
Comment 7 Schelte Bron 2011-03-19 16:21:41 UTC
Thanks for the quick action. I'll keep an eye out for a new version. For now I'm going to stick with MPRIS1 anyway because the MPRIS2 implementation is missing some other important features, most notably the tracklist related information.