Playlist Einfügen: Browser zeigt keine Zeiten und stürzt ab/lädt Emergency

In der Regel werden unsere Playlists (externe .m3u) über Wochen automatisiert geladen, was wunderbar funktioniert.

Wird eine solche Playlist manuell über das Menü Playlist Einfügen geladen zeigt der Bowser fast immer keine Laufzeiten, stürzt ab, oder lädt die Emergency List nach. Gelegentlich funktioniert es.

Ziehe ich die gleiche Playlist mit Drag und Drop auf den Browser passiert das nicht.

Was könnte dieses fehlerhafte Verhalten auslösen?

Alle Titel sind in der Datenbank erfasst, und wie schon gesagt, im automatischen Betrieb verhalten sich die gleichen Dateien unauffällig. Die Playlist sind sehr lang: In der Regel 7-8 Stunden. Ist der Speicher vielleicht überfordert?

Irgendwelche Meldungen im Systemprotokoll?

Ich habe mit unserem Backup Server erneut getestet, den Fehler reproduziert, und eine Zeile gefunden in der sich diese seltsamen Zeichen befinden “”

Meldung im Systemprotokoll:
06.10.2014 20:37:44 Warnung Überspringe fehlerhaftes Element “The Beautiful Blue Danube”: Cannot open file “X:\playlists_mairlist\7H-day\Z:\25 Classical Favorites - 25 Classical Favorites\04 - 25 Classical Favorites - The Beautiful Blue Danube.mp3”. Der angegebene Pfadname ist ungültig

Anmerkung Die Playlisten befinden sich auf Laufwerk X:, die Musikdaten auf Laufwerk Z:

Entsprechende Zeile in der Originalplaylist:
Z:\25 Classical Favorites - 25 Classical Favorites\04 - 25 Classical Favorites - The Beautiful Blue Danube.mp3

Weitere Anmerkung:

Anstelle von “” sollte wohl der Name der Playlist stehen. Ich habe eine Verknüpfung erzeugt um den Pad zu prüfen:
X:\playlists_mairlist\7H-day\Herbstseptemberday2014.m3u

Das sieht doch eigentlich gut aus.

Bitte schicke mir die fragliche m3u-Datei mal zu, info@mairlist.com.

Ist in der Datenbank bei der Speicherort-Umleitung irgendetwas konfiguriert?

Danke für die M3U-Datei.

Wie du schreibst, verwendet ihr mAirList 4.3. Diese Version ist noch nicht Unicode-fähig, das ist erst ab mAirList 4.4 der Fall.

Die M3U-Datei hat allerdings ein UTF8-BOM (EFBBBF) am Anfang, Erklärung siehe hier: https://de.wikipedia.org/wiki/Byte_Order_Mark

00000000 ef bb bf 5a 3a 5c 32 35 20 43 6c 61 73 73 69 63 |...Z:\25 Classic| 00000010 61 6c 20 46 61 76 6f 72 69 74 65 73 20 2d 20 32 |al Favorites - 2| 00000020 35 20 43 6c 61 73 73 69 63 61 6c 20 46 61 76 6f |5 Classical Favo| 00000030 72 69 74 65 73 5c 30 34 20 2d 20 32 35 20 43 6c |rites\04 - 25 Cl| 00000040 61 73 73 69 63 61 6c 20 46 61 76 6f 72 69 74 65 |assical Favorite| 00000050 73 20 2d 20 54 68 65 20 42 65 61 75 74 69 66 75 |s - The Beautifu| 00000060 6c 20 42 6c 75 65 20 44 61 6e 75 62 65 2e 6d 70 |l Blue Danube.mp| 00000070 33 0d 0a 5a 3a 5c 56 61 72 69 6f 75 73 20 41 72 |3..Z:\Various Ar|

mAirList 4.3 kann mit dem BOM nichts anfangen und interpretiert es daher als Teil des Texts der ersten Zeile:

Z:\25 Classical Favorites - 25 Classical Favorites\04 - 25 Classical Favorites - The Beautiful Blue Danube.mp3

Der M3U-Importer meint nun, dass es sich bei dem Dateinamen nicht um eine absolute Pfadangabe handelt (beginnt ja nicht mit einem Laufwerksbuchstaben), hält es also für einen relativen Dateinamen, und stellt noch das Verzeichnis der M3U-Datei vorne an:

X:\playlists_mairlist\7H-day<komische Sonderzeichen>Z:\25 Classical Favorites - 25 Classical Favorites\04 - 25 Classical Favorites - The Beautiful Blue Danube.mp3

Damit wäre geklärt, warum der erste Dateiname immer kaputt ist. Die folgenden Dateien müssten dann aber korrekt übernommen werden, das Problem betrifft nur die erste Zeile. (Wenn nicht, dann gibt es noch ein zweites Problem.)

Abhilfe: Entweder mAirList 4.4 verwenden, oder aber die Software, mit der ihr die M3Us erstellt, so ändern, dass sie die Textdateien nicht in UTF8 mit BOM sondern Latin1-codiert ohne BOM schreibt.

Wow. Da muss man erst mal drauf kommen. Tausend Dank für diese sorgfältige Analyse. Ich werde jetzt die Maschinen auf 4.4 updaten nachdem dies, wie ich jetzt lese, durch ein einfaches Überspielen möglich ist.

Danke!