Pressing the "previous" button while paused does not move the seekbar to the start

[Omer Akram]

vivid r194, krillin

1. Open music app
2. play a song more than 5 seconds.
3. press the pause button
4. press the "previous" button

What happens:
The seekbar stays at its current position visually.

What should happen:
Seekbar should move to the very start.

To reproduce, press the previous button immediately (within half a second or so) after hitting pause.

This issue was discovered with an autopilot test result[1].

http://ci.ubuntu.com/smokeng/vivid/touch/mako/181:20150422:20150210/12698/music_app/2131959/

[Victor Thompson (vthompson)]

This is a duplicate of lp:1442927. We suspect there's something in vivid that is affecting (delaying) this test.

[Victor Thompson (vthompson)]

While this is more or less a dupe of lp:1442927, the problem isn't one of timing as previously thought. The issue is truly something in the audio stack causing issues. I don't see anything in media-hub's log but in the music app's log I see this (unrelated noise has been truncated):

Actually calling m_hubPlayerSession->play()
VideoDimensionChanged signal arrived via the bus.
libust[4537/4559]: Error: Error opening shm /lttng-ust-wait-5-32011 (in get_wait_shm() at lttng-ust-comm.c:958)
libust[4537/4558]: Error: Error opening shm /lttng-ust-wait-5 (in get_wait_shm() at lttng-ust-comm.c:958)
Failed to start playback: Problem starting playback on remote object
.
<truncated>
.
Failed to get current playback position: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.

[Victor Thompson (vthompson)]

Also to be noted is that once this happens the app freezes permanently when a song is played.

[Victor Thompson (vthompson)]

Adding media-hub for visibility. IMO this bug needs to be fixed prior to vivid being promoted to stable because I'm not certain it only happens when the music is paused. This bug has been around for awhile now.

[Jim Hodapp (jhodapp)]

This is invalid for the description of the bug. It's intended that the position is not updated in this case because media-hub isn't the one controlling the playlist. This would be a valid bug if it occurred after media-hub has complete background playlist support in place.

Now the not getting a reply means that media-hub has either crashed or locked up. It would be helpful to have the complete log for media-hub [1] in this scenario be attached to this bug.

[1] /home/phablet/.cache/upstart/media-hub.log

[Victor Thompson (vthompson)]

While trying to reproduce, I had media hub crash prior to recreating the issue. I assume the cause is similar, however. The crash occurred at the very end of the logs.

[Jim Hodapp (jhodapp)]

@Victor: I don't see a segfault in there. Perhaps media-hub-server has hung? Can you confirm by trying to do the following:

1. When you get this issue, quit music-app
2. Open music-app and verify if you can play anything or if it can't connect to the MH backend
3. Open mediaplayer-app and confirm the same thing

If you can't do either then MH has hung and it is a valid bug but we'll want to rephrase this bug's wording or file a new one against MH.

[Victor Thompson (vthompson)]

@Jim: Right, I think media-hub was just hung. I think it's a different issue from whats being reported here, however. My mistake.

This issue seems to only occur right when you open the app. I've attached the media-hub.log when this occurs. media-hub does not crash and does not hang when it occurs. The app and media-hub both continue to function after the bug is hit.

[Victor Thompson (vthompson)]

@Jim, I've looked at lp:1442927 and the test failures started with vivid image #158 [1] which included the new media-hub3 package [2]. This bug is easily reproducible if the previous button (which does a "seek" to 0 in this case) is pressed very soon after hitting the pause button. You can look through the various logs listed in the image 158 tests [1], but it doesn't appear as though anything obvious is being output. Do you think it's possible that media-hub is still processing something related to the "pause" action/request that is being interrupted by the "seek to 0" action or is otherwise preventing the seek from occurring?

1 - http://ci.ubuntu.com/smokeng/vivid/touch/mako/158:20150401.1:20150210/12560/music_app/
2 - http://people.canonical.com/~ogra/touch-image-stats/158.changes

[Jim Hodapp (jhodapp)]

@Victor: thanks for the info. I'll change this back to new status for media-hub and try to confirm it. Thanks for narrowing it down. Which device were you testing this on?

[Victor Thompson (vthompson)]

@Jim: I've reproduced it on mako.

[Victor Thompson (vthompson)]

@Jim: Were you able to confirm this bug?

[Jim Hodapp (jhodapp)]

@Victor: with the latest media-hub that I've been working on, I cannot reproduce this on arale. I'll try with some of my other devices as well.

[Jim Hodapp (jhodapp)]

@Victor: is this still occurring even with silo 9?

[Launchpad Janitor (janitor)]

[Expired for media-hub (Ubuntu) because there has been no activity for 60 days.]