Bug 114360 - amaroK Feature Request: Support for XSPF Playlist Format
Summary: amaroK Feature Request: Support for XSPF Playlist Format
Status: RESOLVED FIXED
Alias: None
Product: amarok
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: Slackware Linux
: NOR wishlist
Target Milestone: ---
Assignee: Amarok Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-10-13 21:55 UTC by Ivo Gonçalves
Modified: 2006-06-11 12:32 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments
XSPF patch (3.64 KB, patch)
2006-03-28 23:20 UTC, Mattias Fliesberg
Details
XSPF second try (5.21 KB, patch)
2006-03-29 20:43 UTC, Mattias Fliesberg
Details
saveXSPF() (2.47 KB, patch)
2006-03-30 03:09 UTC, Mattias Fliesberg
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ivo Gonçalves 2005-10-13 21:55:06 UTC
Version:           Released separately (amaroK) (using KDE KDE 3.4.2)
Installed from:    Slackware Packages
Compiler:          gcc I can't recall the GCC's version
OS:                Linux

Greetings,

As many should know by now, XSPF is a XML playlist format, open standard, patent free, etc. and is part of the Xiph.org Foundation project of open media formats. And I believe that such a great playlist format should be natively supported by amaroK; both playback and generation of standard .xspf files.

I also assume that developers, and volunteers from the XSPF mailing list (such as I) can try to help as best as possible in this task.
Comment 1 Ian Monroe 2005-10-13 22:41:19 UTC
Whats the advantage over M3U? 

Or do you mean you just want amaroK to have the ability to read XSPF? Is it meant mainly for streams or something?
Comment 2 Ivo Gonçalves 2005-10-13 23:16:05 UTC
>>1

XSPF supports both streams and local files.

Regardings advantages over M3U, the xspf.org site will tell you: 
"Unlike M3U
    XSPF is XML.
Unlike SMIL
    XSPF is simple.
Unlike ASX
    XSPF is open."

This page, http://gonze.com/playlists/playlist-format-survey.html will also give a good idea of why XSPF is the better solution for playlist formats. XSPF can also be converted to other formats (through XSLT apps) in case it's necessary. Regardless, I didn't request to remove M3U support, but to add along-side support for XSPF, so yeah, I meant for amaroK to read them, although if it could generate them it would even be better. I suppose as a first phase we could just have the read option, and later, maybe, the write option.
Comment 3 Lucas Gonze 2005-10-14 01:27:32 UTC
Reasons to support XSPF:

- unix-friendly.  Easy to work with using generic tools like xsltproc, allows console apps to do things like reformat playlists then send them to stdout, allows specialist apps for authoring playlists to interact with specialist apps for rendering playlists.

- good for software freedom.  Open and non-proprietary.

- good for amaroK.  Users need more XSPF players.

- interoperable, unlike M3U.  Lack of canonical documentation means that publishers and consumers interpret M3U in different, incompatible, ways.  For example XMMS expects XML in # comments in a particular format; other players crash on a line longer that 255 chars; filesystem paths sometimes depend on the bogus c:\windows\paths\are\indistinguishable\from\URIs syntax, sometimes depend on the /unix/path syntax, sometimes crash on magnet: URIs, sometimes insist on magnet: URIs, etc.

- eliminates work.  Creating and debugging your own XML playlist format is inevitable for all MP3 players.  Why do it yourself when XSPF already exists?
Comment 4 Ian Monroe 2005-10-14 01:45:55 UTC
Lucas, we've already created our own XML format (just for amaroK's internal use), so too late. Though writing code to a spec takes more debugging regardless.

If someone wants to write a patch for this using QDom we'd accept it. amaroK has (fatally) simplistic playlist handling so it wouldn't be hard. 
Comment 5 Lucas Gonze 2005-10-14 01:53:52 UTC
Own XML format: yup.  :P

What would the QDom object have to look like to amaroK's internal code, Ian?  Would any decent C++ object wrapper for XSPF documents do the job?

Comment 6 Ian Monroe 2005-10-14 10:40:22 UTC
QDom is an API for retrieving information from XML. Or Qt SAX. Seems like for the code to be decent you would have to use an XML library and we can't add any new deps, so that leaves Qt's two methods.

The function PlaylistFile::loadPls would be a relevant example of how it works in amaroK.
Comment 7 Mattias Fliesberg 2006-03-28 23:20:31 UTC
Created attachment 15345 [details]
XSPF patch

I made a simple XSPF playlist loader.. please tell me if it's any good and if
there is any use in continuing developing it :)
Comment 8 Mark Kretschmann 2006-03-28 23:39:12 UTC
I'm just curious: what other players use XSPF?
Comment 9 Mattias Fliesberg 2006-03-28 23:56:02 UTC
Here's a list ... http://www.xspf.org/applications/
Comment 10 Mark Kretschmann 2006-03-29 11:33:42 UTC
The patch looks good, except for the formatting. We don't use tabs in amaroK sources. Please refer to the document amarok/HACKING.
Comment 11 Mattias Fliesberg 2006-03-29 12:34:32 UTC
Yeah.. sorry about that, I read the HACKING doc a little too late :)

Comment 12 Mark Kretschmann 2006-03-29 18:15:55 UTC
Well I'm asking you kindly to make a new patch, cause we can't commit it in this form. Pretty please with icing :)
Comment 13 Mattias Fliesberg 2006-03-29 20:43:35 UTC
Created attachment 15357 [details]
XSPF second try

Here's one that better complies with the HACKING doc :)

I also have started creating a saveXSPF() function...
Comment 14 Mattias Fliesberg 2006-03-30 03:09:20 UTC
Created attachment 15366 [details]
saveXSPF()

Here's a simple save function.
Comment 15 Mark Kretschmann 2006-03-30 10:29:45 UTC
SVN commit 524289 by markey:

    * Support for loading and saving XSPF playlists. Patch by Mattias
      Fliesberg <mattias.fliesberg@gmail.com>.

NOTE: Needs testing.

FEATURE: 114360



 M  +3 -1      ChangeLog  
 M  +62 -0     src/playlist.cpp  
 M  +1 -0      src/playlist.h  
 M  +94 -0     src/playlistloader.cpp  
 M  +3 -1      src/playlistloader.h  
Comment 16 Seb Ruiz 2006-03-30 23:52:39 UTC
Seems fine, although there is one weird thing - Mattias has provided a method 
for saving XSPF playlists, but it is an outcast - it is not actually used 
anywhere!

Or am i missing it?

Seb

On Thursday 30 March 2006 18:29, Mark Kretschmann wrote:
> SVN commit 524289 by markey:
>
>     * Support for loading and saving XSPF playlists. Patch by Mattias
>       Fliesberg <mattias.fliesberg@gmail.com>.
>
> NOTE: Needs testing.
>
> FEATURE: 114360
>
>
>
>  M  +3 -1      ChangeLog
>  M  +62 -0     src/playlist.cpp
>  M  +1 -0      src/playlist.h
>  M  +94 -0     src/playlistloader.cpp
>  M  +3 -1      src/playlistloader.h

Comment 17 Mattias Fliesberg 2006-03-31 11:09:50 UTC
Yeah.. I didn't implement it anywhere because I don't really know what needs to be done to implement it :)
Comment 18 Paulus 2006-04-14 17:20:32 UTC
You can already save in XSPF format: playlist -> Save playlist as and then add the extension xspf to the filename you want to give it.

There are a few problems with the output: the tracknumer is always 113:

    <track>
    <location>file:///home/paulus/remote/data/public/Music/paulus/Artists/Pink/Try%20This/01-pink-trouble.mp3</location>
      <trackNum>113</trackNum>
    </track>

besides it wuold be nice to write the creator and the title of the song too so if the song isn't found on the given location the fuzzy-name lookup can still find the file: http://www.xspf.org/xspf-v1.html#rfc.section.3.5 (<- a feature that would be great to be supported in amarok)