PDA

View Full Version : feedback on standalone search/playlist tool idea?advanced_search.xml ?



Peter Watkins
2005-02-10, 21:09
Folks,

Before I start coding, I'd like feedback on a new Perl scrpt --
especially because it depends on features not yet in 6.0. ;-)

I just ordered a flash-RAM-based MP3 player and would like to have my
computer load a mix of music on the player each morning before I head to
work. I'm thinking something like the iPod Shuffle model: some mornings
I'll want to grab a certain band or genre, and some mornings I might
just want a random mix of stuff.

I imagine two tools:
1) a script to query SlimServer and produce a .m3u playlist file of
tracks that are compatible with the device (e.g., .mp3 but not .ogg)
2) a script to retrieve a playlist's files and copy them to the device

The second script is not SlimServer specific, so let's ignore that.

The first script's usage would be something like this:
slimplaylist --genre jazz --random --music-format mp3 --maxsize 400MB

The script would then communicate with SlimServer, find all the Jazz
songs that are in MP3 format, and start building the playlist, picking
individual songs at random until just before the total filesize reached
400 megabytes.

With SlimServer, the only real search interface seems to be the web
interface, and clearly the XML skin would be the way to go, right?

It looks like the SlimServer 6.0 advanced search offers most of what I
would like in the search API[0] -- but there doesn't seem to be an XML
interface corresponding to /advanced_search.html. Is anyone working on
such an interface?

With advanced search, there are two things I'd like to see beyond what
seems to be in the 6.0 code:

First, some sort of "order by" option that included a "random" option:
if I have 40 GB of music and only 250 MB on my player, there's no sense
in the "slimplaylist" tool having to parse XML for thousands of songs so
that it can grab a random hundred.

Second, I'd like to see more information about individual tracks in the
/xml/advanced_search.xml data than is current /xml/search.xml --
something more like what's in /xml/songinfo.xml

-Peter

[0] It'd be nice to have some "not" operators on most fields, e.g.
specify all but a certain genre:
+format:MP3 -genre:holiday
or to specify a field more than once, e.g.
+artist:"The Band" -artist:"Neil Diamond"
to get songs by The Band that Neil Diamond doesn't appear in or
+artist:"The Band" +artist:Dylan
to get only songs in which Bob Dylan sat in with The Band.

Roy M. Silvernail
2005-02-10, 21:56
Peter Watkins wrote:

> I imagine two tools:
> 1) a script to query SlimServer and produce a .m3u playlist file of
> tracks that are compatible with the device (e.g., .mp3 but not .ogg)

With 6.0 on a SQL base, wouldn't it make sense to build a SQL report
generator to build your playlists?

> It looks like the SlimServer 6.0 advanced search offers most of what I
> would like in the search API[0] -- but there doesn't seem to be an XML
> interface corresponding to /advanced_search.html. Is anyone working on
> such an interface?
>
> With advanced search, there are two things I'd like to see beyond what
> seems to be in the 6.0 code:
>
> First, some sort of "order by" option that included a "random" option:
> if I have 40 GB of music and only 250 MB on my player, there's no
> sense in the "slimplaylist" tool having to parse XML for thousands of
> songs so that it can grab a random hundred.
>
> Second, I'd like to see more information about individual tracks in
> the /xml/advanced_search.xml data than is current /xml/search.xml --
> something more like what's in /xml/songinfo.xml

This is what I mean. Instead of using SlimServer as your intermediary,
query the database directly. Your queries can be arbitrarily complex
and rich without trying to shoehorn your needs into SlimServer. You can
have all the NOT operators you want.

That's what I see as the beauty of the DB foundation. Where SlimServer
used to *be* the database, now it's just a client that controls my
Squeezebox. I can hit the DB directly for custom queries and assemble
any arbitrary output format I need. Makes for much lighter-weight
ancilliary apps like the one you're envisioning.

--
Roy M. Silvernail is roy (AT) rant-central (DOT) com, and you're not
"It's just this little chromium switch, here." - TFT
SpamAssassin->procmail->/dev/null->bliss
http://www.rant-central.com

Peter Watkins
2005-02-11, 07:04
On Thu, Feb 10, 2005 at 11:56:16PM -0500, Roy M. Silvernail wrote:
> Peter Watkins wrote:

> > 1) a script to query SlimServer and produce a .m3u playlist file of
> > tracks that are compatible with the device (e.g., .mp3 but not .ogg)
>
> With 6.0 on a SQL base, wouldn't it make sense to build a SQL report
> generator to build your playlists?

Roy, first, thank you for your feedback.

Maybe, though that also means a duplication of effort (SQL code in 2 places).

> > It looks like the SlimServer 6.0 advanced search offers most of what I
> > would like in the search API[0] -- but there doesn't seem to be an XML
> > interface corresponding to /advanced_search.html. Is anyone working on
> > such an interface?
> >
> > With advanced search, there are two things I'd like to see beyond what
> > seems to be in the 6.0 code:
> >
> > First, some sort of "order by" option that included a "random" option:
> > if I have 40 GB of music and only 250 MB on my player, there's no
> > sense in the "slimplaylist" tool having to parse XML for thousands of
> > songs so that it can grab a random hundred.
> >
> > Second, I'd like to see more information about individual tracks in
> > the /xml/advanced_search.xml data than is current /xml/search.xml --
> > something more like what's in /xml/songinfo.xml
>
> This is what I mean. Instead of using SlimServer as your intermediary,
> query the database directly. Your queries can be arbitrarily complex
> and rich without trying to shoehorn your needs into SlimServer. You can
> have all the NOT operators you want.

True. This is something of another thread, but for a while now I've wanted
a more expansive search vocabulary so that SlimServer could offer what might
be called "mood filters" -- a set of search phrases that could be automatically
added to any user search to filter what's shown. For instance, my wife would
probably appreciate filters to hide "guy" music like Primus and Metallica, and
we both might like filters like "hifi" to filter out lower-bitrate tracks. Mood
filters would most likely be associated with Squeezebox devices, and I think
they should probably be additive: a player could enable as many as it wished.

Technically, the mood filters would be straighforward: each search or browse
operation would begin as a fielded string, e.g. browse albums might be
displayby:album order:alpha
Each mood filter would be a separate string. Any time a player browsed/searched,
the SlimServer SQL preprocessor would concatenate the mood filters with the
"search" string. So you'd end up with a field: phrase like this for browsing
albums with the "no guy music" filter enabled:
-artist:Primus -artist:Metallica displayby:album order:alpha

So I might always have the "hifi" filter enabled on the Squeezebox used on the
nice stereo system to keep it from offering me the web downloads that sound
rotten on the nice speakers, and selectively enable other filters at other times.

I also think that a +/ field: grammer allows for a cleaner search interface:
see how Google's simple text input has decimated the more complex search forms
of engines like, IIRC, the original HotBot. Slim's web UI could still offer a nicely
formatted advanced search for users who like that (or simply don't want to
memorize the field: vocabulary) while empowering the basic search for users
who'd rather type than tab and mouse around. Field: search could even be done
on a Squeezebox device, though the text input is tedious enough that some field:
shorthand would probably be required, and even then might not be very usable.

> That's what I see as the beauty of the DB foundation. Where SlimServer
> used to *be* the database, now it's just a client that controls my
> Squeezebox. I can hit the DB directly for custom queries and assemble
> any arbitrary output format I need. Makes for much lighter-weight
> ancilliary apps like the one you're envisioning.

True. And since my app was intended to run on the same system as SlimServer,
that might make more sense.

Thank you,

Peter

Fred
2005-02-11, 07:21
> That's what I see as the beauty of the DB foundation. Where SlimServer
> used to *be* the database, now it's just a client that controls my
> Squeezebox. I can hit the DB directly for custom queries and assemble
> any arbitrary output format I need. Makes for much lighter-weight
> ancilliary apps like the one you're envisioning.

From a testing & opensource point of view, I do agree.

From a SlimServer product point of view, this is really something to be
decided by Dean & gang. Allowing/encouraging direct DB access means the DB
becomes yet another published API of the SlimServer, with the restrictions
this imposes on changes between releases, documentation, etc. In practice, it
is pretty restrictive in terms of clients: you need something that knows how
to talk to a DB directly and most thin devices out there can't do that (and
therefore you need to duplicate the access layer effort, i.e. for example do
something that accesses the DB directly to offer an HTTP/XML interface).

I am not advocating one thing or another, just saying that there are
implications to ponder when entertaining the idea of using the SlimServer DB
directly.

Dean, what's SlimDevices opinion on this?

Fred

kdf
2005-02-11, 14:13
Quoting Fred <fred (AT) thomascorner (DOT) com>:

> > That's what I see as the beauty of the DB foundation. Where SlimServer
> > used to *be* the database, now it's just a client that controls my
> > Squeezebox. I can hit the DB directly for custom queries and assemble
> > any arbitrary output format I need. Makes for much lighter-weight
> > ancilliary apps like the one you're envisioning.
>
> >From a testing & opensource point of view, I do agree.
>
> >From a SlimServer product point of view, this is really something to be
> decided by Dean & gang. Allowing/encouraging direct DB access means the DB
> becomes yet another published API of the SlimServer, with the restrictions
> this imposes on changes between releases, documentation, etc.

or...its open source, use it at will but also at your own risk :)

>In practice, it
> is pretty restrictive in terms of clients: you need something that knows how
> to talk to a DB directly and most thin devices out there can't do that (and
> therefore you need to duplicate the access layer effort, i.e. for example do
> something that accesses the DB directly to offer an HTTP/XML interface).
>
> I am not advocating one thing or another, just saying that there are
> implications to ponder when entertaining the idea of using the SlimServer DB
> directly.

Probably more of an issue for the author to decide if its worth the risk.
Documentation, as always, is in the code. The response to those who jump up
and down to be handed a formal document is always the same, write one up it
will be posted for the benefit of all or eventually someone will post something
:)

of course, this is the unofficial opinion ;)

-kdf