Summary: | pausing when playing streams should actually cause a stop | ||
---|---|---|---|
Product: | [Applications] amarok | Reporter: | Pierre Maurier <strassh> |
Component: | Playback | Assignee: | Amarok Developers <amarok-bugs-dist> |
Status: | RESOLVED FIXED | ||
Severity: | wishlist | CC: | kde-bugzilla, simon |
Priority: | NOR | ||
Version: | 2.3-GIT | ||
Target Milestone: | --- | ||
Platform: | openSUSE | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | 2.3.1 |
Description
Pierre Maurier
2009-05-16 14:25:08 UTC
I can confirm this behavior. According to manually measuring times, it looks like the buffer keeps ~6 minutes. Additionally, during having paused the stream (or when resuming and playing from the buffer), the OSD displays track changes - which looks like they are coming from the live stream and therefore are out of sync with what Amarok actually plays (especially when paused). I agree that "pause" on a stream should act like stop, and "unpause"/"play" should then restart playing it again (where the stream is currently, not where it has been stopped). While it would be nice (and that might have been the intention), to provide time-shifting this way (e.g. when pausing for only a few seconds/minutes), it causes the stream to be not synced to the "real world". Adapting title commit 84ad0085280802c2a1ae93baa59b33a216828978 Author: Mark Kretschmann <kretschmann@kde.org> Date: Fri Apr 16 09:07:02 2010 +0200 Better fix for pausing SHOUTcast streams. The old solution didn't pause the stream, but instead stopped it. This had the drawback that we advanced to the next track. Now we pause it, but on resume we check if the track is a stream, and then we either resume normally, or restart the same track. BUG 192878 *** Bug 233606 has been marked as a duplicate of this bug. *** |