Bugzilla Bug 198820

Audacious does not properly list files in the playlist after closing and
reopening it. It adds "?xspf" to the end of file address.

This happens using libxml-2-2.6.30 and audacious-1.3.2. 

Reproducible: Always

Steps to Reproduce:
1. Add a file to Audacious play list
2. Close Audacious and reopen it
3. Play the file

Please confirm that this is no longer an issue in audacious 1.4.2. Also, any
bug report should include emerge --info, please include it with your reply.

I can confirm that this issue is fixed in audacious-1.4.2. But now that
libxml2-2.6.30 is marked stable I guess audacious-1.3.2 needs to be masked. I'm
sorry I forgot to add my emerge --info:

Portage 2.1.3.19 (default-linux/x86/2006.1/desktop, gcc-4.1.2, glibc-2.6.1-r0,
2.6.22-suspend2-r2 i686)
=================================================================
System uname: 2.6.22-suspend2-r2 i686 Intel(R) Pentium(R) M processor 1.73GHz
Timestamp of tree: Fri, 23 Nov 2007 15:16:01 +0000
ccache version 2.4 [enabled]
app-shells/bash:     3.2_p17
dev-java/java-config: 1.3.7, 2.0.33-r1
dev-lang/python:     2.4.4-r6
dev-python/pycrypto: 2.0.1-r6
dev-util/ccache:     2.4-r7
sys-apps/baselayout: 1.12.9-r2
sys-apps/sandbox:    1.2.18.1-r2
sys-devel/autoconf:  2.13, 2.61-r1
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10
sys-devel/binutils:  2.18-r1
sys-devel/gcc-config: 1.3.16
sys-devel/libtool:   1.5.24
virtual/os-headers:  2.6.22-r2
ACCEPT_KEYWORDS="x86"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-march=pentium-m -O2 -pipe -fomit-frame-pointer"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config
/usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config"
CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/revdep-rebuild
/etc/splash /etc/terminfo /etc/texmf/web2c /etc/udev/rules.d"
CXXFLAGS="-march=pentium-m -O2 -pipe -fomit-frame-pointer"
DISTDIR="/usr/portage/distfiles"
FEATURES="ccache distlocks metadata-transfer parallel-fetch sandbox sfperms
strict unmerge-orphans userfetch"
GENTOO_MIRRORS="http://gentoo.blueyonder.co.uk"
LC_ALL="en_US.UTF-8"
LINGUAS="en_GB"
MAKEOPTS=""
PKGDIR="/usr/portage/packages"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress
--force --whole-file --delete --delete-after --stats --timeout=180
--exclude=/distfiles --exclude=/local --exclude=/packages
--filter=H_**/files/digest-*"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage"
USE="X aac acpi aiglx alsa apm berkdb bitmap-fonts cairo cdr cli cracklib crypt
cups dbus dri dvd dvdr eds emboss encode esd fam fbsplash firefox fortran gdbm
gif glitz gnome gpm gstreamer gtk hal iconv ipv6 isdnlog jpeg ldap mad midi
mikmod mp3 mpeg mudflap ncurses nls nptl nptlonly nsplugin nvidia ogg opengl
openmp oss pam pcre pdf perl png ppds pppd python qt3 qt4 quicktime readline
reflection samba scanner sdl session spell spl ssl svg tcpd truetype
truetype-fonts type1-fonts unicode vorbis win32codecs x86 xcomposite xml xorg
xv zlib" ALSA_CARDS="hda-intel" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix
dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter
mulaw multi null plug rate route share shm softvol" ELIBC="glibc"
INPUT_DEVICES="keyboard mouse synaptics evdev" KERNEL="linux"
LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses
text" LINGUAS="en_GB" USERLAND="GNU" VIDEO_CARDS="nvidia"
Unset:  CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LDFLAGS,
PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS,
PORTDIR_OVERLAY

Could try and go for early stable on 1.4.2 core with 1.4.1 plugins. 1.3 has
been a bit fragile on XML playlist under some circumstances, but it seems as if
this new libxml2 library makes it occur nearly all the time instead of just in
corner cases.

Can you confirm that 1.4 performs as you expect it and that all your music
plays?

it's working fine. The only problem that I have is a reproducible segmentation
fault when I run it from the terminal with the -p switch i.e.

# audacious -p
Segmentation fault

but it could be only my system's fault and it's not really important at all.

*** Bug 200964 has been marked as a duplicate of this bug. ***

(In reply to comment #4)
> it's working fine. The only problem that I have is a reproducible segmentation
> fault when I run it from the terminal with the -p switch i.e. 
> # audacious -p
> Segmentation fault

Thank you for reporting this, this has been resolved in the newest 1.4 releases
(and thus ebuilds). Could you try the newest available Audacious for me?

I haven't had any problem so far with the 1.4.4 version. Thanks for all your
efforts.

Arches, could you please test and mark stable:
media-sound/audacious-1.4.5
media-plugins/audacious-plugins-1.4.4
dev-libs/libmcs-0.6.0
dev-libs/libmowgli-0.5.0

Newer versions of libxml2 wreak havoc on the relatively fragile XSPF playlist
handlers in Audacious 1.3; 1.4 is a lot more robust in this regard. I have
waited until 1.4.5 as there were significant bugfixes queued up each time.
X86 (on which the bug was already reported) has already been done.

Stable for HPPA.

x86, you need also =x11-plugins/wmauda-0.7 because 0.3 is locked down to a old
audacious versions.

x86 stable

ppc and ppc64 done

Libraries seem good for sparc and are stable.
media-sound/audacious-1.4.5 builds and installs on sparc.  However, playback
(with a .wav file for example) is garbled --- sounds sort of like what you
would get with a bad tape or a bad tape player (where the tape does not move
smoothly), or if you played a trumpet under water.

By comparison, with the same test file, vlc does fine.

So please advise, and no sparc for now.

The plugin builds OK, but no keywording action on it until I know more about
why audacious can't play things correctly (it plays them, just wrong).

alpha stable, thanks Tobias

By the way, on this test system, the stable versions are just as bad:
=media-sound/audacious-1.3.2
=media-plugins/audacious-plugins-1.3.3

I'll retest on SB1000 (which is completely current) if I can ever find a
working sound card for it.

Hm, for what it's worth, on one of my amd64 systems, audacious is even worse
than it is on sparc (vlc is fine) with a .wav file.  Now, if there is some
magic needed to build a good version of audacious, it is not apparent from this
bug nor from the ebuilds.  E.g.,
on amd64, audacious-plugins were built with
USE='alsa arts mp3 nls sdl sse2 vorbis wavpack'
and audacious with
USE=nls

Sparc is using the build-in sound card, amd64 a CA0106 (Sound Blaster Audigy).

Ferris, mind trying with USE=sndfile? The default wav plugin isn't fantastic
(and has been discontinued in favour of a reworked sndfile plugin in the 1.5
branch actually).

With USE=sndfile for the audacious-plugins on amd64, at least, audacious fails
completely with .wav files (still white noise).  I'll try sparc tomorrow.

By the way, .mp3 is fine on amd64; I'll verify on sparc that also.

I used .wav for my test because man page said audacious could handle it and I
had a couple lying around from other tests (vlc).

All done for sparc.  Note that for me, audacious cannot handle .wav files on
sparc (and it's worse on amd64, for that matter), even with USE=sndfile. 
However, it looks as if it has never done very well with them, and other
formats (like .mp3) seem fine.

With Tony's (and others') help, we've tracked this down to a file format
audacious does not like (DTS).  I looked around for other .wav files on my
system, and found one that audacious handles just fine.  So I guess my problems
can be called "user error", and everything looks good on sparc now.

amd64 stable