The UK Home Automation Archive

Archive Home
Group Home
Search Archive


Advanced Search

The UKHA-ARCHIVE IS CEASING OPERATIONS 31 DEC 2024


[Message Prev][Message Next][Thread Prev][Thread Next][Message Index][Thread Index]

Re: Some thoughts on xplmedianet and how to implement


  • Subject: Re: Some thoughts on xplmedianet and how to implement
  • From: "Malcolm Lansell" <mlansell@xxxxxxxxxxxxxx>
  • Date: Fri, 11 Mar 2005 10:13:48 -0000
  • References: <FRNT2136DEF6E4@frontier.co.uk>



----- Original Message -----
From: "Tony Tofts" <tony@xxxxxxx>
To: <ukha_xpl@xxxxxxx>
Sent: Friday, March 11, 2005 8:55 AM
Subject: RE: [ukha_xpl] Some thoughts on xplmedianet and how to implement


>
>> For example, if I request music of the "R&B" genre,
with a level
>> of detail of "artist", the core would return the data
containing a list
>> of
>
>> R&B artists as the top menu layer
>
> How do we know if an album/artist is of a particular genre
>
> Using the track tags would be very dangerous, since many albums by the
> same
> artist have different genre on the tracks - and what about
compilations?
>
> Also, if we did it on the fly how long will it take to process 30,000
to
> 50,000+ tracks to get at this information each time?
>

An album would be assigned to the genre of whatever its tracks are - even
if
that means tagging it with more than one genre (although I don't know if
that is currently possible with your structure).  In practice most tracks
from an album will be all the same genre.  The same goes for artist -
combine the genres of the albums to get the genres of the artist.

As for processing, I would hope that the scanner won't have to scan every
track each time - perhaps an "add album" feature so that new
music can be
added without the need for a scan?  BTW, what was the outcome of the
file-watcher suggestion a while back?

For me the issue boils down to how I access my music.  I never liked using
the xplRioNet database because of all the scanning, and because listing
tracks by artist or genre resulted in huge lists of track names that gave
me
no idea which artist or album they came from.  With a large collection,
listing all the "rock - pop" tracks is not helpful - keeping them
grouped by
artist & album is much more logical and easier to manage, IMO.

However...

In all honesty, I personally won't need any of this, if (and it might be a
big if) the clients can be made to play music without needing to reference
the database.  I can knock up some intranet pages to allow access to my
collection, with links triggering xPL "play" messages (I've been
thinking of
writing a php extension for this).

My collection is already organised by genre, artist and album through its
folder hierarchy (which I suppose is how my suggestion for search by genre
would end up).  If I understand the new xPLMediaNet design correctly, the
database module is separate from the core, and is used just to support
other
modules that provide a user interface for media selection.  In that case it
should be possible for me to install the core, and not worry about the
database stuff at all.  If that's not the case, then perhaps it should be -
unless I'm missing something about the database that makes it essential.

Now, I may have set up an intranet, but most other users have not, and
don't
want the hassle anyway.  The reason I'm advocating changes to the database
search (to group by artist and album) is for those other users rather than
myself - I'm sure I'm not the only potential user with a large music
collection - perhaps some of them would care to comment on how they would
like to access their music.

Mal




xPL Links: http://www.xplproject.org.uk http://www.xplhal.com http://www.xpl.myby.co.uk
To Post a Message: ukha_xpl@xxxxxxx
To Subscribe:  ukha_xpl-subscribe@xxxxxxx
To Unsubscribe:  ukha_xpl-unsubscribe@xxxxxxx

xPL Main Index | xPL Thread Index | xPL Home | Archives Home

Comments to the Webmaster are always welcomed, please use this contact form . Note that as this site is a mailing list archive, the Webmaster has no control over the contents of the messages. Comments about message content should be directed to the relevant mailing list.