[prev in list] [next in list] [prev in thread] [next in thread] 

List:       mms
Subject:    Re: Some questions :-)
From:       Anders Rune Jensen <anders () gnulinux ! dk>
Date:       2005-09-03 9:47:05
Message-ID: 1125740825.14858.4.camel () localhost
[Download RAW message or body]


On Fri, 2005-09-02 at 22:36 +0200, Anders Rune Jensen wrote:
> On Fri, 2005-09-02 at 18:55 +0200, Anders Rune Jensen wrote:
> > > And I have a idea left:
> > > Is it a problem to put the metadata-read (imms) for new songs in an extra
> > > thread?
> > 
> > I really like this idea but there is some work that needs to be done
> > before it makes sense to do this. Currently imms is included in mms.
> > From 2.1.X I think it can be installed as a library so that would really
> > be the way to go. So first we need to update to the new version. Another
> > thing that would also work very well with this is inotify support
> > (adding in 2.6.13). Basically what inotify does is tell you when a file
> > has changed on the drive. This way we could monitor the media folders
> > and automaticly begin extracting meta-data when you add a new folder.
> > Basically there is no need for reload anymore. I would do this in 1.1.0
> > because porting between 1.0.X and 1.1.0 has become a lot harder after I
> > cleaned up a lot of the modules in 1.1.0. What I would also like to do
> > is put a lot of the other stuff into the database. So I think when I do
> > the port to the new imms I will add support for storing movie
> > information, picture and epg information in the database also. That
> > would enable cool things like being able to search for all movies with
> > Al Pacino or something like that. 
> > 
> > I think that paragraph became a little longer than I intended but it was
> > just to put it into perspective. I think the idea of doing some of the
> > hard work in the background is excellent. And the functionality for
> > doing it in 1.0.X is there, so if someone would like he could add this.
> > It's really not that hard. Basically what you need to do is to use the
> > updater and then once in a while:
> > 
> > generate list of files that needs to be updated
> > 
> > do {
> > - check if the system is idle (conf->p_last_key())
> > - if idle extract info from a couple of files (check that they still 
> >   needs to be extracted)
> > - sleep
> > } while(files still needs checking)
> > 
> > rerun updater on start and on reload. 
> > 
> > Hmm actually this algorithm seems quite easy, I think I will implement
> > it in the next version (1.0.4).
> 
> Yeah it was quite easy as I suspected. I have now committed it to
> 1.0.4-patch-11. Please test and report succes/failure :)

Fixes in patch-13. It is now an option so that you can disable it when
you do not want it running all the time.

-- 
Anders Rune Jensen
http://www.cs.auc.dk/~arj/

PGP/GnuPG key: 1024D/62C2D7F0 @ pgp.mit.edu
Fingerprint: 6A03 907E 92E1 47EB 4EAB  76B6 068A ACD1 62C2 D7F0


["signature.asc" (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]