Ist unterwegs.
Danke. Problem erkannt:
Beim Bauen des Hook-Containers werden zwar die Hook-Punkte auf die normalen Cuepunkte umkopiert. Allerdings bleiben die “unbeteiligten” Cuepunkte erhalten, insbesondere Start Next.
Im Ergebnis erhält man nun einen Titel, bei dem Fade Out irgendwo in der Mitte des Songs liegt (am Ende des Hooks eben), und Start Next irgendwo am Ende.
Bis Version 4.2 war das nicht “zulässig”, und Start Next wurde einfach ignoriert. In mAirList 4.3 hingegen darf Start Next nun auch nach Fade Out liegen - die Wiedergabe läuft bei Fade Out also erstmal weiter, bis der Start Next erreicht ist. Da aber der Hook Out zum Cue Out geworden ist, endet die Wiedergabe dann dort vorzeitig.
Ich hoffe das war verständlich 
Abhilfe: Ich habe in Build 1836 die Funktion zum Bauen der Hook-Container dergestalt geändert, dass alle “unbeteiligten” Cuepunkte (Ramp, Start Next, Outro, …) entfernt werden. Übrig bleiben nur Cue In, Fade Out und Cue Out, als Kopie von Hook In, Hook Fade, Hook Out.
LACH … ich mußte es zwar dreimal lesen, aber ja ich habe es verstanden. Das hört sich nach einer sicheren Lösung an die vermutlich allgemein besser ist.
Vielen Dank
Nicht wirklich ein Bug, aber ich vermisse in der 4.3 die Trennstriche im Cue-Reiter bei Containern und beim Auswahl vorhören.
In Build 1843 sind sie wieder da, danke für den Hinweis.
Ich habe keinen Bug, eher einen Verbesserungsvorschlag/eine Gewohnheitssache.
Unter Mairlist 4.2 konnte man unter den Eigenschaften nach dem Klicken auf “exportieren” Die Daten in den ID3 Tag, die DB exportieren. Mittlerweile kann man unter Exportieren auch importieren. Was ich persönlich hinderlich finde ist die Anordnung des Kontextmenüs, da die Import Funktionen an der Stelle liegen wo früher die Export Funktion war. Ich habe mir so schon einige Änderungen verhauen, da ich es gewohnt bin auf exportieren zu klicken und die Maus nach rechts zu ziehen und wieder zu klicken… Evtl. geht es ja anderen auch so 
Daher die anfrage ob es möglich wäre das Kontextmenue individuell anzupassen?
Durch die neuen Funktionen verwirrt die Bezeichnung des Buttons “Exportieren”. Das ist ähnlich wie bei früheren Windows Versionen “klicke Start um zu beenden”
Logischer wäre die Namensgebung “Im-/Export” oder ähnlich.
Die Bezeichnung des Buttons finde ich selbst auch nicht so gelungen, aber für einen längeren Text war kein Platz (dann hätte sich der verfügbare Raum für den Schiebregler der Vorhörfunktion sehr verringert).
Wenn du einen Vorschlag für eine bessere kurze Beschriftung hast, immer her damit!
“Im-/Export” würde vielleicht noch gehen, sind ja nur vier Zeichen mehr; aber das finde ich optisch auch nicht so schön.
hm, also im/export wäre schon besser, weil nicht so verwirrend, und dann wenn es geht die reihenfolge eben auch ändern:
oben import, unten export
wir lesen eben von oben nach unten
somit logischer.
aber is eben nur nen vorschlag meinerseits.
ich hab soeben auf die 1848 geupdatet, hatte vorher die 1844 und hab nun wieder das UTF problem, bugreport gesendet.
ich hab nun die 1844 drüberinstalliert, und keine probleme mit der version dann (1844)
Wie sich herausgestellt hat, gab es noch ein zweites UTF-8-Problem. Ich versuche das mal kurz zu erklären:
Für mAirList 4.3 musste ein Update der Datenbankbibliothek “ZeosLib” vorgenommen werden: Seit Build 1828 wird Version 7.0 verwendet, die ein Feature/Bugfix mitbringt, das dringend für v4.3 benötigt wurde.
Leider hat die neue ZeosLib-Version ein Problem mit der Zeichencodierung, also mit welchem Zeichensatz die Datenbank angesprochen wird. Da mAirList (noch) keine Unicode-Anwendung ist, müssen die Datensätze bei der Übertragung von/zu der Datenbank jeweils vom lokalen Zeichensatz (Codierung) nach Unicode und zurück gewandelt werden.
mAirList 4.2 sowie v4.3 beta bis einschließlich Build 1827 haben dazu die Codierung WIN1252 benutzt, was absolut korrekt ist.
Von Build 1828 bis 1832 wurde gar keine Konvertierung durchgeführt, was sofort in korrupten Datensätzen resultierte.
Von Build 1833 bis 1845 wurde der Zeichensatz LATIN1 verwendet, der mit WIN1252 fast identisch ist - aber eben nur fast, wie sich herausstellte, als mehrere User das Upgrade von 4.2 auf 4.3 machten und alte 4.2-Datensätze zum Teil nicht mehr lesbar waren.
Seit Build 1846 wird nun wieder WIN1252 verwendet, und die Probleme sollten endlich der Vergangenheit angehören. Insbesondere das Upgrade v4.2 -> v4.3 sollte nun ohne irgendwelche Fehlermeldungen auskommen.
Hatte man allerdings eine Version zwischen 1833 und 1845 im Einsatz und hat mit dieser die Datenbank bearbeitet oder Playlisten geschrieben, dann befinden sich jetzt ggf. ungültige Datensätze (in LATIN1 geschrieben) in der Datenbank, die manuell korrigiert (nach WIN1252) werden müssen, um mit einer korrekten WIN1252-Version von mAirList gelesen werden zu können.
Wenn wirklich nur die playlist-Tabelle betroffen ist, ist die einfachste Lösung wohl, die Playlisten für den aktuellen Zeitraum zu löschen bzw. neu zu generieren.
Ansonsten kann man auch UPDATE-Befehle per SQL absetzen, die die ungültigen Zeichen durch gültige ersetzen - allerdings muss man dazu erstmal herausfinden, welche genau es sind, und in welchen Tabellen sie stecken.
In deinem speziellen Fall scheint das Problem in der items-Tabelle und dort in der filename-Spalte zu sein; also irgendwo gibt es einen Dateinamen mit einem ungültigen Zeichen, der nicht richtig übersetzt wurde.
Vielleicht erzeugst du mir einfach mal ein Backup der Datenbank (im “COMPRESS”- oder “benutzerdefinierten” Format) und lädst ihn mir irgendwo hoch.
öhm, versteh ich das jetzt richtig ?
die zig tausend tracks manuell kontrollieren nach umlauten, wenn ich nicht mal weis welcher umlaut spinnt ?
versteh ich grad nicht.
ok, ich nutze postgre.
pgadmin
datenbank ausgewählt
rechte maustaste
sicherung
format tar
Kompressionsverhältnis ?
Kodierung ? (ich nehm mal an Latin1 weil ich die 1844 verwende ?
Ich habe das letzte Woche mit einem anderen Kunden durchexerziert. Da waren es unter dem Strich 5-6 Zeichen, die Probleme machten, und es konnte mit 5-6 SQL-Befehlen korrigiert werden, die man einmal kurz drüber laufen ließ 