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