audacious2 does not allow seeking or display seek widget for streaming mp3 urls anymore

Bug #665586 reported by qbxk
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
audacious (Ubuntu)
Triaged
Medium
Unassigned

Bug Description

Binary package hint: audacious

since i upgraded to 10.10, and thus audacious 2.4.0, (iirc, 10.04 used audacious 2.3.9) listening to mp3 files accessible through http no longer allows seeking nor is the seeking widget displayed. previous version of audacious had both allowed seeking and displayed the seek widget. there is no technical reason why seeking should not be available, and perhaps this ui change was related to ensuring that seeking was disallowed for actual mp3 streams (ie, icecast/shoutcast). iirc, the widget was displayed (incorrectly) for live streams previously, but is not now (which is correct behavior). I'm uncertain if this affects file types other than mp3, but that seems likely

IMO, this is *likely* to be an upstream bug, however, the audacious devs have specifically requested to report bugs to our distribution unless we were able to build it ourselves, and for various reasons i was unable to build a functional audacious on my system from their sources.

To reproduce:
   1) get a url for an mp3 file, one that would be delivered as a static file download (ie, not streamed via icecast/shoutcast)
   2) from the playlist in audacious, click and hold the "+" button, and hit "Add internet address..." (or use CTRL+H)
   3) enter your url, hit ok, then begin listening
   4) the seek widget is unavailable, and using the seek keyboard shortcuts for seeking (right/left arrow keys usually) results in skipping to the next/previous track on the playlist

Expected Behavior:
    the seek widget should be displayed allowing you to listen to any point in the mp3 file without requiring a full download of the file.
    using the seek keyboard shortcuts (right/left arrow keys) should seek +/- 5 seconds in the track, as if the file were being played from a local filesystem

for comparison you can follow the reproduction steps in another music player, perhaps VLC, and find that the expected behavior is available.

ubuntu package version: audacious 2.4.0-0ubuntu3

Tags: audacious seek
description: updated
Bryce Harrington (bryce)
Changed in audacious (Ubuntu):
importance: Undecided → Medium
status: New → Triaged
Revision history for this message
William Pitcock (nenolod) wrote :

hi,

adding http://nenolod.net/~nenolod/Kompressor_-_Shiny_Happy_People.mp3 allows seeking. Are you certain you aren't adding URLs that are really streamed? ampache, for example, feeds the MP3 through a PHP script and does not provide Content-Length information so Audacious will obviously think it is streamed.

Revision history for this message
qbxk (ubuntu-launchpad-luckyb) wrote :

very interesting. i see that this url does play while allowing seeking, thank you for noticing that

i like to listen to shows put up by my local radio station, and i suppose files from their webserver are being delivered in such a way that audacious doesn't allow streaming, here's a sample for you, http://www.uvm.edu/~wruv/res/audio/exposure/2009-12-09_2000h_Wed-EXPOSURE_featuring_live_local_music.mp3

i notice that there is a content-length header delivered when i request it via HEAD on the command line, and i don't see any other important headers that differ from your server.

what i think is most important to mention, however, is that i've been listening to this station for a long time, and only when i upgraded audacious did i lose the ability to seek. it did used to work, now it doesn't work in this case, but still works in yours for some reason. what is the important difference between these files? obviously file length is much larger in my case, but is that the deciding factor, i hope not.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.