PDA

View Full Version : browse genre/artist in levels (enhancement?)



Simon Oosthoek
2005-01-09, 14:20
Hi all

My GF and I just had a discussion which may turn out to be a feature request
(if so, I'll add it to the bugzilla, if it's a new idea)

The problem is, we have slightly different tastes is music (which is
probably quite normal ;-). So we have a common music folder, and one for
each of us for the stuff the other doesn't like. We also have a folder for
new stuff and one for dodgy music.

When the parent folder is the music folder according to slimserver, all
music is put in the database and mixed together. So when you browse genres
or artists, it's hard to quickly find what you're looking for.

It would therefore be nice to have a way to add something like levels or
groups in the browse function to be able to browse a subset of all the
music, without having to drop some stuff outside the slimserver realm...

I hope I'm expressing myself clearly ;-)

Say the music folder is /music
and there are folders:
/music/me
/music/her
/music/us
/music/dodgy
/music/new

if this would be in levels, I'd like it to be thus:
/music/me (level2)
/music/her (level2)
/music/us (level1)
/music/dodgy (level3)
/music/new (level1)

or if it was in groups, the names of the folders would do nicely, with an
additional group "all" or something...

I don't think this is currently possible with the software, is it?

Cheers

Simon

Robin Bowes
2005-01-09, 15:08
Simon Oosthoek wrote:
> Hi all
>
> My GF and I just had a discussion which may turn out to be a feature request
> (if so, I'll add it to the bugzilla, if it's a new idea)
>
> The problem is, we have slightly different tastes is music (which is
> probably quite normal ;-). So we have a common music folder, and one for
> each of us for the stuff the other doesn't like. We also have a folder for
> new stuff and one for dodgy music.
>
> When the parent folder is the music folder according to slimserver, all
> music is put in the database and mixed together. So when you browse genres
> or artists, it's hard to quickly find what you're looking for.
>
> It would therefore be nice to have a way to add something like levels or
> groups in the browse function to be able to browse a subset of all the
> music, without having to drop some stuff outside the slimserver realm...
>
> I hope I'm expressing myself clearly ;-)

Hi,

I'd actually find something like that useful too.

Most of my music I have carefully ripped and tagged in .flac format, but
I also have a large repository of mp3s taken from a friend's iPod which
contins some interesting music but is of questionable quality (128kbps,
CBR, missing tags, wrongly spelled names, etc.). Additionally, I also
have a Classical repository and a "torrents" repository.

Sometimes I'd like to just search *my* music, i.e. just the flac files.
I guess a "file type" filter or parameter would achieve the same result
in my case, but I can understand your requirement and can envisage
wanting the same sort of thing. I'm not sure what the solution would be,
though!

R.
--
http://robinbowes.com

kdf
2005-01-09, 15:28
Quoting Robin Bowes <robin-lists (AT) robinbowes (DOT) com>:


> I'd actually find something like that useful too.
>
> Most of my music I have carefully ripped and tagged in .flac format, but
> I also have a large repository of mp3s taken from a friend's iPod which
> contins some interesting music but is of questionable quality (128kbps,
> CBR, missing tags, wrongly spelled names, etc.). Additionally, I also
> have a Classical repository and a "torrents" repository.
>
> Sometimes I'd like to just search *my* music, i.e. just the flac files.
> I guess a "file type" filter or parameter would achieve the same result
> in my case, but I can understand your requirement and can envisage
> wanting the same sort of thing. I'm not sure what the solution would be,
> though!

it would seem entirely possible to provide a much more extensive search form in
the future (after the db stuff matures). I think we'd still have to rely on
some sort of information in the tagging. Having slimserver modify audio files
has never been well recieved. However, marking tags in some way, we could
easily search based on any terms you wanted to have in any supported searchable
tag.

-kdf

Jack Coates
2005-01-09, 15:29
Simon Oosthoek wrote:
> Hi all
>
> My GF and I just had a discussion which may turn out to be a feature request
> (if so, I'll add it to the bugzilla, if it's a new idea)
>
> The problem is, we have slightly different tastes is music (which is
> probably quite normal ;-). So we have a common music folder, and one for
> each of us for the stuff the other doesn't like. We also have a folder for
> new stuff and one for dodgy music.
>
> When the parent folder is the music folder according to slimserver, all
> music is put in the database and mixed together. So when you browse genres
> or artists, it's hard to quickly find what you're looking for.
>
> It would therefore be nice to have a way to add something like levels or
> groups in the browse function to be able to browse a subset of all the
> music, without having to drop some stuff outside the slimserver realm...
>
> I hope I'm expressing myself clearly ;-)
>
> Say the music folder is /music
> and there are folders:
> /music/me
> /music/her
> /music/us
> /music/dodgy
> /music/new
>
> if this would be in levels, I'd like it to be thus:
> /music/me (level2)
> /music/her (level2)
> /music/us (level1)
> /music/dodgy (level3)
> /music/new (level1)
>
> or if it was in groups, the names of the folders would do nicely, with an
> additional group "all" or something...
>
> I don't think this is currently possible with the software, is it?
>
> Cheers
>
> Simon

Not currently, but this is the sort of thing that the SQL back end will
excel in -- adding new attributes and searching on them will be fairly
easy once that's in place.

--
Jack at Monkeynoodle dot Org: It's a Scientific Venture...
Riding the Emergency Third Rail Power Trip since 1996!

Jack Coates
2005-01-09, 15:32
kdf wrote:
> Quoting Robin Bowes <robin-lists (AT) robinbowes (DOT) com>:
>
>
>
>>I'd actually find something like that useful too.
>>
>>Most of my music I have carefully ripped and tagged in .flac format, but
>>I also have a large repository of mp3s taken from a friend's iPod which
>>contins some interesting music but is of questionable quality (128kbps,
>>CBR, missing tags, wrongly spelled names, etc.). Additionally, I also
>>have a Classical repository and a "torrents" repository.
>>
>>Sometimes I'd like to just search *my* music, i.e. just the flac files.
>>I guess a "file type" filter or parameter would achieve the same result
>>in my case, but I can understand your requirement and can envisage
>>wanting the same sort of thing. I'm not sure what the solution would be,
>>though!
>
>
> it would seem entirely possible to provide a much more extensive search form in
> the future (after the db stuff matures). I think we'd still have to rely on
> some sort of information in the tagging. Having slimserver modify audio files
> has never been well recieved. However, marking tags in some way, we could
> easily search based on any terms you wanted to have in any supported searchable
> tag.
>
> -kdf

a devel discussion, but I'm imagining a table of custom attributes
indexed by song_id.

--
Jack at Monkeynoodle dot Org: It's a Scientific Venture...
Riding the Emergency Third Rail Power Trip since 1996!

kdf
2005-01-09, 15:39
Quoting Jack Coates <jack (AT) monkeynoodle (DOT) org>:


> a devel discussion, but I'm imagining a table of custom attributes
> indexed by song_id.

seem to me to be a lot more overhead, and the complexity of then adding every
attribute that gets requested/votebombed. but, yes, its possible. at some
point, however, it just has to stop trying to do everything and make better use
of what is already available.

-kdf

Jack Coates
2005-01-09, 15:52
kdf wrote:
> Quoting Jack Coates <jack (AT) monkeynoodle (DOT) org>:
>
>
>
>>a devel discussion, but I'm imagining a table of custom attributes
>>indexed by song_id.
>
>
> seem to me to be a lot more overhead, and the complexity of then adding every
> attribute that gets requested/votebombed. but, yes, its possible. at some
> point, however, it just has to stop trying to do everything and make better use
> of what is already available.
>
> -kdf

I should clarify that I'm imagining a user-specific feature, or
implementation as a plugin; you're right, inclusion as a mainline
feature would be bad.

--
Jack at Monkeynoodle dot Org: It's a Scientific Venture...
Riding the Emergency Third Rail Power Trip since 1996!

Robin Bowes
2005-01-09, 15:52
kdf wrote:
> Quoting Jack Coates <jack (AT) monkeynoodle (DOT) org>:
>
>>a devel discussion, but I'm imagining a table of custom attributes
>>indexed by song_id.
>
> seem to me to be a lot more overhead, and the complexity of then adding every
> attribute that gets requested/votebombed. but, yes, its possible. at some
> point, however, it just has to stop trying to do everything and make better use
> of what is already available.

As Jack says, a devel discussion, but this is relatively trivial to do
with a well-designed relational back-end. I posted a proposed structure
to the devel list some time ago that allowed for *any* sort of attribute
to be associated with a track.

Of course, to do it properly would require an interface to tag tracks,
plus some way to manage tags. Of course, these would need to be
persistent over re-builds of the database. That could be a challenge.

Let's take this to devel.

R.

Simon Oosthoek
2005-01-09, 16:37
On Sun, Jan 09, 2005 at 02:28:12PM -0800, kdf wrote:
> Quoting Robin Bowes <robin-lists (AT) robinbowes (DOT) com>:
>
>
> > I'd actually find something like that useful too.
> >
> > Most of my music I have carefully ripped and tagged in .flac format, but
> > I also have a large repository of mp3s taken from a friend's iPod which
> > contins some interesting music but is of questionable quality (128kbps,
> > CBR, missing tags, wrongly spelled names, etc.). Additionally, I also
> > have a Classical repository and a "torrents" repository.
> >
> > Sometimes I'd like to just search *my* music, i.e. just the flac files.
> > I guess a "file type" filter or parameter would achieve the same result
> > in my case, but I can understand your requirement and can envisage
> > wanting the same sort of thing. I'm not sure what the solution would be,
> > though!
>
> it would seem entirely possible to provide a much more extensive search form in
> the future (after the db stuff matures). I think we'd still have to rely on
> some sort of information in the tagging. Having slimserver modify audio files
> has never been well recieved. However, marking tags in some way, we could
> easily search based on any terms you wanted to have in any supported searchable
> tag.

I was thinking more along the lines of adding multiple music folders to the
slimserver configuration, each with a certain level or group. (that would
mean an additional field per music folder and a new empty one every time you
add a new folder)

so this would be fairly trivial to add to the scanning code I (naively)
think ;-)

This way, no modifications to tags are necessary, since the information is
only in the configuration and the database with file-info (produced in the
scanning process)

Anyway, I'm not a developer, but I don't see much complication here ;-)

Cheers

Simon

kdf
2005-01-09, 16:46
Quoting Simon Oosthoek <simon (AT) margo (DOT) student.utwente.nl>:


> I was thinking more along the lines of adding multiple music folders to the
> slimserver configuration, each with a certain level or group. (that would
> mean an additional field per music folder and a new empty one every time you
> add a new folder)
>
> so this would be fairly trivial to add to the scanning code I (naively)
> think ;-)

I'm actually working on bug607, which adds the ability to have multiple music
folders. Adding to the scanner is easy. Handling it from there is murder
because of the extensive fingers of code that depend on how its been handled so
far. Its not conducive to branching off from the musicfolder. Regardless of
fixing this, however, it still merged into the sing virtual source. That would
have to come later.

-kdf