nuts Posted June 6, 2009 Share Posted June 6, 2009 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 Quote Link to comment
SupaChris Posted June 6, 2009 Share Posted June 6, 2009 Vielleicht die Zeit im Unix-Format? http://de.wikipedia.org/wiki/Unixzeit Quote Link to comment
Lars_MQ Posted June 6, 2009 Share Posted June 6, 2009 was für eine riesige zahl? etwas wie: 39970,7552083333 ? mach mal einen cast zu nem datumtime wert (cdatetime oder ctime (?) ). Quote Link to comment
nuts Posted June 6, 2009 Author Share Posted June 6, 2009 (edited) 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 June 6, 2009 by nuts Quote Link to comment
Lars_MQ Posted June 6, 2009 Share Posted June 6, 2009 Keine unixzeit. das ist ein normaler Datetime wert, auch von VBA verstanden wird. Quote Link to comment
nuts Posted June 6, 2009 Author Share Posted June 6, 2009 (edited) 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 June 6, 2009 by nuts Quote Link to comment
Lars_MQ Posted June 6, 2009 Share Posted June 6, 2009 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... Quote Link to comment
nuts Posted June 6, 2009 Author Share Posted June 6, 2009 (edited) achso 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 June 6, 2009 by nuts Quote Link to comment
Lars_MQ Posted June 6, 2009 Share Posted June 6, 2009 Nein es wird 0.0 zurückgegeben. Eventuell interpretiert das VBScript etwas eigen... Quote Link to comment
Prinz Posted June 6, 2009 Share Posted June 6, 2009 Hallo, Nein es wird 0.0 zurückgegeben. Eventuell interpretiert das VBScript etwas eigen... 0 ist doch das Datum 31.12.1899 0:00, daher alles korrekt. ;-) Gruß Prinz Quote Link to comment
nuts Posted June 6, 2009 Author Share Posted June 6, 2009 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" Quote Link to comment
Prinz Posted June 6, 2009 Share Posted June 6, 2009 (edited) 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" 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 June 6, 2009 by Prinz Quote Link to comment
nuts Posted June 6, 2009 Author Share Posted June 6, 2009 (edited) 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. 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 June 6, 2009 by nuts Quote Link to comment
erwin Posted June 8, 2009 Share Posted June 8, 2009 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 Quote Link to comment
nuts Posted June 8, 2009 Author Share Posted June 8, 2009 (edited) 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 June 8, 2009 by nuts Quote Link to comment
dvbv Posted June 18, 2009 Share Posted June 18, 2009 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 Quote Link to comment
nuts Posted June 18, 2009 Author Share Posted June 18, 2009 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 Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.