Ja, sowohl der Encoder als auch die Logging-Schnittstellen unterstützen das nun.
Danke Torben , super entwicklung !
Kein richtiger Fehler, eher ein Feedback zur Beta:
Im Laufe der Beta wurde die Stille-Erkennung für Streams geändert:
[*] Stream/Live Feed: Silence detection will only become active when the
player is started
TL;DR: Ich fände es praktisch, wenn der Modus (Stille auch schon vorher erkennen, oder nicht), auch einstellbar wäre.
Langfassung:
So, wie es jetzt ist, ist es auf jeden Fall intuitiver.
Der vorherige “Modus” hatte aber einen Vorteil für, ich nenne sie mal “externe open-end”-Events oder Parties, die man automatisiert übernehmen möchte.
Wenn man beispielsweise nicht weiß, ob das Event bis 2, 3 oder 4 Uhr geht - zur vollen Stunde soll aber ein Service-Block, Opener etc. kommen. Nun lief “die letzte Platte” auf der Party um 3:58, in der 4 Uhr Playliste ist aber noch das Stream-Element drin. In den vorherigen Builds merke man das nicht, weil der Stream dann z. B. nach dem Opener direkt übersprungen wurde und Musik spielte. In den aktuellen Builds wird der Stream angestartet, bis zum Timeout ist dann Stille zu hören.
Im konkreten Fall ging es um die Übernahme von Nachrichten, die über einen Codec angeliefert und via Live-Feed abgespielt wurden. Szenario: Auf der Leitung ist bis zum Beginn und nach Ende der Nachrichten durgehend Stille.
Hier war es hinderlich, wenn das Live-Feed-Element um xx:00:00 startet, im gleichen Moment der Sprecher sein erstes Wort sagt, aber direkt die Stille-Eerkennung auslöst, weil im vorgepufferten Element bislang nichts zu hören war. Daher habe ich das kurzfristig geändert.
Es konfigurierbar zu machen ist grundsätzlich eine gute Idee, auch wenn es mir vor den Codeänderungen graut, um das Flag von der GUI bis in den letzten Winkel der Silence-Detection durchzureichen…
Ansonsten denke ich, sollten wir das Thema Stream-/Feed-Übernahme eines Tages einmal komplett neu denken. Eine Mischung aus den heutigen beiden Möglichkeiten “via Element” und “Stream-Monitor”, so dass man nur noch definiert, von xx:xx bis yy:yy will ich einen Stream übernehmen, aber wenn der früher endet, dann soll das Programm weiterlaufen. Und auch mit der Möglichkeit, die Übernahme für Nachrichten, Werbung etc. zu unterbrechen.
Aber ds ist kein Thema für die 7.3 und soll daher in diesem Thread auch nicht diskutiert werden.
Hallo zusammen,
bei mir schreibt im aktuellen Build 5612 der Datei-Mitschnitt-Encoder keine Einträge mehr ins Cuesheet. Ich konnte das in einer Defaultinstallation reproduzieren, in der lediglich die Datenbankverbindung und der Mitschnittencoder hinzugefügt (Cuesheet natürlich aktiviert) wurden.
Das Symptom ist, das Cuefile wird angelegt, beinhaltet aber hinterher lediglich die Kopfzeile+Zeilenumbruch:
FILE "Aircheck-2023-12-17-15-53-49.mp3" MP3
Mir ist beim Testen auch aufgefallen dass IEncoderConnection
im Skriptinterface neuerdings die folgenden beiden Prozeduren nicht mehr exportiert. Vielleicht hängt das ja zusammen:
Procedure ItemStarted( iItem : IPlaylistItem; iRegion : byte)
Procedure ItemCurrentTitle( iItem : IPlaylistItem; iTitle : string; iRegion : byte)
Die internen Abläufe des Logging-Systems wurden in Version 7.3 teilweise erneuert, um das neue Feature “Titelupdate wenn kein Element spielt” zu ermöglichen.
Hier lag tatsächlich ein Bug vor. Bitte testet mal den soeben hochgeladenen Build 5613, ob es dort wieder funktioniert.
Jawoll, damit geht es wieder! Super
Da das Logging anscheinend gerade aufgeschlaut wird: Wäre es generell möglich dem Datei-Encoder in dem Zuge beizubringen den Itemtyp als Kommentar im Cuesheet zu vermerken, so wie es der Aircheckrecorder bereits macht (z.B. REM MAIRLIST_ITEMTYPE "Music"
)?
Hi Zusammen,
hier mal wieder etwas, das sich nicht verhält wie erwartet:
Beim Abspielen von Titeln im Mix-Editor werden im Systemlog Playlist
“Start
” und “Stop
” Events geloggt, sowie OnItemStart
und OnItemStop
Events emittiert. Gemäß der Angaben im Skript-Template sollten diese Events nur bei der On-Air Wiedergabe getriggert werden.
Hier ein Beispiel. Der Titel wurde lediglich kurz im Mixeditor angespielt:
- Das Verhalten tritt in allen 7.3 builds auf die ich gerade zur Hand habe (5610 bis 5615)
- 7.2.5 ist nicht betroffen
- Getestet habe ich all das in Defaultkonfiguration, mit nur einem minimalen Backgroundskript zum Feststellen der Events (dessen Output im Screenshot zu sehen ist).
Wird in Build 5616 behoben sein, danke.
Das interne Logging-System wurde für das “not playing”-Feature umstrukturiert, dabei hat sich das wohl eingeschlichten.
Hallo,
Build 5618 von heute gibt auf meinem PC (Windows 11 mit Standard-Windows Defender) eine Virenmeldung aus. 5617 und früher funktionierten ohne Probleme. Ging zurück zu 5617 und die Nachricht verschwand wieder.
Ich habe die mAirList.exe bei https://www.virustotal.com/ hochgeladen, und da ist alles auf grün - bis auf Microsoft, die meinen, es sei ein “Program:Win32/Wacapew.C!ml” drin versteckt.
Also aller Wahrscheinlichkeit nach ein false positive. Insbesondere zu diesem angeblichen Virus findet man eine Menge Treffer bei Google: Program:Win32/Wacapew.C!ml - Google Suche
Der Defender schaut leider nicht nur nach nackten Viren-Signaturen, sondern zieht auch andere Kriterien heran - zum Beispiel, ob es sich um eine erwiesenermaßen “gute” Programmversion eines etablierten Herstellers handelt. Als kleine Softwareklitsche mit häufigen Updates hat man da schlechte Karten.
Ich werde morgen nochmal versuchen und (wenn es wieder passiert) ein Screenshot machen. Es ist mehr als signal das es passieren kan
@Calypso
Deaktiviere den Defender und versuche es dann noch einmal mit dem Download. Sollte aber funktionieren.
Ich hab noch die 6er Version auf meinem Windows 10 Rechner laufen.
Hatte im letzten Jahr aber nicht großartig die Zeit (aus privaten Gründen)gehabt, mich mit mAirList zu beschäftigen und vorallem zu aktualisieren.
Ende vom Lied:
Anfang Januar den Rechner zum Aktualisieren angemacht und schon ging das Gezicke von Windows los. Angeblich wäre die .exe von mAirList eine schädliche Datei oder irgendwie so blümerant ausgedrückt…
Hab’s aber mit Trick 17 und Selbstüberlistung dann trotzdem hin bekommen…
Nicht notwendig. Ich glaube dir das schon. Und virustotal bestätigt es ja auch.
Andererseits ist das halt ein false positive, und ich habe absolut keine Handhabe. Gegenüber dem vorherigen Build sind genau die Codezeilen hinzugekommen, die ich in dem andernorts erwähnten GitHub-Issue beschrieben habe:
procedure Set8087CWThreadSafe(ANewCW: Word);
var
L8087CW: Word;
asm
mov L8087CW, ANewCW
fnclex
fldcw L8087CW
end;
function SetRoundMode(const RoundMode: TRoundingMode): TRoundingMode;
var
CtlWord: Word;
begin
CtlWord := Get8087CW;
Set8087CWThreadSafe((CtlWord and $F3FF) or (Ord(RoundMode) shl 10));
Result := TFPURoundingMode((CtlWord shr 10) and 3);
end;
Warum diese jetzt plötzlich dazu führen sollen, dass da ein "Program:Win32/Wacapew.C!ml” im Code versteckt ist, weiß nur Microsoft.
PS: Habe jetzt nochmal neu kompiliert, diesmal mit dem Kommandozeilen-Compiler von Delphi anstelle mit der GUI, und jetzt ist angeblich kein Virus mehr drin lt. virustotal.com. Download ist aktualisiert.
calypso?! Ich bin irritiert.
[Randbemerkung]
Aus dem heute morgen erhaltenen Newsletter einer ebenso “kleinen Softwareklitsche”, die es ähnlich lang wie mAirList gibt und die vergleichbar häufige Updates veröffentlicht:
For fake Smart Screen threat alerts, ask Microsoft why.
Gut, die Nummer mit dem Smart Screen dürften die meisten von uns inzwischen kennen. Das mit dem Defender ist scheinbar eine verschärfte Variante.
Wird Torben jetzt viel Geld an Microsoft zahlen müssen, um als seriös, zumindest in deren Augen, zu gelten? Meine private Meinung dazu würde zu einer Wortwahl greifen, die an dieser Stelle unangemessen erscheint.
Als ich mich gestern im privaten Umfeld umgehört habe, wurde mir zu einem hoch dekorierten (und teuren!) Schutzprogramm geraten und gleichzeitig empfohlen, den Defender abzustellen.
Andererseits konnte ich gestern auf meinem privaten Senderechner ohne jegliche Einschränkung eine Sendung fahren, als wäre nie etwas gewesen.
Windows 11, mAirList v7.3-Beta.
Während Torben gestern festgestellt hat, dass die Defender-Signatur ab *.2933.*
oder höher keine Probleme mehr zu bereiten scheint (siehe mAirList 7 tripped MS Anti-Virus - #3 by Torben), habe ich schon gestern Abend auf verschiedenen Rechnern gleich zwei verschiedene, höhere Signaturen registriert. Microsoft ist also recht aktiv in der Angelegenheit. Manche merken diese Störung vielleicht gar nicht - so, wie ich auf meinem privaten Senderechner.
Letzter Stand bei mir:
Antiviren-Version: 1.403.3033.0
Aus all’ diesen persönlichen Erfahrungen lautet meine private Einschätzung: An mAirList v7.3-Beta liegt’s nicht.
Ich drücke euch die Daumen.
[/Randbemerkung]
SmartScreeen ist nochmal eine andere Geschichte. Da geht es eher darum zu ermitteln, ob die Anwendung aus einer vertrauenswürdigen Quelle kommt.
Das Stichwort dazu heißt: Code-Signing. Dazu muss man ein Zertifikat kaufen. Das mache ich schon seit etlichen Jahren, aktuell noch mit einem “Organisations-validierten” (OV) Zertifikat, das ca. 250 Euro pro Jahr kostet.
Leider reicht Microsoft das inzwischen nicht mehr aus, selbst mit OV-Zertifikaten wird man als “unbekannter Herausgeber” angesehen. Stattdessen muss man jetzt eine “EV-Zertifikat” verwenden, wenn man am SmartScreen vorbei will - das ist nochmal teurer, kostet ca. 400 Euro pro Jahr.
Außerdem hatten die EV-Zertifikate bisher den Nachteil, dass sie nur mit einem Hardware-Dongle als Key funktionieren. Das bedeutet, man kann die Software nur noch an dem (Büro-)Rechner kompilieren und das Setup hochladen, an dem das Dongle steckt. Das passt mal so gar nicht zu meiner Arbeitsweise, auch mal abends oder am Wochenende von zuhause oder von unterwegs aus einen Snapshot hochzuladen.
Leider wurden die Regeln mittlerweile auch für OV-Zertifikate angepasst. Das heißt, wenn mein jetziges, dateibasiertes OV-Zertifikat nächstes Jahr ausläuft, muss ich ohnehin auf ein Hardware-Dongle wechseln, und dann kann man auch die 150 Euro mehr für ein EV-Zertifikat ausgeben.
Nur mit den schnellen Bugfixes und Snapshots hat das dann ein Ende. Neue mAirList-Versionen nur noch unter der Woche zu Bürozeiten möglich. Außer ich will das Dongle dauernd mit mir rumschleppen (und potentiell unterwegs verlieren, was dann richtig teuer wäre).
Dafür ist dann alles “sicherer”. Findet SmartScreen.
Version 7.3 hat heute, am World Radio Day, den Beta-Status verlassen und ist mit Build 5621 hiermit offiziell produktiv.
Vielen Dank allen Testern und Hinweisgebern.