Eine kleine Bug-Sammlung zur 1.3.7

Hallo Torben,

auch von mir erst mal ein dickes Lob! Dein Programm ist in weiten Teilen wirklich so, wie ich es schon immer gesucht habe.

Bei der Welle West Wetterau, einem Veranstaltungsradio aus Hessen, sind wir auch gerade auf der Suche nach einem neuen Programm, deshalb haben wir es mal ausgiebig getestet. Die Chancen für einen Einsatz bei uns stehen ziemlich gut, allerdings sind uns folgende Probleme aufgefallen (bezieht sich alles auf 1.3.7):

b Bug: [/b]Löschen und Uncue bewirken z.Zt. beide, dass der Titel im Archiv landet.

b DB-Suche blockiert alles:[/b]
Nach dem Druck auf ‘Enter’ bei einer Suchanfrage im DB-Suche-Browser bleibt die gesamte mAirList blockiert und “wartet” auf das Suchergebnis. Zwar läuft die Wiedergabe weiter, aber diePlayeranzeigen bleiben stehen. Auch die Tastatur- und Joystick-Abfrage wird solange nicht ausgeführt. Das kann Sendelöcher geben…
Vorschlag: Es wäre gut, wenn Du die DB-Suche so programmieren könntest, dass sie unabhängig läuft…

Besonders problematisch wird das übrigens, wenn man sehr viele Titel in der DB hat. Bei uns waren das jetzt ca. 12.000 Stück. Wenn ich nun (aus Versehen) nach “e” suche, dauerte die Suche über 1 Minute.
Vorschlag: Zusätzlich “Sicherheitsabfrage” vor dem Start des Suchvorgangs, wenn nur ein bis drei Zeichen eingegeben werden.
und: “Abbruch”-Button u/o -Taste zum Unterbrechen des Suchvorgangs.

b DB-Baum-Browser:[/b]
Wenn wir diesen Browser bei 12.000 Titeln öffneten, war ganz mAirList über Minuten blockiert. Wir haben nicht abgewartet, ob sich das Programm irgendwann wieder fängt.

b Datei-Baum-Browser:[/b]
In allen Browsern bewirkt ein Doppelklick, dass die Datei ans Ende der Playlist angefügt wird, was sehr gut ist. Allerdings funktioniert das beim Datei-BAUM-Browser nicht.

b Bug im Cardwall-Speichern-Dialog:[/b]
Der Dialog “vergisst” die Erweiterung “.card” automatisch an den Dateinamen anzuhängen.

b LED-Uhr:[/b]
Die LED-Uhr ist übrigens sehr schön! :slight_smile:
Allerdings geht die Uhr zwar an sich richtig (also die hh:mm-Anzeige), aber die Punkte gehen nach. Eigentlich müssten bei 59 sec alle Punkte voll sein und bei 00 sec nur der oberste Punkt.

b Verbindung zur DB weg:[/b]
Wenn man eine MLP- (oder MLT-) Datei öffnet, die mit Titeln aus der DB bestückt war, ist die Verbindung zur DB weg, d.h. wenn ich während der Sendung z.B. Cue-/Ramp-/…-Zeiten setze, kann ich sie nicht in der DB abspeichern; [Speichern (Datenback)] ist nicht verfügbar.
Vorschlag: Es sollte so sein, dass die Zeiten aus der MLP zunächst gelten (weil sie ggf. vom Redakteur der Sendung ja so gesetzt sind und er evtl. Änderungen in der DB ja nicht kennt). Falls aber die Zeiten noch geändert werden und dann so in die DB geschrieben werden sollen, sollte diese Möglichkeit auch bestehen.

Soweit die kleinen und größeren Fehlerchen. Demnächst schreib ich Dir mal ein paar Feature-Requests…

Auf jeden Fall: Nur weiter so!

Viele Grüße
Stefan

Tach Herr E. ,

ich versuch mal dem Torben hier ein bisschen Arbeit abzunehmen.

zu 3.: Das Problem hab ich bereits auch bemängelt, daran wird schon gearbeitet soweit ich weiss.

zu 5.: Auch das wurde bereits mehrfach beanstandet.

zu 7.: Die DB-Verbindung is nur innerhalb der Browser, sobald du die Titel in die Playlist lädst wird das File von der DB entkoppelt. So hab ich es zumindest mal hier im Forum gelesen. Meines erachtens nach ist die Möglichkeit zum speichern in der DB nach dem Laden in die Playlist nur temporär, d.h. die .mlp bzw. .mlt sehen keine kopplung zur DB vor. Daher gibts ja auch die DB Playlist.

Ich wart ja bei uns gewesen und habt das Programm im kritischen EInsatz gesehen. Hatte ich nicht erwähnt das die Playlisten bei uns über die DB geholt werden?
Und weil ja in der DB nur Musik drin sein sollte war die Regel: Alles was nicht Musik ist kommt aus der Cartwall. Was auch wiederum ein Vorteil im Logging bringt: Beiträge, Jingles, aufgezeichnete Interviews, etc. werden nicht geloggt und deswegen auch nirgends angezeigt (Homepage, etc). Die haben da ja auch nix verloren.

Tipp: mAirlist und der Medienhaus Rechner !
Die ganze maschinerie ist in den zehn tagen dreimal abgestürzt - Blauer Bildschirm (bei WIN2K). Das Problem liegt meines erachtens nach aber nicht an der Software sondern an der Soundkarte (Terratec EWS88MT), bzw. am Zusammenspiel beider Komponenten.
Schnelle Problembehebung erfolgt in u.g. Reihenfolge:

  1. Rechner im abgesicherten Modus starten.
  2. Soundkarte deaktivieren
  3. Rechner herunterfahren und PCI-Steckplatz der Karte wechseln
  4. Rechner im Normalbetrieb wieder hochfahren und Soundkarte aktivieren.
    (Hatte schonmal jemand dieses Problem hier im Forum?)

ansonsten kann ich auch nur sagen: Geiles Programm.
Es scheint ja seine Runden zu machen.
Die Seeheimer hattens ja letztes Jahr schon im Einsatz, allerdings nur im Minimalbetrieb. In Heppenheim und Wald-Michelbach wird auch schon damit geliebäugelt.

@Torben:

mAirlist hat unsere Sendewoche überstanden, bis auf o.g. Problem.
Wir werden es mit 99,99999%iger Sicherheit auch nächstes Jahr wieder einsetzen. DU darfst uns auch in dein Referenzen aufnehmen. Ein Logo findest du unter logos.bienenmarktsradio.de

Nun zu meiner Liste:

  1. DB-Browser aktualisiert nicht beim klick auf aktualisieren und geöffnete Elemente klappen nicht zu.

  2. Ich denke es macht Sinn die Komponente zum einfärben der Playlist mit der Musikfarbe der Musikrichtung in der DB zu verknüpfen, oder?

  3. Kann es sein das mAirlist die Lautstärkeeinstellungen aus dem Header des MP3’s nicht ausliest. Die Songs sind bei uns alle verscheiden Laut und wir haben deshalb den MP3Gain drüberlaufen lassen. Im BPM-Studio sind danach alle gleichlaut in mAirlist nicht.

  4. Die Cartwall könnte noch ein paar extras like Cartblaster vertragen.
    Z.b. eine Cart für Musikbett mit seperaten ausspielkanal die stoppt sobald irgendwas anderes läuft und startet wenn sonst nix läuft, bzw. eine Funktion
    fürs Solo schalten von Carts (hatte ich in einem anderen Thread schonmal angeregt->http://forum.mairlist.de/viewtopic.php?t=161)
    Folgende Idee is auch vom Cartblaster abgeguckt: Ein Cart für die Nachrichten die automatisch startet. Man sollte allerdings absolute Zeiten festlegen können (13, 14, 18, 21 Uhr).

So, das sollte mal wieder genügen, ich denke du hast erstmal genug zu tun :slight_smile:

Hallo und Grüße nach Michelstadt!

zu 7.: Die DB-Verbindung is nur innerhalb der Browser, sobald du die Titel in die Playlist lädst wird das File von der DB entkoppelt. So hab ich es zumindest mal hier im Forum gelesen. Meines erachtens nach ist die Möglichkeit zum speichern in der DB nach dem Laden in die Playlist nur temporär, d.h. die .mlp bzw. .mlt sehen keine kopplung zur DB vor. Daher gibts ja auch die DB Playlist.
Ich nehme an, dass die Entkopplung von der DB auch damit zu tun hat, dass - wenn ich das soweit richtig verstanden habe - die DB quasi ein "Aufsatz" auf mAirList ist und mAirList schon immer und auch in Zukunft auch ohne DB auskommen soll. Das finde ich auch vollkommen okay.

Ganz “gelöst” zu sein scheinen die Einträge in den Listen zumindest VOR dem Speichern ja nicht zu sein, denn dann kann man ja noch Änderungen an den Ramp-/…-Zeiten über den Eigenschaften-Dialog abspeichern. Das geht nur nach dem Öffnen einer MLP nicht. Wenn man sich die MLP anschaut, steht da ja auch nichts zur DB drin:

...
      <MP3File>
        <Title>In My Place
        </Title>
        <Artist>Coldplay
        </Artist>
        <Duration>2288326530
        </Duration>
        <Ramp>336790022
        </Ramp>
        <FadeOutPos>2235020408
        </FadeOutPos>
        <FadeOutPos>2235020408
        </FadeOutPos>
        <Filename>\\STEFANXP\MP3\Coldplay - In My Place.mp3
        </Filename>
      </MP3File>
...

… also kann mAirList nicht wissen, dass die Datei auch in der DB steht.

Darum @Torben:
Wär’s denn prinzipiell möglich, einfach zusätzlich zu jeder Datei - soweit vorhanden - die Verknüpfung zur DB mit abzuspeichern?

Ich wart ja bei uns gewesen und habt das Programm im kritischen EInsatz gesehen. Hatte ich nicht erwähnt das die Playlisten bei uns über die DB geholt werden?
Ja, das hattest Du v.a. im Zusammenhang mit Deiner MP3-Archiv- und DB-Spiegelung erwähnt. Ist aber meiner Meinung nach nicht zwingend notwendig. Wenn man sich "sein" mAirList bereits vor der Sendung mit allem Drum und Dran (also Cardwall, Browser) herrichtet und sich das als MLP ins Studio holt, hat das auch wiederum Vorteile.
Und weil ja in der DB nur Musik drin sein sollte war die Regel: Alles was nicht Musik ist kommt aus der Cartwall. Was auch wiederum ein Vorteil im Logging bringt: Beiträge, Jingles, aufgezeichnete Interviews, etc. werden nicht geloggt und deswegen auch nirgends angezeigt (Homepage, etc). Die haben da ja auch nix verloren.
Ich weiß nicht, ob es mir gefällt, wenn O-Töne und Beiträge nur über die Cardwall abgespielt werden. Damit begrenzt man ja absichtlich die Möglichkeit, dass man alles überall abspielen kann, was ich als großen Vorteil sehe. Wir haben hier ein Layout im Probebetrieb, das drei Player mit zwei Playlisten beinhaltet. Der zweite Player mit nur einer Liste wird dann in erster Linie für Einspieler benutzt, wie Beiträge oder Jingles, die genau nur einmal über den Sender gehen sollen. In der Cardwall muss ich sie mir selber wieder raus nehmen, während ich im anderen Fall eins nach dem anderen einfach per Faderstart oder Starttaste abfahre. Praktisch auch: Wenn das Musikbett in der Cardwall läuft und der Beitrag über einen Player, kann ich den Beitrag separat regeln, das Bett in bestimmten Passagen leiser regeln usw.

Das Logging bzw. die Verarbeitung der Logfiles kann man ja auch an anderer Stelle später noch filtern.

Tipp: mAirlist und der Medienhaus Rechner ! ...
Danke für den Hinweis. Wir sind inzwischen dazu übergegangen, einen eigenen Studiorechner schon im Voraus fertig einzurichten und ausgiebig zu testen und benutzen den Medienhaus-PC an anderer Stelle.
Ich wart ja bei uns gewesen und habt das Programm im kritischen EInsatz gesehen. Hatte ich nicht erwähnt das die Playlisten bei uns über die DB geholt werden?
Ja, das hattest Du v.a. im Zusammenhang mit Deiner MP3-Archiv- und DB-Spiegelung erwähnt. Ist aber meiner Meinung nach nicht zwingend notwendig. Wenn man sich "sein" mAirList bereits vor der Sendung mit allem Drum und Dran (also Cardwall, Browser) herrichtet und sich das als MLP ins Studio holt, hat das auch wiederum Vorteile.

Ich kann dir nur dringend raten, das wirst du von Torben auch noch hören,
einen Mirror des Musikarchivs auf der lokalen Platte abzulegen. Weil, im Falle eines Netzwerkausfalls du sofort eine Sendeloch produzierts. Is klar, nä?! Dann wiederum funktioniert das aber mit den *.mlp Dateien nicht weil die den Pfad absolut abspeichern. D.h. dein Studiorechner holt sich die Files dann wieder vom Server.

Ich hatte mit dem ganzen Zeugs ein halbes Jahr lang Testlauf und bin eigentlich der Meinung das den sichersten und auch idiotensichersten Weg gefunden hab. Man muss halt immer bedenken, net jeder der beim Radio mitmacht kennt sich voll mit allem aus. Und kritische Fehler kann auch nur der schnell beheben der die Technik konzipiert hat.
Ich hab im Rahmen letzten AEV-Rundreisetour (letztes Jahr wurd keine Radio ausgelassen) viele Baustellen gesehen, wo ich dachte, Oh Gott, katastrophe.
Wir haben uns zur Regel gemacht, kein Ausfall darf länger als ne halbe stunde Dauern, das is bei “nur” zehn Tagen Sendung eigentlich schon zuviel, hat sich aber bis jetzt bewährt.
Wenn wir was neues ins Gesamtsystem integrieren wird solange nach Fehlern gesucht bis alles ausgemerzt oder zumindest mit Notfallplan versehen ist.
Du kannst mir ja mal nach eurer Sendewoche einen ausführlichen Bericht zukommen lassen wies denn dann letztendlich gelaufen ist und wies ausgesehen hat. :slight_smile:

auch hier nochma @Torben:
Mach doch die *.mlp’s und die Cartwall auch mit relativen Pfaden, sollte doch gehen, oder?

Hi Leute,

erstmal danke für die vielen Anmerkungen und Vorschläge. Ich werde das mal in Ruhe durchgeben :wink: Hier nur ein paar kurze Kommentare:

Zu den absoluten Dateinamen: Wir hatten das Problem schon früher mal im Zusammenhang mit Raduga und haben es folgendermaßen gelöst:
Alle Musikdateien sind in einem Verzeichnis auf dem Server. Dieses ist auf den Clients als Laufwerk M: verbunden. Wenn wir also mit Dateinamen rumhantieren, dann sind das immer welche, die mit “M:” anfangen. Im Senderechner hingegen ist eine Festplatte, auf der das gesamte Archiv gespiegelt ist. Und dort hat die Festplatte den Laufwerksbuchstaben M:. Lädt man also eine Playlist, in der lauter Dateinamen mit M:… drin sind, greift man dann auf die lokale Kopie zu. Fertig :slight_smile:

Zur Datenbank: Zieht man einen Titel von einem Datenbank-Browser in die Playlist, legt sich mAirList lokale Kopien aller Werte (Cue, Ramp, …) usw. an. Einzig und allein die Datenbank-ID (also das Feld idx der Tabelle songs) merkt sich mAirList noch, um die Werte über den besagten Button dann in die DB zurückschreiben zu können. Ansonsten “leben” die Werte aber nur noch in mAirList. Aktualisierungen aus der Datenbank passieren keine. Dass die Datenbank-ID beim Speichern nicht mit in der MLP-Datei landet, ist tatsächlich ein Bug. Den werde ich mal beheben. Allerdings kann es dann lustige Effekte geben, wenn man eine uralte MLP-Datei öffnet, das Lied vielleicht inzwischen aus der Datenbank gelöscht wurde … Naja, malt euch das selbst aus :wink:

Zu den Datenbank-Browsern: Ich benutze da vorwiegend Komponenten aus der JVCL-Sammlung. Offenbar scheinen die - insbesondere dieser Datenbank-Baum - nicht sehr performant zu sein, wenn man es mit großen Datenmengen zu tun hat. Eventuell muss ich das alles mal neu programmieren :frowning: Dass die Suche im Hintergrund läuft, ohne dass der Rest des Programmes blockiert, versuche ich auch mal hinzukriegen.

Torben

Tachchen zusammen,

@rev0lutio:

Das:

Ist aber meiner Meinung nach nicht zwingend notwendig.
hatte ich eigentlich in erster Linie auf die Playlist bezogen, nicht auf die Spiegelung. War etwas unglücklich formuliert.

Aber ich hätte jetzt genau auch vorgeschlagen, mit entsprechend zugeordneten Laufwerksbuchstaben zu arbeiten. Damit hat man - wenn man’s entsprechend einrichtet - sogar die Cards im Studio lokal usw.

@Torben:

... Einzig und allein die Datenbank-ID (also das Feld idx der Tabelle songs) merkt sich mAirList noch, um die Werte über den besagten Button dann in die DB zurückschreiben zu können. Ansonsten "leben" die Werte aber nur noch in mAirList. Aktualisierungen aus der Datenbank passieren keine.
... das ist auch sehr gut. Dann kann nämlich an den Zeiten usw. in der DB frei "herumgestellt" werden, ohne dass das Auswirkungen auf aktuelle Sendungen hat.
Dass die Datenbank-ID beim Speichern nicht mit in der MLP-Datei landet, ist tatsächlich ein Bug. Den werde ich mal beheben. Allerdings kann es dann lustige Effekte geben, wenn man eine uralte MLP-Datei öffnet, das Lied vielleicht inzwischen aus der Datenbank gelöscht wurde ... Naja, malt euch das selbst aus ;)
Wie wäre folgendes: Der idx-Eintrag wird zusätzlich mit in die MLP gespeichert. Beim Öffnen passiert folgendes: 1. Die MLP wird wie bisher zunächst vollständig geladen. 2. Zusätzlich überprüft mAirList, ob der idx in der DB noch existiert 3. Falls ja, dann überprüft mAirList, ob der Pfad in der MLP mit dem Pfad in der DB übereinstimmt. 4a. Falls ja wird die Verknüpfung zur DB aktiviert. Trotzdem werden die Werte aus der DB [b]nicht[/b] übernommen. 4b. Falls nein gibt's eben keine Verknüpfung.

Ggf. könnte man noch überlegen, ob Funktionen wie “Abgleich mit DB für DIESEN Titel” und “… für diese Playlist” sinnvoll wären…

(Da fällt mir noch ein: Für den Fall, dass ich Titel aus einem Datei-Browser in die Playlist ziehe, könnte doch auch hier über einen Pfadvergleich mit der DB der Titel mit der DB verknüpft werden, falls der Titel auch in der DB ist?)

Zu den Datenbank-Browsern: ... Dass die Suche im Hintergrund läuft, ohne dass der Rest des Programmes blockiert, versuche ich auch mal hinzukriegen.
Das wäre echt klasse.

Vielen Dank für Deine viele Arbeit!

Viele Grüße
Stefan

3. Kann es sein das mAirlist die Lautstärkeeinstellungen aus dem Header des MP3's nicht ausliest.

Das kann ich nicht bestätigen. Ich hab gerade einen von zwei identischen Pegeltönen (1KHz 0dBfs) “mp3gegaint” und beide in mAirlist abgespielt. Der “gegainte” hatte erwartungsgemäß einen deutlich niedrigeren Pegel als der unbehandelte.
Würden die Header ignoriert, hätten beide den gleich Pegel haben müssen.

@carsten: Wenn ich mich nicht täusche, ändert mp3gain nicht die Information im Header, sondern direkt die Lautstärke-Info im eigentlichen MP3, kann mich da aber auch täuschen.

@tw

Auch ein subst unter Windows kann durchaus weiterhelfen, um Laufwerkbuchstaben konsistent zu halten. So mache ich das auch.

Zu Hause nutze ich Laufwerk H:\ und M:\ und unterwegs (Laptop in fremden Studio) liegen die Daten auf c:\sync und werden mit subst H:\ c:\sync\home usw. an ihrem Platz zugreifbar gemacht.

Christoph