I was trying to write a script that would convert the xml playlist generated by Amarok to a m3u playlist that can be read by portable media devices.
Along the way I ran into some interesting obstacles, which it make virtually impossible to complete my script as I want.
An m3u playlist file needs the absolute path of a song, and should have the correct length of the song in seconds.
1) Amarok.Playlist.trackAt(i).length or Amarok.Engine.currentTrack().length both return the length of the song, plus 3 extra zeros. I easily cut them off, but why?
2) When Amarok creates a playlist from files on an external device they are stored in the tmp folder, so getting the path from there is pointless. I need the path to the song from the device root, not the path from where the song is stored now while Amarok does its thing.
3) When Amarok copies songs to the tmp folder it somehow screws up the length of the song. They all got the same number, as in all the tracks are theoretically the same length, but as far as I can tell this is a completely random number, and it's huge. It might be the total length of the playlist but I'm not sure.
4) The current API does not include many usable methods that can be called in a script. I had to more or less guess what the calls of the methods might be, or ask people in the forum and IRC chan for help. For example, the two methods I quoted above do not appear in the API.

I don't know much about scripting, but I think that it would be possible to extend the Scripting API to solve some of these issues. And I know you guys are always looking for ways to expand in improve...

1. The length is in milliseconds. Simply divide by 1000 if you need it in seconds.

2. This should only be an issue for MTP devices. The thing is that it is not possible to play back tracks directly from an MTP device, which is why we cache them locally. Unfortunately this means that, for tracks on sch a device, there is no way to export urls that can easily be used by other players.

3. I _think_ this is fixed in more recent version of Amarok, which version are you using?
But see 2. as these tracks are not very useful for your purpose anyway.

4. Better documentation is needed. I seem to remember there being some "object explorer" Amarok 2 script on kde.apps.org that lets you browse available methods.

1) Yeah, that makes sense, having worked with Java and calendar objects (also milliseconds) I don't know why I didn't realize that.
2) So, you're saying I'm screwed? What if I were to use the device in MSC mode?
3) I am using 2.2.2, the latest version. Not fixed, still a problem.
4) If all of the classes are written in JS, why not simply run JSDoc? That will provide a complete API for all of the classes, in a familiar and convenient form. (That is of course assuming that the classes and methods were documented to begin with).

2. In MSC mode it will give you paths to the tracks on the mounted device, so that should work.

3. oh, lets poke xevix about that then!

4. They are not. They are exported from Qt build time. I don't know if it is possible to use JSDoc afterwards though.

2) In MSC mode Amarok refuses to recognize tracks that were placed there, even while doing so in MSC mode. And it refuses to add tracks to the device, claiming "insufficient space" which is a load of BS. There is plenty of space, Amarok is just being contrary.