Automatisches Nachladen der nächsten Playlist

Deutsch / German Feature-Requests
1

Ich bin mir nicht ganz sicher, ob ich diesen Vorschlag an anderer Stelle bereits geäußert habe, möchte ihn aber dennoch ausführen bzw. wiederholen.

Folgender Fall:
Die Playlisten werden (momentan noch mit der “echten” Sendeablaufsteuerung, also dem ganz normalen Ausspielprogramm) erstellt und abgespeichert. Die Dateinamen haben dabei folgendes Format:
ttmmhhmm.MLP
Beispiel: 21091314.MLP steht für 21.09. von 13-14 Uhr. Jede Playlist faßt also eine Sendestunde. Die Playlist-Dateien werden in einem eigens für sie angelegten Unterverzeichnis PLÄNE abgelegt. Nun soll mAirList bei Programmstart das aktuelle Datum und die aktuelle Zeit auslesen und die entsprechende Liste automatisch öffnen. Ist die Stunde abgelaufen, wird um xx.00.00 der neuen Stunde automatisch die neue Liste nachgeladen, die alte entfernt. Eventuell noch vorhandene Titel der alten Liste entfallen.
Für den momentan laufenden Titel stelle ich mir zwei Modi vor:

  1. Der Titel verbleibt im Player; er wird normal ausgespielt, bis er entweder von selber endet oder von Hand (Pult) beendet wird.
  2. Sofern ein Event vorgesehen ist, welches immer am Ende einer Sendestunde auftritt (Nachrichten-Opener), läuft das Event zur vorgesehenen Zeit und blendet alle noch laufenden Titel aus. Damit wäre die Playlist beendet (egal, ob sich noch Titel in der Liste befinden oder nicht), und die nächste wird geladen.

Ist keine Folgeliste vorhanden, wird auch keine nachgeladen. Im Falle von Modus 2 würde dann nach dem Event nichts mehr kommen; die alte Liste aber in jedem Fall rausgeworfen.

Ob Modus 1 oder 2 gilt, kann beispielsweise beim Erstellen der Playlist festgelegt werden (moderierte Sendung im Tagesprogramm? Dann Event für den Nachrichten-Opener. Unmoderierte Sendung im Nachtprogramm? Dann einfach durchlaufen ohne Event).

Steht ein Tageswechsel an (ttmm2324 -> uumm0001; wobei uu = tt+1 [Monatswechsel/Schaltjahr beachten!]), wird natürlich die des Folgetages geladen.

Zusätzlich wäre es schön, wenn der HourCountdown unterschiedliche Werte anzeigen würde. Ist für die laufende Playlist ein Event (AOT = “Automation on time”, also ein wie oben beschrieben automatisierter Nachrichten-Opener) vorgesehen, so zählt der HourCountdown nicht bis zur nächsten vollen Stunde, sondern bis zum Einsatz des Events. Ist für die laufende Playlist kein AOT vorgesehen, so zählt der HourCountdown tatsächlich die Restzeit bis zur nächsten vollen Stunde. Die unterschiedliche Darstellung könnte beispielsweise mit unterschiedlichen Farben (z. B. rot für “AOT vorhanden”, blau oder grün für “kein AOT vorhanden”) oder mit Präfix (z. B. “AOT: xx.xx” bzw. nur “xx.xx”) realisiert werden.

Frage: ist eine solche Implementierung möglich? Sie würde insbesondere im Hinblick auf eine feststehende Tagesstruktur Sinn machen und das manuelle Nachladen der Playlisten umgehen. Ich würde eine solche Funktion sehr schätzen.

2

Ich habe das jetzt noch nicht hundertprozentig durchdenken könne, allerdings habe ich auf die Schnelle ein Feature eingebaut, das sehr helfen könnte:

Man kann nun auch die gängigen Logging-Variablen %Y, %M, %D, %h, %h und %s in Dateinamen verwenden, wenn man neue Aktionen für ein Event definiert. Dazu gibt es im entsprechenden Dialog einen kleinen Haken.

Außerdem ist es möglich, eine “Zeitverschiebung” anzugeben, die auf die aktuelle Uhrzeit gerechnet wird, bevor die Variablen ersetzt werden.

Beispiel: Du willst jeweils um fünf Minuten vor der vollen Stunde die nächste Playlist laden. Die Playlisten liegen im Verzeichnis “c:\pläne” und haben das Format “YYYYMMDDHH.mlp”, also z.B. “2007092219.mlp” für die heutige 19h-Stunde.

Du gibst also als Dateinamen an: c:\pläne%Y%M%D%h.mlp

Außerdem setzt du den oben erwähnten Haken.

Zuletzt gibst du noch einen Zeit-Offset von 300 Sekunden = 5 Minuten an. Wenn also das Event um :55:00 gestartet wird, wird als Zeit fünf Minuten später = :00:00 angenommen.

Ich habe mal einen Snapshot hochgeladen, bei dem das bereits eingebaut ist. URL (wie üblich, am besten mal bookmarken): http://www.mairlist.com/download/mAirList/v2.1/snapshot/

Wie man den Rest dann hinbekommt, darüber denke ich später nach. Jetzt gibt’s erstmal Pizza :wink:

Torben

3

Pizzza gab’s bei mir auch, allerdings zum Frühstück. Also so gegen 3.

Ich muß mir diese Testversion nachher mal genauer ansehen, aber vorab noch ein paar Sätze dazu:

Das Dateiformat würde ich wirklich (wie oben beschrieben) auf acht Stellen reduzieren. Die Jahreszahl genügt zweistellig, denn 07 genügt, um das Jahr 2007 zu identifizieren. Playlisten mit 97 dürften nicht mehr vorkommen, und wenn, sind sie ebenfalls als Playlisten des letzten Jahrhunderts erkennbar sein. Zudem rege ich an, die Uhrzeit mit vier Stellen anzugeben, nämlich eine Von-bis-Zeit: 1819 = von 18 Uhr bis 19, bzw. je nach Sendeschema auch 1821 (macht natürlich nur Sinn, wenn innerhalb dieser Playlist kein Event auftritt, welches die Playlist unterbricht oder gar vorzeitig beendet, wie es etwa bei dem von mir beschriebenen Nachrichten-Opener der Fall ist).

Die Sache mit dem Zeit-Offset finde ich sehr verwirrend. Nicht nur, daß man dabei schnell mal Fehler macht. Es hört sich auch etwas umständlich an. Hinzu kommen so Sachen wie beispielsweise ein Werbeblock. Den habe ich zwar nicht, aber nehmen wir mal an, es gibt jede Stunde vor den Nachrichten einen Werbeblock, der immer unterschiedlich lang ist. So verschiebt sich das Backtiming auf die Dauer des Werbeblocks plus die Dauer des Nachrichten-Openers. Das jetzt im Detail auszuführen, würde hier zu weit führen, das ist auch erstmal wohl nicht so wichtig. Belassen wir es einfach bei dem Nachrichten-Opener, der als Event (AOT) kommt oder eben nicht kommt - das wiederum ließe sich beim Erstellen der Playlisten angeben. WENN die geplante Stunde einen Opener hat, muß die Backtiming-Anzeige HourCountdown bis zum Einsetzen des Events zählen. Wenn die geplante Stunde KEINEN Opener zur vollen Stunde hat (z. B. Nachtprogramm, Weihnachten, Silvester oder andere Sendung ohne Nachrichten), zählt der HourCountdown tatsächlich bis zur nächsten vollen Stunde. Die nächste Playlist soll erst dann nachgeladen werden, wenn das Event-Element vollständig abgelaufen ist, in der Praxis also erst dann, wenn die Nachrichten laufen. Schön (aber nicht zwingend erforderlich) wäre dann ein Hinweis z. B. in Form einer kurzen Texteinblendung (kein Dialogfenster) auf der Playlist, aus dem hervorgeht, daß die Folgeliste gerade geladen wird.

Wichtig ist nur, daß automatisch immer die nächste gültige Playlist nachgeladen wird. Dies zu realisieren, erscheint mir nicht weiter schwer.

23091415 läuft jetzt gerade. Um 15 Uhr ist sie beendet (hat ein AOT), also wird die nächste geladen: 15+1=16: 23091519 (die läuft bis 19 Uhr ohne AOT durch, d. h., die nächste wird erst um 19 Uhr geladen). Die letzte Liste ist meistens eine, die auf 24 endet. Danach kommt der nächste Tag:
24090001. Welcher Monat wieviele Tage hat, läßt sich ohne weiteres hart einprogrammieren, so daß es auch kein Problem sein dürfte, bei einem 31.09. in den nächsten Monat oder gar ins nächste Jahr zu wechseln.

4

Prinzipiell ist alles möglich, aber je komplizierter die Anforderungen sind, desto geringer ist die Chance, dass sich das sinnvoll (!) in das Programm integrieren lässt. Natürlich kann ich eine bestimmte Anzahl konfigurierbarer Optionen schaffen, aber vielleicht musst du der Software auch etwas entgegenkommen.

Beispiel: Dein Vorschlag, die Zeit vierstellig anzugeben. Sowas wie “1314” ist für den Menschen vielleicht leicht zu lesen (“aha, die Stunde von 13 bis 14 Uhr”). Aber wie wollte man sowas mit Variablen realisieren? %h gibt die aktuelle Stunde zurück. Dann bräuchte man ja noch eine weitere Variable für “aktuelle Stunde + 1”. Und vielleicht noch eine für “aktuelle Stunde + 3”, wenn du plötzlich dreistündige Playlists hast. Also: Lieber nur die Anfangsstunde in den Dateinamen schreiben; wie viele Stunden die Playlist enhalten soll, legst du dann einfach dadurch fest, für wann das nächste Event eingeplant wird.

Natürlich gibt es auch die Möglichkeit, alles haarklein genauso zu machen, wie man es sich vorstellt. Das geht dann aber nur per Script und nicht mehr per GUI.

Die meisten Leute haben ihre Playlisten so organisiert, dass es genau eine Playlist pro Stunde gibt, die ähnlich wie oben beschrieben benannt ist. Diese kann mit den erweiterten Events jetzt automatisch geladen werden, ohne dass man ein Script braucht. Durch den Zeitoffset ist es möglich, das Nachladen auch schon einige Minuten vor der vollen Stunde durchzuführen. Der Offset wird dann einfach auf die aktuelle Zeit draufgerechnet, und das Ergebnis als Basis für die Variablen-Ersetzung genommen. Das hat zwei Vorteile: Man braucht keine zusätzlichen Variablen für z.B. “Tag der nächste Stunde”, und mAirList muss sich keine Gedanken darüber machen, welcher Monat jetzt wie viele Tage hat. Es wird einfach die errechnete Zeit genommen und in die Datums-Formatierungen geworfen. Fertig.

Die Anfrage, ob der Stunden-Countdown nicht alternativ auch bis zum nächsten Fixzeit-Element zählen kann, gab es schonmal. Vielleicht bau ich das mal ein.

5
Dein Vorschlag, die Zeit vierstellig anzugeben. Sowas wie "1314" ist für den Menschen vielleicht leicht zu lesen ("aha, die Stunde von 13 bis 14 Uhr"). Aber wie wollte man sowas mit Variablen realisieren?

Die Programmierung im achtstelligen Format, wie von mir vorgeschlagen, ist nicht wirklich schwer. Zwar beherrsche ich kein Delphi, wohl aber das gute alte QuickBasic und habe soeben folgendes gebastelt:

[code]dateiname$ = “24091314”

tag% = VAL(LEFT$(dateiname$, 2)) 'Die ersten zwei Stellen von dateiname$
monat% = VAL(MID$(dateiname$, 3, 2)) 'Die dritte Stelle von links mit der Länge zwei Stellen
zeitvon% = VAL(MID$(dateiname$, 5, 2)) 'Die fünfte Stelle von links mit der Länge zwei Stellen
zeitbis% = VAL(RIGHT$(dateiname$, 2)) 'Fange rechts an, Länge zwei Stellen

PRINT tag%
PRINT monat%
PRINT zeitvon%
PRINT zeitbis%
[/code]

Das hat mich drei Minuten gekostet. Variablen, die mit einem $ enden, sind String-Varibalen. Jene mit % sind Integer-Variablen. VAL ändert Strings in Integer. Ich bin mir sicher, daß sich eine solche Operation auch mit anderen Programmiersprachen erstellen läßt.

Aber das nur nebenbei. Ich halte es einfach für wichtig, daß solche Sachen auch für den Menschen leicht zu lesen und zu durchschauen sind, denn für die ist das alles ja schließlich gemacht. Es nützt mir nichts, wenn der Rechner damit umgehen kann, denn ich muß es ja schließlich auch. Daher bin ich der Meinung, daß sich der Rechner und die Programme dem Menschen anpassen sollten und nicht umgekehrt.

Natürlich gibt es auch die Möglichkeit, alles haarklein genauso zu machen, wie man es sich vorstellt. Das geht dann aber nur per Script und nicht mehr per GUI.

Wie das geht, ist für mich als Mensch (!) nicht wichtig. Wichtig ist nur, daß es geht. Im übrigen zähle auch ich zu denjenigen, die nur eine Stunde in eine Playlist packen würden. Es stellt sich allerdings dann die Frage, wie das Nachladen aussehen soll, wenn beispielsweise eine Sendung ohne Nachrichten-Opener oder eine automatisierte Sendung durchläuft. Da wäre es weitaus einfacher, eine Playlist von der Länge x Stunden zu basteln, die dann auch solange durchläuft, bis die Sendung mit der Länge x durchgelaufen ist. Anderenfalls stellt sich die Frage: was machen, wenn der letzte Titel der alten Liste läuft, dieser über die Grenze von xx.00.00 kommt und dann die neue Liste geladen wird? Soll der alte Titel auslaufen, die rechstlichen Titel der alten Liste verworfen werden? Sollten die restlichen Titel der alten Liste weiterlaufen? Soll es eine harte Unterbrechung im gerade laufenden Titel geben?
Diese Fragen zu beantworten sind wohl Ermessenssache und schreien geradezu nach Einstellmöglichkeiten. Diese zu programmieren, halte ich für aufwendiger als das Auslesen eines achstelligen Dateinamens. Von daher wiederhole ich meinen Vorschlag, auch Playlisten von mehr als einer Stunde Dauer zuzulassen, die gerade bei unmoderierten Sendestrecken oder bei Sendestrecken ohne Event durchlaufen: “24091317”.

Die Sache mit dem Offset könnte ebenfalls in den Playlist-Dateien als Zeile enthalten sein:

Offset = 0 Event = 0
Hier ist klar: es gibt kein Event und auch keine Zeitverschiebung im HourCountdown. Der HourCountdown zählt ganz normal bis zur nächsten vollen Stunde.

Demgegenüber steht beispielsweise so etwas:

Offset = 5 Event = \NACHRI.MLE
Hier ist klar: es gibt ein Event (\NACHRI.MLE) und eine Zeitverschiebung um fünf Sekunden. Das Event NACHRI.MLE wird also fünf Sekunden vor der vollen Stunde (xx.59.55) aufgerufen. Sobald dieses Element durchgelaufen ist, gilt die Playlist als durchgelaufen, alle Player werden geleert, und es wird die jeweils nächste Liste (zeitbis% = zeitbis% + 1) nachgeladen.

Das klingt komplizierter als es ist. Vielleicht führt das an dieser Stelle auch zu weit, vielleicht ist das eher was fürs Telefon (oder besser: für eine Demonstration, aber das wird sich wohl vorerst nicht ergeben, wenn ich das alles richtig einschätze).
Ferner sei erwähnt, daß ich die von Dir erwähnte Option mit dem Haken und der Offset-Einstell-Möglichkeit in dem Snapshot nicht gefunden habe.

6

Ich glaube, wir reden in mindestens zwei Punkten aneinander vorbei :wink:

  1. Dass man in einem eigenen Programm oder Script mit Variablen arbeiten kann, steht außer Frage. Es geht hier auch nicht um das Auslesen von Dateinamen, sondern um das Erzeugen: Man gibt in der mAirList-GUI nur das Schema des Dateinamens, und mAirList ersetzt automatisch bestimmte Platzhalter (= Variablen) durch die Werte der aktuellen Uhrzeit. Gibst du also als Dateinamen “c:\pläne\montag-%h.mlp” an, dann macht mAirList daraus - angenommen, es ist gerade 12:43 uhr - “c:\pläne\montag-12.mlp”.

Diese Möglichkeit und solche Variablen existieren jetzt für die Komponenten der aktuellen Uhrzeit (siehe oben). Nicht aber für Uhrzeiten in der Zukunft oder Vergangenheit. Das ist unpraktikabel, sowas zusätzlich einzuführen.

  1. Der Time-Offset hat mit dem Hour-Countdown und dem Aufrufzeitpunkt der Events nichts zu tun. Es geht hier nur darum, dass man mAirList anweist, die angenommene aktuelle Uhrzeit um x Sekunden nach vorne oder nach hinten zu verschieben, während die Variablen ausgewertet und der Dateiname zusammengesetzt werden.

Beispiel: Es ist 11:55:00, du gibst als Offset 300 Sekunden an: mAirList ersetzt “%h:%m:%s” durch “12:00:00”. Ohne Offset wäre es “11:55:00”. Zweck: siehe unten.

Die Haken findest du übrigens, wenn du im Event Scheduler ein neues Event anlegst und dort eine “Playlist laden”-Aktion o.ä. hinzufügst.

Das Nachladen wird über genau diesen Event-Scheduler realisiert. Dort gibt es ein stündliches Event mit der Aktion “Playlist laden”, und man verwendet eben diese Platzhalter, um automatisch den passenden Dateinamen ermitteln zu lassen.

Einige Leute bevorzugen, das Laden schon einige Minuten vor der vollen Stunde zu machen, und dann mit der Funktion “Playlist anhängen” statt “Playlist laden”. Dann verwendet man den Time-Offset, damit schon der Name der 12-Uhr-Playlist richtig ermittelt werden kann, obwohl es vielleicht noch 11:55 ist. Damit die Playlist dann pünktlich zur vollen Stunde gestartet wird, kann man das erste Element mit einer Fix-Zeit versehen. Oder alternativ vor der Playlist noch eine zweite Playlist einfügen, die genau ein Dummy-Element mit der gewünschen Fix-Zeit enthält.

Wenn du längere Playlisten willst, legst du halt kein stündliches Event an, sondern eins, was vielleicht nur alle drei Stunden läuft, aber dafür Playlisten lädt, die entsprechend länger sind.

7

So, ich habe das gerade mal ausprobiert. Abgesehen davon, daß einige Dialogfelder noch in Englisch sind und ich die Bedienung für äußerst kompliziert halte, scheint das zu funktionieren. Zumindest mit festen Dateinamen.

Der HourCountdown zeigt nach wie vor den Countdown bis xx.00.00 an, was natürlich wenig hilfreich ist, wenn der Opener (das Event) bereits um xx.59.55 einsetzt. Fürs Backtiming sollte der HourCountdown die Länge des Events schon mitberücksichtigen - entweder automatisch oder per Hand. Die Sache mit dem Offset scheint dafür ja uninteressant zu sein.

Ferner rege ich eine Zeile in der Playlist an, die das Event anzeigt. Diese Zeile darf gerne eine markante Farbe haben (schwarz oder grau). Sie rutscht immer an die Position, an der das Event auch tatsächlich kommen würde. Das heißt: die Titel der aktuellen Playlist, die HINTER dieser Zeile stehen, werden wohl nicht mehr ausgespielt. Als Startzeit für das Event steht natürlich die jeweilige Zeit, z. B. 13.59.55
Eine solche Zeile ist momentan nicht da, würde jedoch das Backtiming und die Übersichtlichkeit erleichtern, weil man auf den ersten Blick sieht, daß da etwas kommt und alles, was danach steht, sowieso nicht mehr läuft.

Desweiteren blicke ich das mit den Variablen in den Dateinamen nicht. Könntest Du mir bitte ein Beispiel dafür geben, wie ich den Dateinamen für das Laden einer Folgeliste im Event-Scheduler angeben muß?
In diesem Zusammenhang möchte ich noch einmal erwähnen, daß es durchaus sinnvoll sein kann, daß mAirList bei jedem Programmstart automatisch die für das jeweils aktuelle Datum und die die jeweils aktuelle Uhrzeit gültige Playlist sucht und lädt.

8

Der Snapshot ist immer auf Englisch. Die Sprachdatei wird inzwischen immer in die .exe eingebaut, allerdings nur, wenn ich einen “echten” Release hochlade (macht das gleiche Script, das auch die setup.exe und die zip-Datei erzeugt). Wenn du noch von einer früheren Version ein “locale”-Verzeichnis hast, siehst du immerhin einen Teil der Meldungen auf deutsch. Dieses Verzeichnis kannst du aber auch löschen, für die neueren “echten” Versionen wird es nicht mehr benötigt.

Zum Hour-Countdown: Am besten versiehst du deinen Nachrichten-Opener mit einer Fixzeit (im Eigenschaften-Dialog). Ich baue den Hour-Countdown dann so um, dass er alternativ auch die Zeit bis zum nächsten Fix-Element anzeigt, sofern ein solches existiert.

Der Event-Scheduler ist unabhängig von den Elementen in der Playlist und deren Fix-Zeiten. Das Laden der nächsten Playlist kann zu derselben Uhrzeit geschehen, zu der auch der Opener kommt, muss aber nicht. Früher oder später ist vielleicht sogar besser, damit nicht zu viele Dinge gleichzeitig passieren, die die Performance beeinträchtigen könnten.

Die Idee, die Events in der Playlist einzublenden, finde ich ganz nett. Mal schauen, vielleicht baue ich das mal ein :wink: Ansonsten siehst du in der Playlist-Toolbar das Feld mit dem E daneben, da steht auch die Zeit des nächsten Events drin.

Und wegen den Variablen im Dateinamen:

Zunächst musst du dich davon trennen, mehr als das Datum und/oder die Uhrzeit der Startzeit der Playlist im Dateinamen stehen zu haben. Also raus mit der End-Stunde. Dann gibst zu zum Beispiel als Dateinamen an “c:\pläne%D%M%h.mlp”, und mAirList macht daraus dann automatisch “240913.mlp”.

9

Der Nachrichten-Opener hat immer eine Fixzeit (xx.59.55, damit das Ausblenden noch zu hören ist). Würde der HourCountdown auf dieses Event angesetzt, würde mich das sehr freuen. Zudem rege ich an, den HourCountdown erst ab einem bestimmten Wert (z. B. bei 10 oder 15 Minuten Restzeit) sichtbar zu machen und bitte, das Minus zu entfernen. Es genügt eine Anzeige von z. B. 14.34 (noch 14 Minuten und 37 Sekunden bis zum Einsetzen des Events) oder 26 (noch 26 Sekunden bis zum Einsetzen des Events) oder 7 (noch 7…).

Das Laden der nächsten Playlist kann ein weiteres Element im Event sein. So habe ich es eben gerade zu Testzwecken auch gemacht und halte es ebenso wie Du für sinnvoll. Zudem wäre ein Script, welches die momentane Playlist leert, hilfreich. Den News-Break stelle ich mir dann z. B. folgendermaßen vor:
xx.59.55: Nachrichten-Opener startet
xx.59.58: Jetzige Playlist und alle Player werden komplett geleert (kann man hierzu ein Script schreiben? Wie muß das aussehen?)
yy.00.05: Neue Playlist wird nachgeladen, bereit zum Abfahren

Das Feld mit dem E in der Toolbar kenne ich bereits, nur wäre es wirklich übersichtlicher, einen Grenzbalken mit dem Event in die Playlist einzubauen. Hier mal zwei Beispiele:
Beispiel grau
Beispiel schwarz
In Grau gefällt’s mir besser, aber das könnte man ja auch einstellen.

Das mit den Dateinamen klappt leider nicht. Ich habe es so gemacht, aber mAirList nimmt die Variablen als String an und meldet, daß die Datei %D%M%h.MLP nicht gefunden wurde, obwohl es Dateien mit den Namen
240914.MLP
240915.MLP
240916.MLP
240917.MLP
240918.MLP
240919.MLP
240920.MLP
gibt.

EDIT: Irrtum von mir, ich hatte dieses Häkchen mit den Variablen nicht gesetzt - sorry, mein Fehler.
Aaaaber: was noch sinnvoll wäre, das wäre eben diese AutoLoad-Funktion, die bei Programmstart die jeweils gültige Playlist für die Ist-Zeit heraussucht und automatisch lädt. Und eben, wie gesagt, ein Script, das alles aus der Playlist und den Playern löscht.
Zudem ist mir noch ein Schönheitsfehler aufgefallen: beim Nachladen einer neuen Liste erscheint oben in der Titelleiste immernoch die alte Playlist mit dem Zusatz “(geändert)”. Läßt sich das so umstellen, daß oben die jeweils aktuelle Playlist im Titel erscheint?

10
...und bitte, das Minus zu entfernen.
Das dann aber bitte konfigurierbar. Ich mag das Minus!
11

Daß ein Countdown keine positiven Werte anzeigt, liegt in der Natur der Sache.

12

Wäre trotzdem nett, wenn du es mir überlassen könntest, wie ein Countdown für mich auszusehen hat.

13

Ebenso :wink:

14
Das dann aber bitte konfigurierbar.
Sag ich ja schon die ganze Zeit! ;-)
15

Sagte ich an anderer Stelle bereits. Von daher verstehe ich Deine Aufregung nicht.

16

Zitat?

17

Och nö, nicht auf dem Niveau. Ich habe keine Lust, meine ganzen letzten Postings alle zu durchforsten, nur, damit einer hier nicht schmollt. Würdest Du Dir die Mühe machen, zu lesen (und zu verstehen), was ich bisher hier geschrieben habe, würdest Du feststellen, daß ich ein großer Freund von Einstellmöglichkeiten bin und mich immer wieder gegen hart einprogrammierte Darstellungsformen geäußert habe. Im übrigen sei erwähnt, daß es in diesem Thema um mehr geht als um reine Kosmetik. Die Tatsache, daß Du Dich hier - Verzeihung - einmischst, um lauthals nach einem Strich (!) zu schreien, zeigt, daß Dir die Problematik nicht bewußt geworden ist.
Daher betrachte ich die Diskussion mit Dir an dieser Stelle für beendet und bitte um Verständnis, daß ich mich nun weiterhin dem Thema widme. Nicht böse gemeint, nur ehrlich.

18
Die Tatsache, daß Du Dich hier - Verzeihung - einmischst, um lauthals nach einem Strich (!) zu schreien, zeigt, daß Dir die Problematik nicht bewußt geworden ist.
Köstlich! Immerhin war es dir dieser Strich ja auch wert, nach seiner Abschaffung zu schreien. Und damit ist das Thema auch für mich erledigt.
19

Wie ich schon sagte: Du hast die Problematik nicht verstanden. Aber was rede ich… :wink:

20

Jo, jetzt hast du’s mir gegeben. Du bist der Größte! :wink: Gute Nacht!