Antoniop wrote: > Let me summarize how I think it works : > With the windows version, at startup it scans the watch folders for the > new tracks that never have been analyzed. Then it tries to analyze these > new tracks. > For each new file, if it succeeds, an entry for the file is added in the > cache file with the result of the analysis (some key value used to > generate mixes) and, if you ticked the option "Archive analysis when > tracks are analyzed" in the setup, it also writes the result as a tag in > the track file itself. > All files that analysis has succeeded are mixable, the others are market > "Unanalyzable", will not be used for mixes and will not be rescaned > (except if you select them manually). > > The headless server works differently. It does not perform an automatic > scan. At server startup, it loads the existing cache that is on the > disk. If you want to add files in MusicIp, you go to the headless server > page : > 23619 > You enter the root folder of music and you click on "Add Music". MusicIp > scans the folder for new files not in cache. If it find new files with a > tag, then fine, it will add them to the cache and then can be used for > mixes, they're mixable. If the new files have no tag, then they must be > validated (analyzed), but it's not automatic, you need to click on > "start validation". Once the analysis is finished, it will increase the > number of mixables files. > The problem with this is that the headless server is unable to store the > analysis in the file itself, it only stores the analysis in the cache > file (the one that is in mmm.ini). Plus, it's very very slow on RPI. > That's why I analyze my files with the windows version of MusicIp (with > option "modify files" ticked) then I transfer the files to the RPI, then > they don't need to be reanalyzed. I guess you do the same. > So at MusicIp server startup, no new scan of folders, only an upload of > the cache. > > Here is the size of the cache on my RPI. > > Code: -------------------- > > $ du -BM .MusicMagic/default.m3lib > 13M .MusicMagic/default.m3lib -------------------- > > > 13 Mbytes > > When you do a scan "new and changed" in LMS, LMS asks MusicIP server > for the new mixable files. MusicIp then just sends the new information > to LMS, and don't do a rescan itself. Why ? because you still have to > click on "add files" in MusicIp to add files. The import takes 1 > second on my RPI. It would take much more if it had to rescan every > file. > On my system, it sends around 100 even if I didn't add any file nor > changed anything, I don't know why. > "refresh songs" will check that referenced files still exists. > To me, it's the "normal" Musicp behaviour. > > If MusicIp takes a lot of time to startup, maybe it's because your > cache is too big to fit in the free memory, maybe that the last "add > songs" process didn't finish. > If the MusicIp import rescan all the tracks, maybe it's just because > the last import failed. > > Just in case, my versions of qemu : > > Code: -------------------- > > $ dpkg-query -l 'qemu*'|grep '^.i' > ii qemu 1:2.1+dfsg-12+deb8u6 armhf fast processor emulator > ii qemu-slof 20140630+dfsg-1 all Slimline Open Firmware -- QEMU PowerPC version > ii qemu-system 1:2.1+dfsg-12+deb8u6 armhf QEMU full system emulation binaries > ii qemu-system-arm 1:2.1+dfsg-12+deb8u6 armhf QEMU full system emulation binaries (arm) > ii qemu-system-common 1:2.1+dfsg-12+deb8u6 armhf QEMU full system emulation binaries (common files) > ii qemu-system-mips 1:2.1+dfsg-12+deb8u6 armhf QEMU full system emulation binaries (mips) > ii qemu-system-misc 1:2.1+dfsg-12+deb8u6 armhf QEMU full system emulation binaries (miscelaneous) > ii qemu-system-ppc 1:2.1+dfsg-12+deb8u6 armhf QEMU full system emulation binaries (ppc) > ii qemu-system-sparc 1:2.1+dfsg-12+deb8u6 armhf QEMU full system emulation binaries (sparc) > ii qemu-system-x86 1:2.1+dfsg-12+deb8u6 armhf QEMU full system emulation binaries (x86) > ii qemu-user 1:2.1+dfsg-12+deb8u6 armhf QEMU user mode emulation binaries > ii qemu-user-binfmt 1:2.1+dfsg-12+deb8u6 armhf QEMU user mode binfmt registration for qemu-user > ii qemu-utils 1:2.1+dfsg-12+deb8u6 armhf QEMU utilities -------------------- > >
Yes you are right that the un-mixable tracks should not be re-loaded. I just checked, I have the same versions of qemu, thus that can be ruled out as well... ------------------------------------------------------------------------ frankd's Profile: http://forums.slimdevices.com/member.php?userid=52885 View this thread: http://forums.slimdevices.com/showthread.php?t=106958 _______________________________________________ plugins mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/plugins
