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

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

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.

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

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.

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

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.

@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.

@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.

@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

@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?

@Jim: I've reproduced it on mako.

@Jim: Were you able to confirm this bug?

@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.

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

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