Pat Farrell
2004-07-21, 14:03
At 03:02 PM 7/21/2004, Eric Koldinger <kolding (AT) alum (DOT) berkeley.edu> wrote:
>From: Eric Koldinger <kolding (AT) alum (DOT) berkeley.edu>
>This is something I've been interested in doing for a while. I've wanted
>to add "Browse by Composer", "Browse by Orchestra", whatnot.
>The actual code that does the cataloging is down in
>server/Slim/Music/Info.pm. The songs are all brought in and stored in a
>great big perl hash, and accesssed via some query functions in here.
>Unfortunately, I haven't been able to get a handle on how things work.
I too have spent some time in that code, for the same reason.
> If I can get a reasonable explanation of the structures and how they're
> accessed, I'll gladly work on this. I just fear it might involve
> rewriting the entire Info.pm module.
I believe that it will require a complete rewrite of Info.pm.
I could be wrong, but I'm pretty sure.
The approach I'd take would be to generate a unique songID from
the contents of the audio bytes, run thru SHA1 and maybe chopped shorter.
That is the key to the song, which drives a couple of hashtables
with KEY -> path
and others with Title -> key, Artist -> key, etc.
Then it is trivial to replace the backing store with a nice free relational
DBMS like
MySql. Or whatever you want to use.
Simply ripping out the perl database and using a relational table
the same way is not worth the effort, IMHO.
I expect this to be a lot of work, and it will break a lot of other modules
that
use Info.pm, as it doesn't have a well isolated API design, more organic,
which I can understand how it got there.
Pat
>From: Eric Koldinger <kolding (AT) alum (DOT) berkeley.edu>
>This is something I've been interested in doing for a while. I've wanted
>to add "Browse by Composer", "Browse by Orchestra", whatnot.
>The actual code that does the cataloging is down in
>server/Slim/Music/Info.pm. The songs are all brought in and stored in a
>great big perl hash, and accesssed via some query functions in here.
>Unfortunately, I haven't been able to get a handle on how things work.
I too have spent some time in that code, for the same reason.
> If I can get a reasonable explanation of the structures and how they're
> accessed, I'll gladly work on this. I just fear it might involve
> rewriting the entire Info.pm module.
I believe that it will require a complete rewrite of Info.pm.
I could be wrong, but I'm pretty sure.
The approach I'd take would be to generate a unique songID from
the contents of the audio bytes, run thru SHA1 and maybe chopped shorter.
That is the key to the song, which drives a couple of hashtables
with KEY -> path
and others with Title -> key, Artist -> key, etc.
Then it is trivial to replace the backing store with a nice free relational
DBMS like
MySql. Or whatever you want to use.
Simply ripping out the perl database and using a relational table
the same way is not worth the effort, IMHO.
I expect this to be a lot of work, and it will break a lot of other modules
that
use Info.pm, as it doesn't have a well isolated API design, more organic,
which I can understand how it got there.
Pat