Martijn Voncken wrote: > Hi, > > There is no progress on the mediadb, so i'm proposing something again. > > Had a disussiuon with Tack on IRC a while ago.
Yes, I still hope to get a mediadb from Tack (or from you or from both working together). > He really wants scalebility (>100 000 files),and after some thought > i do agree. The media he's working on for MeBox is a side project > with lots of goals, no way of knowing when it's finished. You read his proposal for beacon? > My New goals: > *scalability far beyond 100 000 media files Yes > *use sqlite. > > Back to (attr, value) mapping , Like wander proposed. > I'm willing to make a sqlite mediadb with that schema. > Good points: > *scales > *sqlite > *"easy" to replace fxd files. > Bad points: > *more code > *lots of joins for complex stuff > *some really dynamic stuff will not be implemented [ but i love to > prove me wrong ;-) ] > *some challenges in implementing smart-query's + album-tree. I need a way to add unknown fields from plugins. A plugin may want to store the attribute foo to a file. E.g. the bookmark plugin adds the last play position and the freevo core should not know that the plugin does need that kind of attr. > -various- > A static sqlite schema would be a lot easier but: > But you search images on ISO, mp3's on artist and Video's on director. > -my plans- > 1: > freevo cache,fill sqlite db Yes or do it during runtime. > 2: > replace mediadb Yes > 3/4: > minimal search/smart playlists/albumtree > Evaluate , is it good enough? OK > 5: > audio.logger > 6: > improve search/smart playlists/albumtree > 7: > other freevo processes could ask the main freevo-process data via mbus. > background indexing could also report back via mbus. Great ideas. Looks like a start to get the mediadb going. The ideas From Tack are great but it is easier to do it step by step. Adding inotify support is great but not the first thing we should do. Dischi -- Fast, cheap, good: pick two.
pgpkEPKC1m7xO.pgp
Description: PGP signature
