- Thread starter
- #151
ok, muss man wissenWenn dann z.b. nach Verschieben oder Löschen von Songs ein Datenbank Reorg durchgeführt wird, dann werden die Einträge in der Datenbank, wo wir das File nicht mehr finden gelöscht und die neuen kommen mit fortlaufender idTrack Nummerierung dazu.
wenn ich meine musik "säubere" löschen und neue titel hinzufüge usw usw. danach track nr neu vergeben muss (wodurch sicherlich ne neue reihenfolge entsteht) nahm ich an, die db übernimmt genaus so die neuen nr. und ordnet auch neu
aber egal, ist so ! und auch nachvollziehbar bei reorg der db.
neuer sachverhalt:
edit:
mhhh, irgendwas ist da faul.
- reihenfolge in mp3tag ist immer alphabetisch "artistname" so wird dann auch track nr. vergeben mit assistent
- sortiere ich in mp nach name = identisch zu mp3tag
- sortiere ich in mp nach track nr. sieht es aus wie im screen . . . verstehe ich nicht ?
db mehrmals gelöscht und eingelesen und ebenfalls mit mp3tag sowie MPTagThat überprüft.
rätselhaft
überhaupt nicht kapiere ich - wieso nach löschen und neu einlesen der db nicht funzt ? <- bei reorg der db könnte ich det kapieren.
- nochmal getestet nur 1 ordner mit 250 titel, ca 20 neu reingekommen sowie 4-5 gelöscht.
- mit mp3 editoren neue tracknr. vergeben und überprüft bzgl nr
- db neu eingelesen
- wieder fehlen in der richtigen reihenfolge die neuen titel in mp musik list
- die haben auch keine fortlaufenden sortiereihenfolge in mp/musik sondern liegen als 03/04/16/18/29/30/38 usw genauso ... hintereinander in der liste, aaaber erst nach nr 241.
ich glaube mp nutzt da etwas anderes ?? um neu einzuordnen/sortieren.
- screen 1 ist mp mit neu eingelesener db (1 ordner) sort. tracknr.
- screen 2 db nach neu einlesen (1 ordner) - da stimmt exakt die idTrack was mp aber nicht interessiert ... siehe screen 1
der gibt dem zwar die nr 3 . . . legt aber irgendwo hinten ab = andere sortierung
hier versagt jetzt meine "logik" als "schrauber" du bist "entwickler" hast ne andere logik . . .
Attachments
Last edited: