Kein Scriptproblem, sondern meinungsfrage.

[Jache84]

Hallo liebe Forumleser.

Weiß nicht wo ich das reinstellen soll, deswegen einfach mal hier.
ansonsten bitte verschieben einer der Moderatoren. DANKE

Ich habe hier kein direktes Codeproblem sondern würde ich gerne eure Meinung zu folgender Frage wissen.

Ich hab eine Datenbank in der die ID3Tags von MP3´s gespeichert werden.

Die MP3´s sind wie folgt auf der Festplatte abgespeichert:

Ordner von A-Z. Unter den Ordnern sind die Interpreten und den Interpretenordner sind die Alben des Interpreten und darunter liegen die Titel des entsprechenden Albums. Falls es von einem Album mehrere Titel gibt allerdings ist das album nicht komplett wird für dieses kein Albumordner erstellt sondern die MP3s liegen direkt im Ordner des Interpreten.

Somit sieht die Struktur folgendermaßen aus:

A-Z/INTERRET/ALBUM/mp3´s

Oder A_Z/INTERPRET/mp3´s

In meiner SQL Datenbank welche ein PHP Frontend hat gibt es die Möglichkeit nach Liedern zu suchen. Falls ein Leid gefunden wird kann man zu dem Lied ein Cover hinzufügen. Momentan wird das Cover als Blob in der Datenbank abgespeichert. Sprich jeder Datensatz hat noch ein Feld namens „cover“ als Typ Blob in das man ein Cover hinzufügen kann.

Jetzt mein Problem und ich würde gerne wissen was ihr für sinnvoller haltet:

Wenn ich bespielsweise 500 MP3s eingelesen habe und zu 70 MP3´s noch ein Cover anschließend hinzugefügt habe.

Dann nach 6 monaten habe ich nicht mehr 500 MP3´s sondern 800. Ich müsste meine Datenbank neu einlesen lassen. Dann kann ich entweder ein Update über die Datenbank fahren wo ich sage wenn interpret – Titel schon in Datenbank vorhanden überspringe diesen ansonsten mach mir ein Insert. Somit bleiben die Covers die ich schon hinzugefügt habe bestehen und alles ist soweit gut.

Wenn ich allerdings in den ersten 500 MP3´s einen ID3Tag nach dem einlesen in die Datenbank ändere, kann ich nicht mehr vergleichen welche MP3´s schon in der Datenbank eingelesen wurden und welche noch nicht, da ich ja auch den Interpreten oder den Titel im ID3Tag ändern kann und er somit, falls ich was geändert habe, die MP3 nochmal in die DB hinzufügt. Also ist das auch Mist.

Wenn ich jetzt sage ich speicher die Covers NICHT in der DB sondern speicher nur den Link in die DB wo das Bild auf meiner Festplatte liegt, könnte ich immer ein DropTable durchführen und alle MP3´s neu einlesen sowie auch die Pfade zu den Covern, da diese ja nicht direkt in die DB gespeichert wurden sondern in den Ordnern der Alben liegen. Problem ist aber das ich wenn ich einem MP3 Lied, welches nicht in einem Album ist, ein Cover zuordne muss dieses in dem ordner des Interpreten liegen, da ich ja dann kein Ordner für das Album habe. Wenn dann allerdings ein halbes Jahr später doch alle Titel von dem Album zusammen sind und ich dann ein Ordner für das Album erstelle und dort rein dann das Cover lege ist der Pfad der in der DB abgespeichert ist nicht mehr korrekt.

Ihr sehr also egal wie ich es mache es gibt immer ein problem. Wie würdet ihr das Problem lösen. Würde mich sehr über Antwort freuen.

Liebe Grüße
Jache84

[TobiaZ]

Ich sehe dein problem ganz wo anders.

Was machst du, wenn du den Titel (oder was auch immer) geändert hast und dann dein Drop Table durchfühst? Da sind deine Änderungen volle Kanne weg!
(Vielleicht habe ich dich an der Stelle "UPDATE - überspringen" (was denn jetzt?) auch nicht richtig verstanden.)

Den Weg kannst du also eigentlich vergessen.

Das mit dem DropTable ist ohnehin eher unüblich, schließlich besteht die möglichkeit, dass du die datensätze irgendwann mal mit einer anderen Tabelle verknüpfst.

Also:

1) alle dateien einmal einlesen, speichern. Gleichzeitig den Pfad zur datei (/i/Interpret/Album/Lied.mp3) im Datensatz speichern.
2) Datensätze so oft du willst bearbeiten.
3) Datensätze neu einlesen, vorhandene (vergl. Pfad) überspringen

Die Cover kannst du übrigens speichern, wo immer du willst, aber bitte nicht in nem blobfied. bei 15 Titeln pro Album speicherst du 15 Bilder in der DB. Irgendwie verschenkter Speicherplatz.
Gib den Covern eine id und speicher diese zu den entsprechenden Datensätzen in der DB. Zur not tut es hier auch der Pfad.

Hab ich noch was vergessen?

BTW: BRAINSTORMING finde ich zu dem Thema doch sehr passend, oder? *move*

[Jache84]

Ähm STOp nein

In meiner DB gibt es NICHT die Möglichkeit die Tags zu ändern. Dieses kann ich nru in einem speziellen programm. Die DB soll nur dazu sein um schnell nach liedern suchen zu können und sich Information zu dem einzelen File anzuschauen.

Erläutere mal genauer wie du das meinst mit dem Cover eine ID geben und dann zuordnen.

Danke udn LG
Jache84

[TobiaZ]

Achso. nagut, dann streich den Teil mit dem ändern.

naja, in der DB ein Feld mit der id, und das cover heißt dann

1_album_interpret.jpg oder so.

[Jache84]

okay, ist soweit ganz gut. Wo würdest du die Covers speichern?

und wenn ich dann ein Update auf dei DB mache und schaue wo sich was geändert hat, wie mache ich das, den ich habe ja keinen anhaltungspunkt. wenn ich nach interpret und titel gehe, geht ja nicht da sich ja was beim interpreten oder titel im tag geändert haben könnte, z.B. Rechtschreibfehler.

wie soll ich da ran gehen????

[TobiaZ]

Was das Update angeht, schau mal nach REPLACE.

Ich würd die Covers in ein seperates Verzeichnis packen.

[Jache84]

Ja seperates verzeichnis ist wohl am sinnvollsten. Gibt es die Möglichkeit mit PHP das man egal wie groß ein bild ist dieses auf 120 x 120 Pixel verkleinert angezeigt wird?


Werde mal nach REPLACE unter MySQL suchen, wenn ich fragen dazu habe, frage ich Allerdings wahrscheinlich erst späte rheute da ich jetzt nochmal weg muss. Vielen Dnak schon mal.

Liebe Grüße
jache

[Jache84]

hmmm, das REPLACE arbeitet ja so, das kontolliert wird ob der PK schon existiert wenn ja wird der Datensatz aktualisiert ansonsten wird ein insert gemacht. Da sist ja spitze, allerdings ist das problem das ich ja keinen PK habe den ich auslese. Sondern in meiner Tabelle eine Spalte ID habe diese ist autoincrement und somit wird der wert automatisch geschrieben. Andere idee, wie ich es machen kann?

[TobiaZ]

Gibt es die Möglichkeit mit PHP das man egal wie groß ein bild ist dieses auf 120 x 120 Pixel verkleinert angezeigt wird?

Ja, such mal danach.

allerdings ist das problem das ich ja keinen PK habe den ich auslese. Sondern in meiner Tabelle eine Spalte ID habe diese ist autoincrement und somit wird der wert automatisch geschrieben. Andere idee, wie ich es machen kann?

der einfachheit halber würde ich die pfad-spalte missbrauchen.

[Jache84]

okay das ist echt eine gute idee.

allerdings gibt es noch ein Problem, denn wenn ich den ID3Tag änder von interpret und Titel ändert sich auch der dateiname des Titels, da der dateiname aus dem ID3Tag generiert wird und smoit ist der auch icht mehr eindeutig.

Was kann ich tun?

[Jache84]

hier noch mal ein Screenshot von meiner tabelle:

[TobiaZ]

naja, man könnte auch nen md5-hash der datei als identifikation nehmen. ansonsten hast du ja dann keine möglichkeit deine dateien zu identifizieren.

[Jache84]

richtig, habe irgendwie keine Möglichkeit. Muss es aber irgendwie geben. Ist der MD5 nicht auf anders wenn der Dateiname anders lautet?

[TobiaZ]

vom Dateinamen wäre der hash nicht abhängig. aber durch die änderungen an dem ID3Tags würde sich natürlich der hash ändern.

Somit kannst du eine veränderte datei nicht eindeutig zur "original"-Datei zuordnen.

Vielleicht kann man die header-infos aber abtrennen. Dann könntest du den hash von der "reinen musikinfo" bilden. Wie praktikabel das ist, vermag ich nicht zu sagen.

Also zurück zur drop-table?

[Jache84]

jo bin dann wohl soweit wieder das ganze mit drop table zu machen, dann ist aber immernoch die Frage wie ich es dann mit den Covern mache.

Wenn ich die Covers einfach immer so nenne: Interpret - Album.jpg kann ich diese ja alle in einen ordner machen und dann suchen ob es in dem ordner wo die Cover sliegen ein cover zur momentan selektierten MP3 gibt. Sprich:

if Interpret - album von selektierter Datei in Ordner Cover dann zeige mir es an.

oder wie würdest du es mir raten zu machen?

Danke dir.

Grüße
jochen