Your message dated Sat, 11 Apr 2009 15:38:19 +0200
with message-id <[email protected]>
and subject line Re: audacious: doesn't handle playlists with relative paths
well
has caused the Debian Bug report #479106,
regarding audacious: doesn't handle playlists with relative paths well
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
479106: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=479106
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: audacious
Version: 1.4.6-2
Severity: normal
Hi,
Audacious fails to locate files referred in XSPF playlists when the
XML:base attribute is missing from said playlists and relative paths are
used.
Example, there are 2 files, "song1.mp3" and "song2.mp3", in a directory.
In this same directory there is an XSPF playlist file whose contents is:
<?xml version="1.0" encoding="UTF-8"?>
<playlist version="1" xmlns="http://xspf.org/ns/0/";>
<trackList>
<track>
<location>song1.mp3</location>
</track>
<track>
<location>song2.mp3</location>
</track>
</trackList>
</playlist>
If opened with audacious, this list will fail to play because audacious
doesn't seem to be able to find out where these files are located.
In my opinion, audacious should look in the same location where the
playlist is in order to find the files when no absolute paths are given.
This is the behaviour that dictates the XSPF spectification [1], if I
understand correctly, and this is what audacious already does with M3U
playlist (it's common sense, anyway).
[1] http://xspf.org/xspf-v1.html#rfc.section.6.2
-- System Information:
Debian Release: lenny/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.24-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=ca_ES.UTF-8, LC_CTYPE=ca_ES.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages audacious depends on:
ii audacious-plugins 1.4.4-1 Base plugins for audacious
ii dbus 1.2.1-1 simple interprocess messaging syst
ii gtk2-engines-pixbuf 2.12.9-2 Pixbuf-based theme for GTK+ 2.x
ii libatk1.0-0 1.22.0-1 The ATK accessibility toolkit
ii libaudclient1 1.4.6-2 audacious dbus remote control libr
ii libc6 2.7-10 GNU C Library: Shared libraries
ii libcairo2 1.4.14-1 The Cairo 2D vector graphics libra
ii libdbus-1-3 1.2.1-1 simple interprocess messaging syst
ii libdbus-glib-1-2 0.74-2 simple interprocess messaging syst
ii libglade2-0 1:2.6.2-1 library to load .glade files at ru
ii libglib2.0-0 2.16.1-2 The GLib library of C routines
ii libgtk2.0-0 2.12.9-2 The GTK+ graphical user interface
ii libmcs1 0.7.0-1 Abstraction library to store confi
ii libmowgli1 0.6.1-1 a high performance development fra
ii libpango1.0-0 1.20.2-2 Layout and rendering of internatio
ii libsamplerate0 0.1.3-1 audio rate conversion library
ii libx11-6 2:1.0.3-7 X11 client-side library
ii libxml2 2.6.32.dfsg-2 GNOME XML library
Versions of packages audacious recommends:
ii audacious-plugins-extra 1.4.4-1 Various extra plugins for audaciou
ii unzip 5.52-11 De-archiver for .zip files
-- no debconf information
--- End Message ---
--- Begin Message ---
10/04/09 @ 02:23 (-0400), thus spake John Lindgren:
> Apparently, the bug has already been fixed in upstream revision 2665.
>
> http://atheme.org/repositories/changes/audacious-plugins/src/xspf/xspf.c
Thanks, John.
I confirm it's fixed. I'm closing this bug now.
Ernest
--- End Message ---
