Jump to content

NextRecordingTime - Verstehe den Rückgabewert nicht.


Recommended Posts

Hey,

 

ich bastle gerade ein Skript (mit autoit).

 

Dabei will ich abfragen wann die nächste Aufnahme ansteht.

 

$DVBViewer = ObjGet ("", "DVBViewerServer.DVBViewer")
If $DVBViewer = 0 Then
MsgBox (1, "", "Keine Verbindung zum DVBViewer möglich")
Exit
Else
Local $checktimer = $DVBViewer.TimerManager.NextRecordingTime()
MsgBox(1, "", $checktimer)
EndIf
exit

 

Das funktioniert auch, allerdings ist der Rückgabewert eine riesige Zahl, bei der ich keinen Bezug zum tatsächlich nächsten Timer herstellen kann.

Woran kann das liegen? Ist das bei euch auch so?

 

Gruß nuts

Link to comment

was für eine riesige zahl?

 

etwas wie: 39970,7552083333 ? mach mal einen cast zu nem datumtime wert (cdatetime oder ctime (?) ).

Link to comment

oha.

weiss das jemand genau? bevor ich mich an die umrechnung der unixzeit mache.

 

edit \ komischerweise bleibt die zahl auch bei geänderten timern immer gleich: 18991230000000

Edited by nuts
Link to comment

hehe der freizeitprogrammierer nuts weiss mit begriffen "cast zu nem datumtime wert (cdatetime oder ctime (?)" leider nichts anzufangen.

 

nach einem normalen Datetime wert sieht mir das nicht aus.

 

 

edit \ ahh mein rückgabewert ändert sich wirklich nicht!

hab jetzt verschiedene früher gelegene timer hinzugefügt - oder missverstehe ich die funktion?

es soll doch datum und uhrzeit des nächsten timers angezeigt werden?

 

edit2 \ ich verwende den recordingservice für meine aufnahmen (server/client konfig.) - nur falls das wichtig sein sollte!

 

edit 3\ habs jetzt nochmal ohne recordingservice und mit 0 timern versucht.

ergebnis: 18991230000000

sehr seltsam - funktionierts bei sonst wem?

Edited by nuts
Link to comment

Die recording service timer werden dabei nicht berücksichtigt, nur die lokalen timer. Das muss ich erstmal prüfen, ob ich das so einfach ändern kann...

Link to comment

achso :D

und 18991230000000 wird bei 0 timern zurückgegeben (wenn ich mir die anmerkung erlauben dürfte: das ist entweder seltsam/falsch im com interface dokumentiert oder so nicht gewollt).

 

also ich bin dann eigentlich schon zufrieden.

mein skript unterscheidet sowieso zwischen einzelplatz und server/client konfig.

Edited by nuts
Link to comment

Hallo,

 

Nein es wird 0.0 zurückgegeben. :D Eventuell interpretiert das VBScript etwas eigen...

 

0 ist doch das Datum 31.12.1899 0:00, daher alles korrekt. ;-)

 

Gruß

Prinz

Link to comment

okay dann ziehe ich meine anmerkung wieder zurück ;)

 

also bei mir wird definitiv 18991230000000 bei 0 timern zurückgegeben.

 

wie kommt man von 0.0 auf 18991230000000? ist schon seltsam, konnte jetzt auch nichts ergoogeln.

 

naja macht ja nichts, dann prüfe ich eben auf "18991230000000" :D

Link to comment
okay dann ziehe ich meine anmerkung wieder zurück ;)

 

also bei mir wird definitiv 18991230000000 bei 0 timern zurückgegeben.

 

wie kommt man von 0.0 auf 18991230000000? ist schon seltsam, konnte jetzt auch nichts ergoogeln.

 

naja macht ja nichts, dann prüfe ich eben auf "18991230000000" :D

 

Dieser magische Wert findet man auch häufig in der DVBViewer Inf-Datei zur Sendung, wenn im EPG wohl der Datumswert 0 eigetragen ist. Beispiel:

LastShown=30.12.1899

 

Diverse Programmiersprachen arbeiten bei einer Float-Darstellung intern mit dem 30.12.1899 als Bezugspunkt. Soviel ich weiß ist dabei vor dem Dezimalpunkt die Anzahl der Tage und dahinter der Dezimalbruch des Tages. Warum ausgerechnet der 30.12. und nicht der 1.1.1900 wissen die Götter. Ich glaube es gibt auch welche die mit dem 1.1.1900 arbeiten. Oder ist der bestimmende Faktor Windows selber?

 

Gruß

Prinz

Edited by Prinz
Link to comment

hehe danke Prinz für die erläuterung.

dann ist ja alles klar - ganz schon verwirrend wenn man das nicht weiss und auch noch der recording service mit reinspielt!

 

wahrscheinlich würde ein in delphi geschriebenes tool den rückgabewert automatisch zu 0.0 berichtigen?

 

mein autoit tool erhält aber nunmal 18991230000000 und wandelt nichts zurück.

 

p.s. hab noch etwas gegoggelt

TDatetime 0 = 30.12.1899 00:00:00 = Delphi Urknall

 

ich ziehe meine anmerkung glaube ich doch nicht zurück. :D

 

soweit ich das verstanden habe wäre es sinnvoll den Rückgabewert in eine verständlichere form umzuwandeln (DatetoStr oder sowas)

mal sehn was der delphi großmeister dazu sagt. ;)

Edited by nuts
Link to comment
TDatetime 0 = 30.12.1899 00:00:00 = Delphi Urknall

 

// Umwandlung von DVBViewer DateTime-Datentypen (=Delphi) nach time_t
/*
The TDateTime type holds a date and time value.

It is stored as a Double variable, with the date as the integral part,
and time as fractional part.
The date is stored as the number of days since 30 Dec 1899.
Quite why it is not 31 Dec is not clear. 01 Jan 1900 has a days value of 2.

Because TDateTime is actually a double, you can perform calculations on it as if it were a number.
This is useful for calculations such as the difference between two dates.
*/
inline time_t TDateTime2time_t( double DateTime )
{
 const int BASEDELTA	= 25569;		// Days between TDateTime basis (12/30/1899) and time_t basis (1/1/1970)
 const int SECS_PER_DAY = 24 * 60 * 60; // Seconds per day

 // the ( time_t )-cast separates the integer part; fractions of seconds are not returned
 return ( time_t ) ( ( DateTime - BASEDELTA ) * SECS_PER_DAY );
}

 

Ist zwar aus meinem C-Header aber vielleicht kannst Du damit was anfangen. time_t ist in C die Anzahl der verflossenen Sekunden ab 01.01.1970.

 

mfg erwin

Link to comment

mhm die syntax von c ist mir wenig vertraut.

eigentlich ist mein problem auch gelöst.

 

ich möchte prüfen ob in den nächsten 15 min eine aufnahme ansteht (wie der DVBViewer das auch macht).

erster schritt ist dabei ob überhaupt ein timer eingetragen ist, denn dann kann ich mir weitere abfragen sparen.

 

für den rückgabewert "kein timer" müsste man, meiner meinung nach, gar nicht mit den dateformaten rumfummeln.

Edited by nuts
Link to comment
  • 2 weeks later...

Hi,

 

also wenn man sich 18991230000000 genau anschaut, dann sieht man, dass autoit (oder was Du da verwendest) so wohl den 30.12.1899 00:00:00 Uhr darstellt: yyyymmddhhmmss. "Jetzt" wäre dann wohl 20090618202600.

 

Das, was Delphi zurückgibt, ist die Standard-Datetime-Repräsentation unter Windows als Fließkommazahl und wurde hier auch schon richtig erklärt: die Stellen vor dem Komma sind die Tage seit dem 30.12.1899, nach dem Komma der Bruchteil des Tages: 18 Uhr wäre z.B. 0,75.

 

Zum ersten Mal wurde dieses Format von Lotus 1-2-3 verwendet (oder war es Multiplan?) und daher stammt auch der Fehler, dass der 1. Januar 1900 Tag 2 ist; eigentlich sollte das Tag 1 sein, aber die haben sich wg. eines Schaltjahres oder so verrechnet...

 

Schöne Grüße

Link to comment

ja habs schon verstanden.

 

für den rückgabewert "kein timer" müsste man, meiner meinung nach, gar nicht mit den dateformaten rumfummeln.

 

bleibt dieser punkt - ist jetzt aber eigentlich nicht der rede wert :)

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...