This bug appeared somewhere between 1.2.10-r1 and 1.2.10-r5 (given a guess, it appeared in -r3 when a stream seeking patch was apparently added). Vanilla XMMS 1.2.10 does not generate this problem. When playing mp3s that have http:// locations, files that are passed through any kind of script (ie: a php script that simply read()s and print()s the mp3), the output becomes garbled and choppy. In addition, the track play time is incorrect (generally shows in the 2800+ mins range). Reproducible: Always Steps to Reproduce: 1. Open a playlist with URI file locations (pointing to a script that generates the mp3) in XMMS. 2. Play the track. Actual Results: Garbled music plays. Expected Results: Non-garbled music should play. Portage 2.0.50-r11 (default-x86-1.4, gcc-3.3.3, glibc-2.3.3.20040420-r0, 2.4.20-gentoo-r8) ================================================================= System uname: 2.4.20-gentoo-r8 i686 AMD Athlon(tm) XP 2200+ Gentoo Base System version 1.4.16 distcc 2.12.1 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [enabled] ccache version 2.3 [enabled] Autoconf: sys-devel/autoconf-2.59-r3 Automake: sys-devel/automake-1.8.3 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-march=athlon-xp -O3 -pipe -funroll-loops" CHOST="i686-pc-linux-gnu" COMPILER="" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.1/share/config /usr/kde/3/share/config /usr/share/config /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=athlon-xp -O3 -pipe -funroll-loops" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache distcc sandbox" GENTOO_MIRRORS="http://128.213.5.34/gentoo http://gentoo.oregonstate.edu http://www.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://128.213.5.35/gentoo-portage" USE="X aalib apm avi berkdb bitmap-fonts bonobo cdr crypt cups encode esd esound foomaticdb gdbm gif gpm gtk gtk2 gtkhtml guile imlib java jpeg libg++ libwww mad mikmod motif mpeg ncurses nls oggvorbis opengl oss pam pdflib perl png postgres python qt quicktime readline ruby sdl slang spell ssl svga tcltk tcpd tetex tiff truetype x86 xml2 xmms xprint xv zlib"
commenting out line 98 from the -r5 ebuild # epatch ${PATCHDIR}/${P}-stream-seek.patch results in a version of xmms that functions properly, implying that this patch is what is causing the problem.
I think it is better to have seeking support for streams than to somehow try to figure out which http:// streams are seekable and which are not.
actually... streams without seeking support (shoutcast, etc) don't allow any kind of seeking, and xmms disables youu from trying to seek... so it looks like the bug is with your php script isn't well constructed... what script are you using?
I'm using a script that is essentially identical to the one shown in the URL I posted ( http://beezhive.com/sound_example.php - the relevent php source is the last one displayed on the page). I am not actually trying to seek in a non-seekable stream (although it will let me try). I tcpdumped a shoutcast stream, and didn't see any particular headers that I appeared to need to send to prevent stream seeking.
Looking at the streaming patch, it looks like this sets the stream to not seekable: content-length: 0 The relevant parts in the patch that give me this impression are: @@ -586,7 +594,9 @@ #endif /* udp_serverport = atoi (line + 20); */ } - + if (!strncasecmp(line, "content-length:", 15)) { + mpg123_info->filesize = atoi(line + 15); + } } else { @@ -917,7 +917,7 @@ break; } - if (!have_xing_header && strncasecmp(filename, "http://", 7)) + if(!have_xing_header && mpg123_info->filesize != 0) mpg123_info->num_frames = mpg123_calc_numframes(&fr); memcpy(&fr, &temp_fr, sizeof(struct frame)); Can you give that a try in your script.
That seems to have fixed it. However, a content-length of 0 technically violates the RFC ( http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.13 ), as the content length is definitely non-zero. Is perhaps the value of the filesize variable uninalized, thus causing the seemingly random very large play times when not sending a content-length (ie: should be initialized to 0 at some point, so no content-length given will default to the safer alternative)?
If it doesn't get a content-length, mpg123_info->filesize defaults to 0, but is there a way to have php not send a content-length?
HEAD /pass_song.php HTTP/1.1 HOST: beezhive.com HTTP/1.1 200 OK Date: Tue, 12 Oct 2004 02:33:34 GMT Server: Apache/1.3.31 (Unix) FrontPage/5.0.2.2635 mod_throttle/3.1.2 mod_ssl/2.8.18 OpenSSL/0.9.6c icy-name: Curt Cloniger - traveling without moving (5:17) x-audiocast-name: Curt Cloniger - traveling without moving (5:17) X-Powered-By: PHP/4.3.8 Content-Type: audio/mpeg No content-length sent. (dump of actual connection confirms) The only additional header I see in the dump is Transfer-Encoding: chunked (which doesn't get sent when I send the content-length of 0). This would explain the semi-garbled sound - it could be the chunk headers/footers, which probably aren't being handled properly anymore. See http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.6.1
