mAirListDB Migration zu SQLDB schlägt fehl

Hallo zusammen,
um meine DB mit mehr Perfomance aber auch vernüftigen Datensicherungen zu versorgen möchte ich meinen .mldb auf eine MariaDB migrieren.

Die MariaDB Verbindung und auch der Startvorgang des DB Klonens via DB Fenster funktioniert soweit.

Nur bei einem Element (8022) bricht der Vorgang ab.

2023-12-17 13_22_21-mAirList

mAirList 7.2.4 Build 5434 ist in Nutzung auf einem Win10 Enterprise.

MariaDB läuft auf einem Debian 11.8 und mit Version 10.5.21

Schau mal ob der DB Benutzer im Beispiel “mairlist” alle Berechtigungen hat. Über PG Admin kannst du das direkt einstellen.

Ich habe in der .mldb nur einen user dieser ist Administrator
Bei der MariaDB selbiges.

Bei INF werde ich hellhörig.
Schau dir das Element bitte nochmal genau an. Erscheint da was ungewöhnlich?

Ist Element 8022 auch DB ID 8022?

Das wäre nämlich nicht existent, scheinbar irgendwann mal gelöscht…

Wenn dem so ist, fällt mir die Antwort leichter.

Es müsste sich demzufolge um das 8022. Element der Übertragung handeln, sofern sie linear verläuft (was noch herauszufinden wäre).

Ich hätte in dem Fall zu einem csv-Export gegriffen und mir in der Tabellenkalkulation die 8023. Zeile anzeigen lassen.
:arrow_right: Die Spaltenüberschriften sind Zeile 1, daher +1.

Ist aber noch nicht gesichert, ob ich auf diese Art und Weise wirklich den Treffer lande; interne Anfrage läuft bereits.

Der CSV Export, hab ihn gerade mal gemacht ist nicht linear…

Hat hiermit zu tun:

Da sind wohl Elemente in der Bibliothek, bei denen seinerzeit die Lautheits-Analyse fehlgeschlagen ist, und daher der Wert “-INF” (minus unendlich) für bestimmte Pegelwerte hinterlegt ist. Meines Wissens trat oder tritt das bei sehr kurzen Elementen auf oder solchen, die komplett aus Stille bestehen.

SQlite ist nur schwach typisiert und stört sich daran nicht, die anderen SQL-Systeme aber sehr wohl, und können diesen Wert nicht speichern.

Also mal in der Bibliothek nach den Pegel-Spalten sortieren und schauen, ob du das oder die Elemente findest. Vielleicht lässt es sich manuell bereinigen.

2 Likes

Bingo, ich habe zwei Einträge finden können die im Feld LUFS -INF stehen haben.

Diese sind 4sec lang, nach einem manuellen analysieren ist das Feld nun leer.

Ich versuche dann da migrieren mal aufs neue…

1 Like

Update: nach etwas über einer Stunde scheint das klonen erfolgreich gewesen zu sein.

Der Hot-Switch im laufenden Betrieb scheint ebenfalls erfolgreich.

Der mAirListDB Server und der daran hängende Client scheint auch schneller zu sein.

Ich behalte das jetzt noch bis 23 Uhr im Auge, dann müssten ein paar Playlisten durch gelaufen sein…

1 Like

Jetzt nur die Frage:

Lassen sich die Playoutprotokolle der .mldb die im Zeitbereich des Klonens liegen manuell in die neue DB überspielen ?

Wir reden hier von ca. 50 Minuten fehlenden Logs

Update dazu, mittels HeidiSQL konnte ich in der .mldb die fehlenden Einträge finden, diese exportiere ich jetzt und versuche diese anschließend in die neue DB einzupflegen.

Update dazu: bis auf eine Playoutduration konnte ich alle Datensätze umziehen und “retten”

Wenn das ganze jetzt weiterhin so gut läuft dann war der Umzug ein Erfolg.

Ich habe nachgeschaut, diese Einträge mit “INF” wurden von Versionen älter als 6.3.10 erzeugt, dann wurde das Verhalten korrigiert:

Version 6.3.10 Build 4423 (2021-03-26)

[*] R128: Correct handling of files with no defined loudness (e.g. silence);
    loudness will no longer be displayed as -INF and break saving in DB library

Leider kann man die auf diese Weise entstandenen Einträge nur händisch reparieren, oder im Zweifel per SQL-Query.

2 Likes