Linked by Thom Holwerda on Wed 8th May 2013 14:22 UTC
BeOS & Derivatives This is one of those news items that's fun to write, fun to read, fun to comment on, and where no one will be able to say anything unkind. It's all just one big ball of awesome fluffiness. TuneTracker, the BeOS radio automation software, has just released something very special: TuneTracker System 5, the first version designed entirely and specifically for Haiku. In fact, it actually includes Haiku in the software package. Better yet, TuneTracker also unveiled several system-in-a-box products - which have Haiku and TuneTracker pre-installed.
Thread beginning with comment 561015
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[2]: Comment by BBAP
by pysiak on Thu 9th May 2013 07:12 UTC in reply to "RE: Comment by BBAP"
pysiak
Member since:
2008-01-01

1. Use file attributes to store all the metadata on the media (instead of having to use sqlite/mysql like xbmc does). It seems like a perfect fit for Haiku (probably the reason TuneTracker is still a BeOS app).

I see the benefits in storing meta data in the file system, instead of a database, but I have a few doubts:

1) can you easily and *efficiently* do a query on metadata? e.g. SELECT AUTHOR, FILENAME FROM /home/user/mp3/ WHERE TITLE LIKE '%RED%'; ?
2) would that query result be cached by the file system cache or would you want to traverse the whole library? Would you need to write your own cache mechanism? Would you want to preserve the state of the cache between runs?
3) Do all copy methods ensure file attributes are preserved? I would think that cp works differently than a copy routine coded in an application and, say, something along sendfile(). That opens the risk of losing precious meta data.

Not to mention confining yourself to one file system.

Reply Parent Score: 2

RE[3]: Comment by BBAP
by henderson101 on Thu 9th May 2013 09:15 in reply to "RE[2]: Comment by BBAP"
henderson101 Member since:
2006-05-30

1) can you easily and *efficiently* do a query on metadata? e.g. SELECT AUTHOR, FILENAME FROM /home/user/mp3/ WHERE TITLE LIKE '%RED%'; ?


Yes, but the query language is not SQL. Have a look at this article on Ars:

http://arstechnica.com/information-technology/2010/06/the-beos-file...

2) would that query result be cached by the file system cache or would you want to traverse the whole library? Would you need to write your own cache mechanism? Would you want to preserve the state of the cache between runs?


Yes, you can save queries. I used to have 4 or 5 queries saved to filter for specific file types or email status. They are known as "live queries" and Tracker displays them like a folder (as an example) when opened. AFAIR, one can do similar with the low level API. But because Attributes are indexed, running the query again is not as intensive as say, using the find file dialogue in Windows XP.

3) Do all copy methods ensure file attributes are preserved? I would think that cp works differently than a copy routine coded in an application and, say, something along sendfile(). That opens the risk of losing precious meta data.


The meta data is preserved. The metadata is stored on an inode level. Read this book for more info:

http://www.nobius.org/~dbg/practical-file-system-design.pdf


Not to mention confining yourself to one file system.


Haiku only boots from one file system, so there's no actual issue here really, is there?

Reply Parent Score: 3

RE[4]: Comment by BBAP
by pysiak on Thu 9th May 2013 12:25 in reply to "RE[3]: Comment by BBAP"
pysiak Member since:
2008-01-01

Thanks for your answer. It sounds very nice!

As I donated some money to Haiku years ago, I feel I should have a decent look now!

Reply Parent Score: 2

RE[4]: Comment by BBAP
by v_bobok on Fri 10th May 2013 04:43 in reply to "RE[3]: Comment by BBAP"
v_bobok Member since:
2008-08-01

Haiku uses it's own BFS on a system drive, but it can write in several popular and not so popular file systems and read from almost anything.

Reply Parent Score: 2