Hallo allerseits,
mir ist heute aufgefallen, dass in der db-Suche bei Umlauten zwischen Groß- und Kleinschreibung unterschieden wird. Und zwar offenbar nur bei Umlauten. Suche nach “d.ö.f.” findet nix, Suche nach “d.” findet “D.Ö.F.”, Suche nach “Ö.” findet “D.Ö.F.”, Suche nach “ö.” findet nix. Bug or feature?
Schöne Grüße
Martin
hmm, das würde erklären, warum ich immer Probleme habe, die Ärzte zu finden, weil ich eigentlich grundsätzlich in kleinschrift suche.
Wir müssen das näher eingrenzen.
Eine Spontansuche mit “ötzi” lieferte mir direkt alle Suchergebnisse mit “DJ Ötzi”.
Ich habe jetzt allerdings den Begriff direkt in der Datenbank / Bibliothek im dortigen Suchfeld eingegeben.
Malte & Martin, war das bei euch vielleicht im Browserfenster > Datenbank-Suche?
Okay… da ist wirklich eine Anomalie drin. Allerdings habe ich eine andere gefunden. ???
Gebt in das Suchfeld doch bitte mal “jürgen” ein (ja, klein geschrieben).
Die Datenbank darf da ruhig mal Udo Jürgens, Jürgen Drews, Jürgen Marcus etc. auswerfen.
Klappt bei mir sowohl klein geschrieben als auch “normal”.
Aber: Sucht bitte mal nach “JÜRGEN”.
Bei mir, im Gegensatz zu vorher: Null Ergebnisse. :o
Torben, könntest Du das bitte erklären und ggf. beseitigen?
Ja genau. Browserfenster Datenbanksuche.
Bei mir im Studio nutze ich das Datenbankinterface so gut wie gar nicht. Sendung wird direkt in die Hauptplayliste geplant.
Lediglich zum Synchronisieren bemühe ich mal das DB Fenster.
Moin…Den von Uli beschriebenen Bug kann ich für Version 3930 bestätigen,
bei Kleinschreibung Ergebnisse vorhanden, mit großem Anfangsbuchstaben 0 Ergebnis.
Nachdem ich den Server auf Version 3.1.9 aktualisiert habe, habe ich das hier gerade noch einmal geprüft.
Suchbegriff ärzte liefert kein Ergebnis.
Suchbegriff Ärzte liefert alle Ergebnisse.
Beim Ötzi genau so. klein geschrieben, keine Ergebnisse, mit großem Ö, alle Ergebnisse.
Gegenprobe beim Jürgen: suchbegriff jürgen liefert Ergebnisse, Suchbegriff JÜRGEN, liefert keine.
Also Umlaute sind Casesensitive.
Wohingegen Suchbegriffe ohne Umlaute, die jeweils gleichen Ergebnisse liefern.
Auf meinem Server läuft eine PostgreSQL Datenbank und bei mir im Studio läuft eine lokale DB, beide verhalten sich gleich. Also am DB Backend liegt es nicht.
Greetz
Malte
EDIT: Das betrifft nicht nur die Suchmaske im Explorer, sondern auch die Datenbankverwaltung selber. Sowohl in der Bibliotheksansicht wie auch in der Playlistenansicht, habe ich mit dem Suchfeld unten links, das gleiche Phänomen.
Stellt sich also die Frage Könnte das einen Effekt auf die Artist-/ Title Seperation haben, beim Minischeduler?
Die Suche benutzt den SQL-Operator LIKE (bzw. ILIKE bei PostgreSQL) für den Vergleich. Offenbar kann der nicht bei allen Systemen korrekt mit Umlauten umgehen.
Auf die Separation hat das keinen Einfluss, da der Scheduler zunächst die Gesamtliste aller Elemente im Ordner herunterlädt und dann auf Anwendunsebene vergleicht.
Demnach müsste es sich aber auf meinem Server mit dem PostgreSQL Backend und auf meinem Studiorechner mit SQLite, unterschiedlich verhalten. Ist aber identisch.
Oder anders herum, ich könnte verstehen, dass das auf dem PostgreSQL ein Problem macht aber woher soll das bei SQLite kommen, wenn alles auf der gleichen Maschine passiert?
Ich denke nicht, dass das einen Einfluß hat, weil die Umlaute nur innerhalb der DB auftreten aber auf dem Server sind keine locals installiert, der läuft also als en_US.UTF8 auf debian 9.
PostgreSQL ist Version 9.6, die standardmäßig mit Debian kommt.
Das ganze in einem LXC Container auf Proxmox.
Laut PostgreSQL Doku (PostgreSQL: Documentation: 9.6: Pattern Matching) wäre ILIKE gezielt Casesensitive.
The key word ILIKE can be used instead of LIKE to make the match case-insensitive according to the active locale. This is not in the SQL standard but is a PostgreSQL extension.Ich weiß nur nicht, wie ich den Nachsatz "according to the active local" deuten soll. Nutzt PostgreSQL die vom Server (die bei mir ja nicht gesetzt ist) oder eine eigene. Ich meine, ich habe damals den Wiki-Eintrag befolgt: https://wiki.mairlist.com/tutorials:mairlistdb:setup-postgresql Da wird ja nichts explizit gesetzt. Weder in der DB selber noch für Linux.
Die einzigen locales die ich in der Config gefunden habe, sind Zeitzone, error messages, numeric, time. Da ist also IMHO nichts dabei, was sich auf eine SQL Abfrage mit Umlauten auswirken würde.
Was ich noch nicht ganz einsortieren kann ist dieses Setting:
# default configuration for text search
default_text_search_config = 'pg_catalog.english'
Moin…Nachtrag:
Bei mir arbeitet die Mairlist DB, gebe ich jürgen oder juergen ein, bekomme ich unterschiedliche Ergebnisse.
Gebe ich JÜRGEN ein, setzt der Browser JÜRGEN auf jürgen, macht also aus groß=Kleinschrift. das mit Return bestätigen liefert Ergebnisse.
JUERGEN liefert direkt Ergebnisse, in dem Auswahlfenster wird direkt auf klein gesetzt und gesucht…Kurios das ganze…
Bin ich froh, dass ich keinen Jürgen in der Rotation habe ;D ;D
Das habe ich auch beobachtet, dass das zurückgesetzt wird aber gesucht wird nach dem richtigen Begriff, der tatsächlich eingegeben wurde.
National betrachtet mag das nach einer “Lösung” aussehen, aber mAirList ist ja nun mal eine weltweit vertriebene und eingesetzte Software. Und da gibt es viele Sprachen, die Sonderzeichen aufweisen - der gesamte skandinavische Raum, Frankreich, Spanien, Portugal, Türkei, Trema in de Nederlandse spelling 8) …
… nicht zu vergessen: Der arabische Sprachraum (in dem ich mich nicht hinreichend auskenne) - wird ja auch in der Konfig berücksichtigt mit “[tt]Optimierung für linksläufige Sprachen[/tt]”.
Von daher ist eine Datenbank-Suche unter Berücksichtigung von Sonderzeichen - ganz gleich, welche - meiner Meinung nach ein elementarer Bestandteil des Programms und hat eine große Bedeutung weitab jeglicher “Jürgens”. ;D
Randnotiz:
Da ich für einen befreundeten DJ die Pioneer-Datenbank rekordbox pflege und an dieser Struktur regelmäßig verzweifle (wenn ich graue Haare bekomme, nenne ich die Farbe “Pioneer” :
), weiß ich den mAirList-Komfort durchaus zu schätzen. In der rekordbox muss ich nämlich regelmäßig alle Umlaute, Accents etc. auskehren, weil sonst a) die Sortierung und b) die Suche am Player (die keine Umlaute kennt) sofort kapituliert.
Beim von Martin zu Beginn des Threads erwähnten Beispiel wäre der Suizid der rekordbox vorprogrammiert: Umlaut und Punkt - das geht gar nicht.
Ich hatte bei mir auch schon nach der EAV bzw. E.A.V. gesucht, aber die Freunde sind bei mir ausgeschrieben… 8)
Martin erinnert mich übrigens an meine Anfänge des digitalen DJ’ings - damals mit BPM Studio. Das Programm hat zwar alle Tags in jeder Schreibweise gefressen, aber wenn man einen ID-Tag im Programm geändert hat, wurde der konsequent IN GROSSEN BUCHSTABEN zurückgeschrieben / gespeichert. :o
Nachtrag:
Habe Gestern eine Neue Datenbank mit Build 3930 erstellt (hatte vorher mit einer erstellten aus 6.0.9 gearbeitet), und getestet. Die Gleichstellung ä=ae, ö=oe, ü=ue, egal ob groß oder klein haut nicht hin. Effekt also wie vorher.
Ich erstelle gerade eine Datenbank mit Sam, Importiere die mal nach Mair, um zu sehen ob der Effekt der gleiche bleibt.
Dauert aber ein wenig, wegen der Menge…
“Meinten Sie: ‘mAirList’?” ;D 8) 
Japp…sry…Heute schon so viel getippert da wird man faul… 
So…leider hatte ich Übersehen, das es mit Sam 4…DB geht, die Version habe ich nicht, daher fällt der Test flach…allerdings besteht das Datenbank Problem bei Sam genauso!!!
Gerade getestet…die DB mit Sam erstellt und bei Eingabe ä,ö,ü genauso unterschiedliche Ergebnisse wie bei Mairlist, also ist es nicht einmal ein Mairlist Bug!
Einziger Unterschied bei Sam, dort ist es egal ob groß oder klein, das liefert immer die gleichen Ergebnisse (ich meine damit AE=ae,OE=oe, etc pp), aber die Gleichsetzung Ä=AE erfolgt auch hier nicht.
(Info Sam 2018, DB= Firebird)
Jemand eine Idee?
Ich habe für mich beschlossen, das Problem anders an zu gehen.
Ich werde meine Datenbank (Rohdaten auf Platte), auf Schreibfehler Prüfen, und alles dementsprechend Anpassen.
Per Script hätte ich zwar schnell alle Files Umbenannt (ae gegen ä ausgetauscht, etc. pp), aber das macht keinen Sinn, da es Interpreten wie Aerosmith, oder Blue System gibt, da hätte man nur neue Fehler eingebaut…schließlich Suche ich im Normalfall mit der richtigen Schreibweise…
Wenn dann alles korrigiert ist, wird eine neue Datenbank erstellt und fertig…
Hier mal ein kurzer Zwischenstand, bin fast fertig mit Durchgucken, hat mit MP3-Tag ca. 30m gedauert, die Interpreten Suchen und Korrigieren. Titel habe ich noch keinen Fehler gefunden…da ist es fast zu Schade weiter bei der Datenbankprogrammierung zu Suchen, da es ein grundlegendes Problem zu sein scheint…
Sorry, wenn ich dieses Thema wieder nach oben hole.
Mir ist nur gerade in den Sinn gekommen, ob vielleicht das hier
auch die Ursache für das Problem beim suchen mit Umlauten sein könnte.
Nur so eine Idee. Vielleicht liege ich da ja auch vollkommen daneben.