Haben die Elemente eventuell keine Cue-Punkte mehr und laufen bis zum Ende durch? Erst dann beginnt ja das nächste Element der Playliste…
Die Planlänge spielt eigentlich beim Abspielen keine Rolle, sie gibt dem Scheduler nur eine Maßgabe für die PLANUNG der Stunde. Ist sie auf vier Sekunden eingestellt, wird der Scheduler versuchen, nur Elemente mit maximal dieser nutzbaren Länge (CAVE: Von Cue-/Fade-In bis zu Fade-/Cue-Out/Start Next) auszuwählen und zu planen.
Anhand der gegebenen Beschreibung und Screenshots ist keine sinnhafte Analyse möglich.
Vorschlag: In der Playlist beide Elemente markieren, Mix-Editor aufrufen und davon einen Screenshot erzeugen.
Sie erleichtert in der Stundenvorlage eine ungefähre Einschätzung der Sendestunde anhand der Plan-Längen und der daraufhn automatisch kalkulierten Länge von “Auffüllen mit Musik”.
Und trotzdem hatte es keinen Einfluss auf das Element, wie der nachfolgende Screenshot zeigt: Die effektive Spieldauer beträgt 3 Sekunden. 
Guter Ansatz, daher der Vorschlag mit einem Blick in den Mix-Editor.
Kannst du mir das bitte mal anhand des MiniSchedulerLog zeigen? Ist mir noch gar nicht aufgefallen…
@Stefan_Hillen die Elemente haben Cue-Punkte und teilweise Start Next. Auch wenn sie bis zum Ende laufen würden, sollte keine Stille entstehen, da die Elemente kurz danach zu Ende sind.
Wo finde ich denn den MiniSchedulerLog?
Problem ist immernur zwischen #1 Zeitansage und #2 Stationsansage_kurz
Wenn weitere Informationen erforderlich, bitte melden.
Warum? Soll man die Minuten nicht hören?
Doch, die soll man hören! Aber die anschließende Stille nicht mehr!
Diese Frage war, wenn Sie bitte nochmal nachlesen möchten, an Stefan gerichtet. Natürlich würde ich mir nicht anmaßen, Sie zu duzen, nachdem es vor einiger Zeit Ihr Wunsch war, in unserem Umgang miteinander gesiezt zu werden. Das respektiere ich.
Insofern kann sich das gar nicht auf Sie bezogen haben.
Ganz allgemein: Der MiniSchedulerLog ist für Ihre konkrete Fragestellung nicht wichtig; er führt zu keinen neuen Erkenntnissen. Sofern Sie ihn erzeugen lassen (dazu bedarf es einer Aktivierung des Logs), wird er im standardmäßig Verzeichnis
C:\ProgramData\mAirList\[Versionsnummer]
gespeichert. Man kann das Zielverzeichnis des Logs aber in der Konfiguration verändern.
Haben Sie nach der Änderung im Auto-Cue diesen denn dann auch neu berechnen lassen? Allein durch den Eintrag in der Konfiguration ändern sich die Cue-Punkte der Elemente ja nicht automatisch.
Außerdem finden Sie weitere Anregungen sowie einen Erfahrungsaustausch in diesem Thread: Auto-Cue: Eure Einstellungen?
Möchten Sie Ihre Erfahrungen dazu beitragen?
Interessant in diesem Zusammenhang sind die technisch herausragenden Ausführungen von @Tondose in diesem Thread:
Ich hatte um einen Screenshot des Mix-Editors der beiden Elemente, zwischen denen die Stille auftritt, erbeten:
Wird der noch nachgereicht oder ist eine Analyse von der Seite her nicht mehr gefragt?
Beim Beobachten ist mir aufgefallen, dass die 11:00 Ansage wieder eine größere Stille aufweist.
Habe mit daraufhin diese Zeitansage genauer angesehen. Bei dem Cue-Editor habe ich nichts auffälliges gefunden. Als ich mir aber den Verlauf aungesehen habe, konnte ich folgendes feststellen:
In der Datenbank ist für die 11:00 Zeitansage eine duration von 2.131 und bei totalduration mit 2.264 angegeben.
Wie kommen diese unterschiedlichenLängen in der Verlaufsanzeige zustande?
Habe mir auch noch mal andere Zeitansagen angesehen, das Problem begann am Sonntag den 24. April. An diesem Tage habe ich die Auto-Cue Einstellungen geändert, weil beim Einlesen von neuen Titeln, die Fade-Out-Punkte zu früh lagen. Die Punkte werden wohl scheinbarvon der reduzierten Lautstärke berechnet und nicht mehr wie früher von der originalen Lautstärke.
Aber wie kann dies Auswirkungen auf die Länge beim Abspielen der Files haben?
Nein, siehe Nachbarthread.
Erneut die Frage:
Und deswegen blendest Du die Stille aus. Aha.
Für die Zeitansagen habe ich damals die Cue-Punkte nicht neu berechnen lassen!
Warum schwanken aber die Zeiten zwischen 4 und 10 Sekunden, ohne dass ichetwas ändere?
Die Stille ist bis zu 10 Sekunden lang! Das hört sich echt besch… an.
Ich glaube, dass ich an dem selben Tag auch den mAirList Software auf die neuste Version durchgeführt habe.
Bitte laden Sie die betreffende Datei nach mairlist.com/upload hoch, damit ich mir die anschauen kann.
Vielleicht auch gleich die “Stationsansage kurz” mit dazu, damit wir das in Kombination testen können.
Tritt das ausschließlich in der Automation auf, die direkt auf den Encoder geht oder ist ein Mischpult dazwischengeschaltet? In letzterem Fall: Bitte überprüfen Sie, dass alle Audiogeräte in der Konfiguration auf WASAPI und nicht auf DirectSound stehen.
Vielen Dank.
Habe alle Zeitdateien und Stationsansage _kurz hochgeladen.
Die Zeitdateien sind vom21.02.2021 und seitdem nicht mehr geändert.
Es gibt kein zwischengeschaltetes Mischpult. Alles läuft über die Automation. Es gibt nur noch ASIO für den Encoder Ausgang und den Mikrofon-Eingan. Aber da hat sich seit Monaten nichts verändert.
Wenn weitere information benötigt werden, bitte melden!
Schon einmal Danke!
Ein erster, kurzer Test hat keine Auffälligkeiten gezeigt. Alles in bester Ordnung und läuft einwandfrei.
Erst einmal Danke.
Es ist auch monatelang einwandfrei gelaufen. Navch meiner Auffassung kann es nur mit der Umstellung auf R128, Änderung der Auto-Cue-Daten oder dem neuem Build zusammen hängen.
Es ist schon alles sehr seltsam.
Gerade kamm die 21:00 Zeitansage, welche sich mit 4.2 s schon fast wieder normal angehört hat.
Aber woher kommen die großen Unterschiede? Es ändert sich an den Files und der Konfiguration doch nichts!
Heute gab es um 12:00 eine Länge von 14.0 s und um 13:00 10.4 s, mit anderen Worten um 12:00 eine Stille von fast 12s und eine Stunde später vo 8 s. Die Audios sind aber nur zira 2 s lang!
@UliNobbe, wäre es da nicht mal an der Zeit, dass Torben sich des Problems mal annehmen sollte?
@UliNobbe habe heute Nacht mAirList neu gestartet. Seitdem konnte ich keine große Stille mehr zwischen den Ansagen feststellen
Habe mir die Zeiten unter Verlauf nochmals genauer angesehen. Auch im “Normalbetrieb” ohne längere Stille, kommt es zu Zeitunterschiede von etwa +/- 1s. Da die Zeitansagen und die nachfolgende Stationsansage_kurz sich nicht verändern, verstehe ich nicht so recht, wie es zu diesen Unterschieden kommt!
Ich tippe auf Deinen Rechner/Hardware…mAirList spielt normal alles sauber ohne Probleme ab
Ich stimme Ihnen insoweit zu, als dass ein so kurzes Element nicht länger spielen sollte als seine echte Dauer.
Was hier protokolliert wird, ist der Zeitraum zwischen Start und EOF-Rückmeldung.
Jetzt mal technisch: mAirList fügt von alleine keine Stille an die Datei an. Am EOF wartet mAirList auf die BASS-Rückmeldung, ob die Datei denn auch wirklich ausgespielt wurde. These: BASS bleibt (warum auch immer) am Ende der Datei stehen und mAirlist wartet darauf, das nächste Element abspielen zu dürfen.
Aber warum? 
Sie sollten an den entsprechenden Stellen einen Eintrag im Systemprotokoll finden (nötigenfalls erweitern Sie bitte den Filter). Findet sich dort etwas auffälliges?
Ich nehme an, dass sie ein logisch denkender Mensch sind, der sachlich fundierten Argumenten zugänglich ist (hoffentlich täusche ich mich nicht!).
Angenommen, unsere Software hätte einen Bug, der bei Ihnen zu besagtem Phänomen führt: Müsste der dann nicht bei jedem mAirList-Benutzer auftreten, der eine 24/7-Automation am laufen hat?
Unsere Kunden, egal ob professionell oder Privatanwender, würden im Forum und im Premium-Support Alarm schlagen: Hilfe, Sendelöcher!
Wir würden ob der schieren Menge an Fehlermeldungen den bei allen Anwendern auftretenden Fehler identifizieren und mittels Snapshot beseitigen. Keine Frage.
Ich habe gerade nochmal nachgeschaut: Nein, nichts. Wir haben andere Sachen auf dem Tisch liegen, aber was ihre Beobachtung betrifft, sind aktuell nur Sie der einzige Melder.
Und jetzt denken Sie, Torben solle sich “des Problems annehmen”, das offenbar nur bei Ihnen besteht?
Denken wir kosequent logisch weiter: Müsste das nicht heißen, dass Sie ein besonderes mAirList mit einem Code haben, der nur bei Ihnen zu Unregelmäßigkeiten führt, bei den anderen aber nicht?
Ich schätze, sie erkennen selber den Bruch in der Logik Ihrer Argumentation.
Vorschlag: Überprüfen Sie bitte die Audiogeräte auf DirectSound und beobachten Sie das Systemprotokoll.
Weiterer dringender Vorschlag: Aufgrund dieser Merkwürdigkeit …
… bitte alle Zeitansagen hart abschneiden bzw. mit Cue-Out versehen. Alle Fade-Outs löschen.
