Yes, thanks - after 55 minutes it finished full text search (for 420k
mp3-files). I will now test the feature and report if it was only the
initial scan that took so "long" or if it's the same with every
(update-) scan. Great idea, by the way! :-)
I knew FTS might be heavy on your server. But ahm... it's a massive hog
with a large collection. I just tried with ~400k tracks:
Dateien/Verzeichnisse werden erkannt:
/Users/mh/Documents/SqueezeZeugs/Massive Music Library (431973 von
431973) Beendet 00:02:25
Neue Musikdateien werden durchsucht:
/Users/mh/Documents/SqueezeZeugs/Massive Music Library (398652 von
398652) Beendet 00:52:23
Volltext Index erstellen (5 von 5) Beendet 00:12:19
Musiksammlungs-Ansichten erstellen (4 von 4) Beendet 00:01:25
Nach aktualisierten Plattenhüllen suchen (32304 von 32304) Beendet
00:06:03
Datenbank Optimierung (2 von 2) Beendet 00:08:31
Der Server hat das Durchsuchen Ihrer Medienbibliothek abgeschlossen.
Laufzeit: 01:23:06 (Freitag 24. Oktober 2014 / 12:21)
Building the index was pretty quick (compared to what you reported). 12
minutes is nowhere near the 55 minutes you experienced. I could imagine
that disk IO is becoming an issue again: the resulting library.db weighs
a whopping 1.1GB. With the temporary .wal file it created about 2.5GB at
peak times. The fulltext index accounts for about 500MB of the 1.1GB.
Now scan times are one issue. But unfortunately searches are useless
with this large a library. The web UI would constantly time out, while
the server was eating up to 800MB of memory.
I'll see what I can do about this...
--
Michael
_______________________________________________
beta mailing list
[email protected]
http://lists.slimdevices.com/mailman/listinfo/beta
