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.
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?
>>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.
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?
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.
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?
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.
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 :)
I'm just curious: what other players use XSPF?
Here's a list ... http://www.xspf.org/applications/
The patch looks good, except for the formatting. We don't use tabs in amaroK sources. Please refer to the document amarok/HACKING.
Yeah.. sorry about that, I read the HACKING doc a little too late :)
Well I'm asking you kindly to make a new patch, cause we can't commit it in this form. Pretty please with icing :)
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...
Created attachment 15366 [details] saveXSPF() Here's a simple save function.
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
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
Yeah.. I didn't implement it anywhere because I don't really know what needs to be done to implement it :)
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)