OmniThreadLibrary: Was ist für meine Anforderung der richtige Weg? Welchen Container?

[Codehunter]

@MichaelT: Das sehe ich eigentlich ganz genauso. Der TE hat das Thema Datenbank ja von vornherein ausgeschlossen, weshalb ich mich auf eine Antwort zur konkreten Frage beschränkt habe. Prinzipiell ist ein multithreaded Datei-Auslesen ja nicht verkehrt. Was man dann aus den gewonnenen Daten macht, steht ja auf einem anderen Blatt.

[juergen]

Hallo Codehunter,
hallo MichaelT,

leider habe ich noch keine Zeit gefunden mich mit Threads zu beschäftigen. Ich denke ich benötige dafür viel Zeit.

Zum Thema Datenbank vs. Daten (Musik-Tags) speichern in ein DevExpress-Grid (letztendlich eine Objectlist):
Es gibt einen sehr guten Player mit SQL-Lite-Datenbank -> MediaMonkey. Das ist quasi die eierlegende Wollmichsau in dem Bereich.

Warum hatte ich mich nun gegen eine Datenbank entschieden?
Das Problem sind die Änderungen an den Musikdateien. Auch der geniale MediaMonkey speichert nicht alle Änderungen in der Musikdatei selbst, sondern in seiner DB.
Weiterhin besteht das Problem, wenn man Musikdateien mit anderen Programmen ändert, dass dann *konsistent* zu synchronisieren *ohne jedes Mal die ganzen Dateien neu zu scannen*.
Aus diesem Grunde habe ich mich gegen eine DB entschieden. Ich speichere die Bilder und Tag-Änderungen *direkt* in den Musikdateien und brauch mich nicht um Synchronisierung kümmern.
Die Suche über das Grid ist vernachlässigbar, also schnell genug wie ich finde. Bei ca. 60.000 Dateien benötigt die Suche weniger wie 1 Sekunde.
Weiterer Vorteil OHNE Datenbank: Da alle Änderungen in den Dateien selbst gespeichert werden, ist der Wechsel zu einem anderen Programm unproblematisch.


Ich habe also nur das Problem des Zeitverhaltens beim Einlesen der Musik-Eigenschaften (Tags).

Aber auch hier habe ich mit Testprogrammen inzw. festgestellt, dass Parallelisierung nur zum Teil hilft. Der limitierende Faktor ist wohl die Festplatte! Wenn ich mit 8 Threads die Dateien einlese von einem (langsamen) NAS-Laufwerk ist das langsamer als mit 4 Threads. Bei meiner SSD sieht es besser aus.

OmniThreadLibrary scheint mir zum einarbeiten leichter zu sein, da es dazu ein Buch gibt und etliche Beispiele. Das werde ich aber erst sehen, wenn ich dazu komme mich mit dem Thema zu beschäftigen.

[Codehunter]

Zitat von juergen:

Aber auch hier habe ich mit Testprogrammen inzw. festgestellt, dass Parallelisierung nur zum Teil hilft. Der limitierende Faktor ist wohl die Festplatte! Wenn ich mit 8 Threads die Dateien einlese von einem (langsamen) NAS-Laufwerk ist das langsamer als mit 4 Threads. Bei meiner SSD sieht es besser aus.

Nun ja, alles andere hätte mich auch gewundert. Irgendeinen Grund muss es ja geben, dass SSDs so beliebt sind Es gibt immer limitierende Faktoren (Flaschenhälse). Bei einem NAS sind das noch viel mehr als bei einer lokal eingebauten Festplatte. Ich kenne genug Werbeversprechen mit großen Zahlen und wenn man genauer hinschaut ist alles nur heiße Luft. NAS mit GbE-Anbindung ist inzwischen Usus. Doch wie ist die Schnittstelle im System angebunden? Nicht selten findet man da noch 33 MHz PCI-Busse. Oder der verbaute SoC verdient nicht mal die Bezeichnung "CPU". Dann ist auch noch zu klären, ob die Netzwerkverbindung durchgehend Fullduplex läuft oder nicht - WLAN dazwischen: Schon nur noch Halbduplex.

Thumbs.db - schon mal gehört? Microsoft cached Miniaturansichten von Bilddateien auch in einer Datenbank. Aus den selben Gründen. Ich würde einen Cache in so ein Programm einbauen und zusätzlich eine Benutzerfunktion, welche die Daten in zwei Wegen synchronisiert: Vom Cache in die Dateitags oder umgekehrt. Welche Richtung bei Asynchronität bevorzugt werden soll, würde ich dem Anwender überlassen.

Grundsätzlich stellt sich die Frage: Entwickelst du nur für den Hausgebrauch oder marktorientiert?

[juergen]

Hallo Codehunter,

Zitat von Codehunter:

Grundsätzlich stellt sich die Frage: Entwickelst du nur für den Hausgebrauch oder marktorientiert?

Das Ganze ist ein rein privates Vergnügen und nur für mich und Freunde gedacht. Allerdings kann ich die jeweils neuen Erkenntnisse dann gut in der Praxis gebrauchen (für die Firma).
Ich programmiere grundsätzlich nur hobbymäßig
Klar, auch die Firma hat dadurch den Nutzen, da ich diverse Anforderungen dann umsetzen kann.

[Codehunter]

So hab ich vor 20 Jahren auch mal angefangen Nur wars bei mir ein Outlook-Express-Ersatz. Oder noch früher, eine Warenwirtschaft in Amiga Basic. (Rückblickend eine scheußliche IDE. Wer die nur hergestellt hat... ^^)

[bytecook]

Zitat von Codehunter:

* Oder noch früher, eine Warenwirtschaft in Amiga Basic. (Rückblickend eine scheußliche IDE. Wer die nur hergestellt hat... ^^) *

DAS waren noch Zeiten... wobei ... mein erster Programmierhobel war noch ein Texas Instruments 99/4A mit satten 12KB

[Codehunter]

Also der A500 war mein erster eigener. 1991 war das. Davor gabs an der Schule noch den KC-87/1.11. Der hatte schon fette 16 kB RAM und konnte die Hornhaut von den Fingern hobeln