Datenbank Mairlist 6x bzw. 7x Upgrade - Fehler

Deutsch / German mAirList 7.x
21

Ja, genau mit der Meldung von @Gregor_G

Ich habe nun noch mal etwas geforscht, weil mir aufgefallen ist, dass andere .WAV funktionieren.

Bisherige Feststellungen:

  • ALLE Titel, die auf dem Server früher mit der 6.3.* vom Auto-Importer importiert und dann in einen Systemordner verschoben worden waren, sind nicht abrufbar und werfen diesen Fehler aus. Egal mit welcher Dateiendung.

  • Werden Dateien auf dem Server händisch importiert über “synchronisieren”, können sie ebenfalls nicht abgerufen werden

  • Transkodierung an oder aus macht keinen Unterschied

Im Protokoll des DBservers finde ich folgendes interessant:

Alle erfolgreichen Aufrufe erfolgen mit der ID und ADMIN-Namen, die mit den Fehlermeldungen scheinbar allesamt mit dem PFAD und ohne ADMIN-Name…

Beispiel ohne Fehlermeldung:

84.1x.xxx.xxx - "Stefan" [05/Jul/2022:10:48:27 +0200] "GET /api/v1/items?folder=91&sorted=false&station=1 HTTP/1.1" 200 - "-" "Mozilla/5.0 (compatible; mAirList/7.0.1.5032)"
84.1x.xxx.xxx - "Stefan" [05/Jul/2022:10:48:30 +0200] "GET /api/v1/items/8047?station=1 HTTP/1.1" 200 - "-" "Mozilla/5.0 (compatible; mAirList/7.0.1.5032)"
84.1x.xxx.xxx - "Stefan" [05/Jul/2022:10:48:31 +0200] "GET /api/v1/config HTTP/1.1" 200 - "-" "Mozilla/5.0 (compatible; mAirList/7.0.1.5032)"
84.1x.xxx.xxx - "Stefan" [05/Jul/2022:10:48:31 +0200] "GET /api/v1/stations HTTP/1.1" 200 - "-" "Mozilla/5.0 (compatible; mAirList/7.0.1.5032)"
84.1x.xxx.xxx - "Stefan" [05/Jul/2022:10:48:31 +0200] "GET /api/v1/storages HTTP/1.1" 200 - "-" "Mozilla/5.0 (compatible; mAirList/7.0.1.5032)"
84.1x.xxx.xxx - "Stefan" [05/Jul/2022:10:48:31 +0200] "GET /api/v1/folders?station=1 HTTP/1.1" 200 - "-" "Mozilla/5.0 (compatible; mAirList/7.0.1.5032)"
84.1x.xxx.xxx - "Stefan" [05/Jul/2022:10:48:31 +0200] "GET /api/v1/items/8047/folders?station=1 HTTP/1.1" 200 - "-" "Mozilla/5.0 (compatible; mAirList/7.0.1.5032)"
84.1x.xxx.xxx - "Stefan" [05/Jul/2022:10:48:31 +0200] "GET /api/v1/items/8047/restrictions?station=1 HTTP/1.1" 200 - "-" "Mozilla/5.0 (compatible; mAirList/7.0.1.5032)"
84.1x.xxx.xxx - "Stefan" [05/Jul/2022:10:48:31 +0200] "GET /api/v1/config HTTP/1.1" 200 - "-" "Mozilla/5.0 (compatible; mAirList/7.0.1.5032)"
84.1x.xxx.xxx - "Stefan" [05/Jul/2022:10:48:31 +0200] "GET /api/v1/stations HTTP/1.1" 200 - "-" "Mozilla/5.0 (compatible; mAirList/7.0.1.5032)"
84.1x.xxx.xxx - "Stefan" [05/Jul/2022:10:48:31 +0200] "GET /api/v1/storages HTTP/1.1" 200 - "-" "Mozilla/5.0 (compatible; mAirList/7.0.1.5032)"
84.1x.xxx.xxx - "Stefan" [05/Jul/2022:10:48:31 +0200] "GET /api/v1/items/8047/history?station=1 HTTP/1.1" 200 - "-" "Mozilla/5.0 (compatible; mAirList/7.0.1.5032)"

Beispiel MIT Fehlermeldung

84.1x.xxx.xxx - "" [05/Jul/2022:10:51:51 +0200] "GET /api/v1/storages/1/files/0%20-%20von%20Auto-Importer/Wham!%20;%20Wake%20me%20up%20before%20you%20go-go%20;%20%5BSAMPLER%5D%20HR3%20Pop%20&%20Weck%20-%20Guten%20Morgen%20Hits%20(1995).m4a?quality=default HTTP/1.1" 401 - "-" "Mozilla/5.0 (compatible; mAirList/7.0.1.5032)"

Ist das hilfreich?

22

Sind soeben per Mail raus.

23

Ja, genau da scheint das Problem zu liegen. Offenbar “vergisst” er, beim Download der Dateien den Benutzernamen/Passwort zu übergeben bzw. in die URL einzubauen.

EDIT: Habt ihr neben der DBClient-Verbindung noch andere Datenbanken eingerichtet?

1 Like
24

Auf dem 7er-Rechner? Ja, aber nicht aktiviert…

25

Ja eine weitere DB Client Verbindung dort ist aber dasselbe Problem.
Und alle anderen sind deaktiviert, bzw. ungenutzt.

26

Macht bitte mal folgendes:

  • database.ini wegsichern
  • Alle anderen Datenbankverbindungen löschen
  • Tritt der Fehler dann auch auf?
  • (database.ini zurückspielen)
27

Keine Veränderung, immer noch die selben Fehlermeldungen

28

Mit dem gleichen 401 im serverseitigen Log?

Ich beziehe mich hier ausschließlich auf die API-Anfragen mit GET /api/v1/storages/<ID>/files/<Dateiname>. Das sind die, wo die eigentliche Audiodatei übertragen wird. Die anderen, die du oben erwähnt hast (/api/v1/items etc.) übertragen lediglich Titelinfos/Metadaten und sind hier erstmal irrelevant.

Dazu doch eine Frage: Du hast oben gesagt, dass es (scheinbar) nur bestimmte Audiodateien betrifft? Kannst du das noch einmal verifizieren? Und wenn ja, lässt sich ein bestimmtes Muster erkennen?

Und noch etwas: Macht es einen Unterschied, ob man die DB-Anwendung über das Playout öffnet, oder aus dem Windows-Startmenü heraus?

29

ICH HABE EINE LÖSUNG:

Auf dem Server einen neuen Admin-User angelegt, aber nur mit Passwort und Benutzername. Den dann stattdessen in der 7er zur Anmeldung genutzt.

Damit werden auf der 7er-Version alle Titel abgerufen, die vorher blockiert waren.

MIT TOKEN auch beim neuen User gibt es weiterhin die bekannten Fehlermeldungen.

---------snip--------------

Hier noch, was ich bis eben zur Lösung geschrieben hatte:

Soweit ich das bisher festgestellt habe, betrifft das alle Dateien, die ich nicht auf dem 7.0-Rechner als Audio-Cache gespiegelt habe.

Scheint so.

84.xxx.xxx.xxx - "" [05/Jul/2022:15:28:26 +0200] "GET /api/v1/storages/1/files/0%20-%20von%20Auto-Importer/EUPHORIA-III-07-Show_Stopper-MainMix-125bpm.mp3?quality=default HTTP/1.1" 401 - "-" "Mozilla/5.0 (compatible; mAirList/7.0.1.5032)"
84.xxx.xxx.xxx - "" [05/Jul/2022:15:28:26 +0200] "GET /api/v1/storages/1/files/0%20-%20von%20Auto-Importer/EUPHORIA-II-03-CodeRed-JingleMix-133bpm.mp3?quality=default HTTP/1.1" 401 - "-" "Mozilla/5.0 (compatible; mAirList/7.0.1.5032)"

Der Fehler tritt immer auf.

  • Wenn während des Starts das Cartwall-Preset mit Jingles geladen wird, die nicht im Audio-Cache sind.

  • Wenn die Datenbankapplikation alleine gestartet wird

  • Wenn die Datenbank-App aus mAirlist heraus gestartet wird

30

Falls es etwas zur Lösung beiträgt: Da scheinen ja nun andere Berechtigungen gesetzt zu sein?

Mein Standard-User im DBServer der 6.3-Version sah so aus:

IMG_5320
IMG_53201500×1125 308 KB

(unterer User)

Der neue ist der obere…

31

Ja, die LibraryPermissions sind neu dazugekommen vor einiger Zeit. Bei vorhandenen Usern sollte aber sowieso All als Standard angenommen werden, wenn der Wert nicht gesetzt ist.

Hast du mal versucht, die Berechtigungen vom alten Admin zu bearbeiten (alles anhaken!) und zu speichern - geht es dann auch mit dem alten User?

1 Like
32

Danke. Habe jetzt mal (mit cURL) auf deiner Datenbank getestet. Mit Benutzername/Passwort geht es, mit dem Token nicht.

33

Das war tatsächlich mein erster Versuch, hat aber zumindest mit Token nicht funktioniert. Ob nur mit User/Passwort habe ich nicht probiert, kann ich aber später noch mal nachholen…

Aber @Gregor_G hatte ja schon geschrieben

Also wohl eher nicht mit einem existenten Benutzer. Aber solange es mit dem neuen Nutzer nun funktioniert…

Kleiner Hinweis: Wenn Dateien transkodiert und vom Server in meinen Studiorechner vorgeladen werden, erscheint kein kleiner grüner Haken in der Playliste. Das ist etwas verwirrend, denn bei nicht-transkodierten (also den Originalen) werden sie angezeigt.

34

Der Nutzer war aber auch neu angelegt, oder?

35

Ich glaube, ich habe den Fehler gefunden. Testet mal bitte Build 5034 (gerade hochgeladen).

Es betrifft aber wirklich nur die Token-Authentifizierung. Neuer oder alter User ist dabei egal. Es war einfach der benötigte Authorization-Header nicht gesetzt, bzw. der dort übertragene Token leer.

Deswegen fragte ich ja:

Nun bin ich etwas verwundert, denn wenn das auch bei User/Passwort-Authentifizierung auftritt, dann muss es einen zweiten Bug geben.

1 Like
36

Aber nur bei einem existierenden User. Bei dem neu angelegten User hat es jetzt mit User/Passwort funktioniert.

37

Also der jetzt behobene Bug bezog sich eindeutig auf den Fall Token-Authentifizierung.

Und zwar wurde als Bearer-Token irrtümlich nicht das konfigurierte Token, sondern der Wert aus dem Feld “Passwort” mitgeschickt. Oder eben ein leerer String, wenn man Benutzer/Passwort nicht ausgefüllt hatte.

1 Like
38

@Torben Falls Du das bei dem ganzen Stress übersehen hast: Ist das gewollt oder ist das ein Bug (und Du hast es für später auf der Liste)?