24th June 2005 at 3:48 am #70
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?24th June 2005 at 4:38 am #3432jkpGuest
/me raises his hand in support of the request as well 🙂25th June 2005 at 6:58 am #3433
The .playlist file isn’t coming back. It’s been replaced by sql queries.
I’m figuring it out, though… it’s just slow.
— Ron25th June 2005 at 11:16 pm #3434jholtGuest
Further out, I was thinking it might be cool to be able to view a playlist (read-only) with a URL, such as …/playlist/.27th June 2005 at 10:13 am #3435
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?30th June 2005 at 6:11 pm #3436jholtGuest
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 @[email protected] 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.
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.
— Ron15th July 2005 at 11:11 pm #3438
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…16th July 2005 at 11:13 am #3439
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.3rd October 2005 at 8:26 am #3440
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.27th October 2005 at 10:52 am #3441
Should work. You’ll need to disconnect and reconnect with iTunes, though.
Somewhere, I lost the magic “supports updates” flag, and it’s not updating. That’s okay, though, because I really need to figure out the incremental update format. Playlists are problematic without it.
Soundbridge recognizes it immediately, though. Another reason the Soundbridge is awesome.
And on sqlite, it’s “select * from songs order by random()”
- The forum ‘Feature Requests’ is closed to new topics and replies.