mir fehlt die Variable im Logging, die Startzeit der mitgesendeten Songs zu erfassen. Für Laufzeit gibt es 9 verschiedene Varianten, und sogar die vorraussichtliche Endzeit kann man benutzen. Aber die Startzeit von mehreren Songs/Elementen nicht?
Vielleicht gibt es ja einen bestimmten Grund dafür, auf den ich noch nicht gekommen bin. Oder vielleicht habe ich den Wald vor lauter Bäumen nicht gesehen.
PS: die Systemzeit mitzuschicken/anzugeben ist mir schon bekannt. Das funktioniert allerdings nur beim aktuell gestarteten Element. Bei mir geht es primär um den nächsten Song, hier eine Startzeit an eine API zu schicken. :=)
Nachtrag: dass das im Live Betrieb natürlich eine dynamische Playlist ist, ergibt ja sinn. Aber im Automationsbetrieb, wo die zeiten sehr warscheinlich genau berechnet werden können, fehlt mir so eine Funktion schon in gewisserweise.
Und da kann ich einfach ein + davor setzen? Und so die zukünftigen Songs hochzählen?
So z.B. %+R{Startzeit}, %++R{Startzeit}
EDIT: Das geht noch nicht.
Ich meine das wäre ein sehr einfacher Workaround was verrückt wäre.
Aber dennoch, als Feature Request gebe ich das trotzdem mal an Torben
Das backtiming wird ja sowieso fortlaufend errechnet, da denke ich ist das eigentlich kein riesen Hit sowas noch einzubauen. Und in der RestAPI ist das ja sowieso schon drin
Und da kann ich einfach ein + davor setzen? Und so die zukünftigen Songs hochzählen?
So z.B. %+R{Startzeit}, %++R{Startzeit}
EDIT: Das geht noch nicht.
Ich meine das wäre ein sehr einfacher Workaround was verrückt wäre.
Aber dennoch, als Feature Request gebe ich das trotzdem mal an Torben
Das backtiming wird ja sowieso fortlaufend errechnet, da denke ich ist das eigentlich kein riesen Hit sowas noch einzubauen. Und in der RestAPI ist das ja sowieso schon drin
Nein, das geht natürlich nicht. Dafür braucht es ein paar Zeilen mehr. Das mit den mehreren Titeln hatte ich verpaßt. Wieviele Elemente sollen denn auf die Reise gehen? (Du weißt schon, daß das die GVL nicht mag, so im voraus? Aber vielleicht ist es ja nur für einen Monitor.)
Jup, der Vertrag der GVL ist mir durchaus vertraut ^^ Aber danke für den Hinweis!
Also grundsätzlich will ich einen Song aus der Zukunft also “den nächsten Song” mitschicken. Kann man das Script ggf. Modular aufbauen? Ich habe zwar zwei linke Hände, aber Code kopieren und das Attributname anpassen sollte ich hinkriegen falls doch irgendwann mal nötig
Ah, okay: Das ist das Loggingergebnis, mit allen Klammern und Zeilenumbrüchen. Also, wenn ich so langsam von Begriff bin, kann’s auch ein wenig dauern mit dem Resultat. Sowas schüttle ich nicht eben aus dem Ärmel. Aber eigentlich sollte es funktionieren. Glaube ich. Vielleicht.
im prinzip gehts ja nur darum, ein Attribut für die Startzeit des nächsten Tracks im Logging zu haben. Wenn du da in die Richtung gehst, Startzeit+Duration=Endzeit & Endzeit = Startzeit Song 2
Diese Rechnerei brauchst du mir nicht in einem Script bauen, auch wenn ich dein Engagement sehr schätze! Das haben wir auch schon in einer selbstprogrammierten API hinbekommen. Und die RESTAPI von mAirList gibt das ja auch an.
Ich dachte, es gibt einen einfachen Workaround, der mir solche Attribute für ein einfaches eintragen im Logging.
Nachtrag, womit dieser Beitrag hier auch geschlossen werden kann:
%S{Format} Start time in FormatDateTime formatting (used for stop logging)
Ist bei den General Logging Variables dokumentiert. Aaaaaber, hier einfach ein + oder mehrere davon, geben mir die Startzeit der nächsten Elemente. Crazy. Das wurde so explizit nicht dokumentiert, dass das Möglich ist.
Aber damit brauchst du mir kein Script schreiben :=) Ich danke dir trotzdem für deine angebotene Hilfe!
geht noch nicht.
