The UK Home Automation Archive

Archive Home
Group Home
Search Archive


Advanced Search

The UKHA-ARCHIVE IS CEASING OPERATIONS 31 DEC 2024

Latest message you have seen: Re: xplmedianet menu navigation


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

xplmedianet database


  • Subject: xplmedianet database
  • From: "Tony Tofts" <tony@xxxxxxxxxx>
  • Date: Wed, 16 Mar 2005 18:56:51 -0000


Hi all,

More thoughts please...

The current media.dll uses the same database structure as xplrionet did.
i.e. a relational database using different tables for artist, album, track,
genre etc and requiring various queries (stored procedures) for various
actions due to the complexity of some queries.

This has the advantage of being disk space efficient, but on the downside
is
not suitable for mysql/mssql.

I think we should change the database to contain only 2 tables and no
queries (excluding the possibility of storing playlists).

A statistics table as currently (as this is keyed on md5 it can also be
kept
up-to-date by files played via browse, query, playlist which return a
filename rather than a md5 key - as the tags.dll supplies exactly the same
info as it does for media that is scanned so a matching md5 key can be
created)

And a track table where each record stores all the info for a track (like
genre, artist, track name, album, md4 hash etc) in a flat rather than
relational format.

I also want to limit the path to 255 characters, excluding filename, rather
than using the wasteful (and messy to process in a query) memo field
type...

Thoughts/comments please?

Thanks
Tony



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.