When do we get playlists back?

[Mike]

For those of us that aren’t sharing an iTunes folder but instead just a directory(s) of mp3 files to iTunes clients, can we get our mt-daapd.playlist support back?

[jkp]

/me raises his hand in support of the request as well 🙂

[rpedde]

The .playlist file isn’t coming back. It’s been replaced by sql queries.

Unfortunately, the progress on the replacement is slow. Mostly because I’m not a web developer. I don’t know javascript very well, so I’m learning as I go along.

That, and there is no decent javascript development environment — debuggers suck, there is no stable feature set across browsers, and leveling libraries aren’t mature yet.

I’m figuring it out, though… it’s just slow.

— Ron

[jholt]

Ron, are you talking about the web interface to playlists? Perhaps this is something I can work on. I know JavaScript, and I’m working on something similar for the Library browser. I was wondering what that dead playlist page was all about…

Further out, I was thinking it might be cool to be able to view a playlist (read-only) with a URL, such as …/playlist/.

[rpedde]

Yeah, I’ve played with the stuff too, and it’s tough to get something that works on safari, ff and ie.

the smart.html file is mine — it was going to be where I started working on a sql parser.

Right now, the smart playlists are actually sql “where” clauses, but it occurs to me that it won’t be very portable, plus there are some things that are difficult to do with sql. (randomized playlists, for example).

So I’ve started to think that perhaps the smart playlists as stored in the database should be some kind of database-neutral specification (kind of like the old .playlist file) that gets turned into a database-specific query.

So I’ve come full circle on this one. I’m starting to think now that the .playlist concept might be kind of the way to go, only with the .playlist spec stored in the database.

Opinions?

[jholt]

I’m not deep-enough into the playlist fu to have a strong opinion on the smart playlist implementation, but what you’re suggesting sounds reasonable. My interest in playlists is mostly of the static variety — for example, a music professor can create a playlist of required listening for a class. The web interface should be simple.

I’m familiar with cross-browser issues when coding up dynamic html. My motto is to keep it simple. I’ve got a working mock-up of a three list library browser much like iTunes (artist, album, tracks). The lists update dynamically as artists and albums are selected. I say mock-up because I’m populating it with faked library data for now. But I understand the @blah@ hooks and it’s close to working with real data.

Something I’ve been puzzling over is whether to use http xml requests to update the page, once editing is in place. This is all the rage, but I haven’t much experience with it. And heck, when I think about it, it sounds like it overlaps the daapd protocol. A lot.

1. User browses library.
2. User changes the name of a track. Implemented as client-side javascript doing a POST.
3. Page picks up changes. Implemented as client-side javascript making an xml request to mt-daapd for updated artist / album info.

Would it be possible to use the javascript xml requests to hook into daapd? I don’t know enough yet to say. But hey, it would be killing several birds with one stone, and making possible a whole range of client-side browser functionality.

[rpedde]

Look on the nightlies page — there is a comment that points to the last “old style” mt-daapd.

Feb 5th or so, I think.

As far as removing old before replacing — that’s why it’s developer code. That’s part of the trade-off. Deal.

— Ron

[Mike]

Maybe this is ridiculous, but why not have multiple ways of doing playlists? A .playlist file for static (or smart) playlists that gets parsed at startup and turn into whatever sql fu necessary to create playlists. Then, a web based way of managing playlists more on-the-fly so to say, so that you can create whatever mix you happen to want to hear at that exact moment.

I realize that it’s more work than choosing one or the other, but it would also be the best of both worlds…

[rpedde]

Except that every new way to do playlists makes the code more complex. Part of the attraction of moving to a sql backend and sql-based playlists is that somewhere around 40% of the code just disappeared. That’s attractive.

Simple is more bug free. So I like that aspect of it.

The other thing is that I want to move all this stuff into the database. So I think it will end up being something of a compromise — something like the old .playlist file, but the spec stored in the database, rather than in a file, that way it can get re-parsed every time it gets requested, and things like “most recently played” get updated in realtime, rather than whenever mt-daapd starts.

By putting it in the database, it eliminates a whole series of misfeatures that plagued the .playlist implementation.

There will always be a way to do smart playlists, as that’s all I use. So I need to have it for me, if nothing else.

Anyway, I guess that’s how I see it going.

[Mike]

So, with direct-to-AirTunes support presumably in the near future, I think this discussion needs a bump. An obvious extension of the whole web based library navigator/playlist creator is the ability to push it to a given AirTunes client.
I was just exploring the Playlist page, and I see that it does load my playlist (took a few minutes, 18,000+ songs), but the genre/artist/album sections collapse as soon as I click in them. I’m using ff on mac os x tiger.
All in all though, one of my favorite pieces of software.

[Author]

Posts