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 561003
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: Comment by BBAP
by galvanash on Thu 9th May 2013 03:18 UTC in reply to "Comment by BBAP"
galvanash
Member since:
2006-01-25

Maybe there is spin off for an in-car entertainment system. Or run XBMC or something custom on Haiku for lounge room media centres...


+1!!!

What I would like to see is something very much LIKE xbmc written for Haiku... For the following reasons I think it would be an excellent project for the community to work on:

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).

2. Use it as an excuse to focus more attention on Media Kit. Work has been done on it but its not close to optimal yet. My hope is to see Media Kit get good enough that a good full featured media center type application could be written using it (instead of having to implement everything internally like xbmc does).

3. Its not an easy task, but it isn't that hard either. Im pretty familiar with XBMC (did some development on it here and there), and if Media Kit was doing all the playback work and the filesystem was doing all the metadata indexing, all you have left is doing a good UI, a scanner, and a plugin architecture. I doubt you would want to get as fancy as xbmc with the state of OpenGL on Haiku at the moment, but I think you could do something decent using webkit/blink to do the rendering.

4. Thread the hell out of the media scanner! XBMC is like 100X faster than it used to be when scanning items into the library, even still I have 350 lines or so of naive code (written in node.js no less) that can outperform it by a few orders of magnitude - and that is on Windows... It is the perfect problem to attack with Haiku's exceptional threading, its all network latency bound.

5. It sounds like fun. Developers like fun projects ;)

Edited 2013-05-09 03:26 UTC

Reply Parent Score: 3

RE[2]: Comment by BBAP
by pysiak on Thu 9th May 2013 07:12 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