xml error 67 Playlist item does not match (mAirList version 4.x)

Hallo,

der Export der Bibliothek bei meiner vers. 3 wird ohne Fehler abgeschlossen.

Die in die Datenbank Version 4 aufgenommenen Songs aus der gleichen Quelle wie bei der Vers.3
läuft ohne Fehlermeldung.
Der Export der unveränderten Bilbliothek meiner Vers. 4 wird mit der nachfolgenden Fehlermeldung abgebrochen:
XML Error 67, Line1, Position136: end tag playlist item does not match the start tag external ID

Hilfe tut not.

Danke sagt Juergen

Heute habe ich mühevoll unter rund 4400 Songs 5 Titel als Verursacher für die XML Error 67 … Fehlermeldung gefunden.

  1. Wie kann ich den Ärger künftig vermeiden, bzw. wie sind die fehlerhaften Audio Dateien schneller zu finden?
  2. Ist evt. die Festplatte defekt? (2 Jahre in Betrieb)
  3. Welche Lehre ziehe ich daraus? Nach dem Import genau markierter Audio Dateien immer eine Sicherung unter neuem Namen der Datenbank anlegen.

Frage: Warum wird der Fehler nicht schon beim Import bemerkt?

LG Juergen

Fehler beseitigt !

In den Dateinamen standen Sonderzeichen, teils versehentlich hereingenommen, teils mit dem Titel nach dem Rippen übernommen, Beispiel französische “Sonderbuchstaben” im Titel. Nach dem Ändern des Titels gabe es keine xml Error Meldung mehr.

Damit hat sich meine Frage 2) zur def. HD erledigt.

Bleibt Frage 1) Wie kann ich den Ärger künftig vermeiden, bzw. wie sind die fehlerhaften Audio Dateien schneller zu finden?

LG Juergen

Ich glaube, deine Vermutungen gehen schon in die richtige Richtung, aber ein klein wenig anders wird es doch gewesen sein. Am Titel-Feld lag es auf keinen Fall.

Zur Erläuterung:

In der mAirListDB haben nur die wichtigsten Felder eigene Spalten in der Tabelle mit den Playlist-Elementen (bzw. sind in eigenen Untertabellen). Die übrigen Felder werden als XML im Feld “xmldata” abgelegt, in demselben Format wie in den MMD-Dateien, mlp-Playlisten usw.

Der Vorteil an dieser Methode ist, dass die mAirListDB ohne jegliche Anpassung mit beliebigen neuen Elementtypen umgehen kann. Beispiel: In v4.1 sind ja die “Live Feeds” hinzugekommen, dort gibt es die Felder “Aufnahme-Soundkarte” und “Verzögerung”. In einer rein relationalen Datenbank hätte man nun die Tabellenstruktur anpassen und diese Felder dort hinzufügen müssen. Mit allen damit verbundenen Unannehmlichkeiten (Schema-Upgrade usw.). Dadurch, dass diese neuen Felder einfach als XML abgelegt werden, ist das nicht notwendig. Die mAirListDB kommt sofort mit diesen Elementen klar.

Bei dir scheint es nun so gewesen zu sein, dass bei mindestens einem Element diese XML-Daten korrupt waren. Warum auch immer. Am Titel kann es nicht gelegen haben - der steht nämlich nicht im XML sondern hat eine eigene Spalte in der Tabelle. Ohnehin sollten Sonderzeichen ordentlich codiert werden, so dass sie das XML nicht kaputt machen. Vielleicht ist damals beim Speichern irgendetwas anderes schiefgelaufen.

Durch das Bearbeiten des Titels wurde der XML-Block neu geschrieben, und diesmal fehlerfrei, so dass der Fehler nicht mehr auftritt.

Bleibt also die Frage, warum er überhaupt korrupt werden konnte. Es wäre interessant zu wissen, ob du den Fehler mit derselben Datei reproduzieren kannst. (Du kannst sie ja einmal unter einem anderen Namen kopieren und dann als neue Datei in die Datenbank importieren.)

Um zu testen, ob nun alle Elemente in Ordnung sind, könntest du z.B. die Funktion “Gesamte Datenbank exportieren” verwenden. Wenn die ohne Fehlermeldung durchläuft, sind alle XML-Blöcke in Ordnung.

Hallo Torben,

vielen Dank für die umfassende Aufklärung.

Die bei mir korrupten Dateien habe ich zunächst in einen extra Ordner verschoben. Dort habe ich den Dateinamen und später die Einträge in den Titel sowie, falls es mir notwendig erschien, den Interpreten editiert. Dann in den Quellordner für die Datenbank zurück und importiert.

Wie von dir vorgeschlagen die “Gesamte Datenbank exportieren” ausgeführt. Ergebnis : keine Fehlermeldung mehr.

Nach meiner Auffassung scheint es aus verschiedenen Gründen angebracht die Audiodateien auf Quellordner zu verteilen, die z.B. Schlager, 90er, 80er, oder Filmtitel heißen. Auf diese Art entstehen mehrere Datenbanken mit entsprechendem Namen bei einer geringeren Anzahl von Dateien. Sollte es mal ein Problem mit der Datenbank geben, ist die Suche z.B. nach der defekten Datei ungleich schneller, als wenn alle verfügbaren Songs in einer Datenbank liegen.

Ist dieser Organisation zustimmen oder welche Alternativen gibt es?