Darum geht es ja nicht.
Es geht ja um ein Datum, das anzeigt, auf welchen Feed-Update-Status man sich befindet.
Beiträge von Sven H
-
-
Ok, dann geht das wohl technisch nicht.
Oder gibt es auf der Box ein Datum, welchen Feed-Stand man drauf hat?Ein Datum, wann man das letzte Feed-Update gemacht hat, wäre ja nicht hilfreich. Da würde dann ja bei jedem was anderes stehen
-
Ich bin gerade nicht aktuell, da mir vom Feed 46 Updates angeboten werden, hab aber definitiv nach dem 20.03. ein Update gemacht.
Wo kann ich denn erkennen, auf welchem commit-Stand vom Datum her ich jetzt persönlich bin.
-
Weiß die Box denn, wann sie das letzte Update für obigen Link gemacht hat?
Ich kenn mich da mit den internen Abläufen nicht so aus.
Könnte man da der Box ein passendes Datum entlocken?
-
Dann wüsste man zumindest, dass man tatsächlich das letzte Update vom obigen Link hat.
Dann gäbe es auch diese Diskussion nichtSo könnte man ja meinen, mir fehlen alles Updates aus obigen Link nach dem E2-Update vor 7 Tagen.
-
Um aber den Updatestand zweier Boxen über den About-Screen zu vergleichen, wäre es doch hilfreich, wenn irgendwo ein Datum stehen würde, welchen letzten Stand man z.B. von hier hat:
http://git.opendreambox.org/?p=opendreambox.git;a=shortlogDas Datum des letzten E2-Updates hilft da nicht wirklich.
Ich glaube, das ist der Gedanke von alpha.Erzeugt eigentlich jedes commit im genannten Link automatisch ein Feedupdate für die Box oder wird das irgendwann manuell angestoßen?
-
Hier nun die 0.3.3
Ich hab das nicht gerade ausführlich gestestet aber ich denke das sollte passen so.Danke
Hinweis für GP3-Nutzer:
Aktuell zeigt sich auch mit der neuen von Reichi angepassten Version des pzyP4T-Plugins teilweise noch das Refresh-Problem.
Das liegt aber noch am GP3 und ist kein "Fehler" im pzyP4T-Plugin.
Wenn man testweise die neue "fillTimerList()" aus der TimerEdit.py direkt ins pzyP4T-Plugin reinnimmt, klappt das Refreshen auch vollständig mit GP3.Dank Reichi geht das jetzt sogar ganz ohne invalidate()
(wobei mir immer noch unklar ist, warum in meinem Code nur ein doppeltes invalidate() geholfen hat ) -
@zombi
Da gibt es einen passenden Thread im ihad (refresh problem bei Timerlist nach Aufräumen).
Da hatte ich schon mal was dazu geschriebenhttp://www.i-have-a-dreambox.c…hread.php?threadid=197054
Da ist wohl die eigene fillTimerList-Funktion nicht mehr kompatibel zum Rest der neuen TimerEdit.py
-
Das ist eine Funktion aus der aktualisierten TimerEdit.py.
Das GP ersetzt die offensichtlich durch eine eigene Funktion, da die Funktion aus der TimerEdit.py mit GP nicht zur Anwendung kommt.
-
Wenn du GP hast, dann kommt von dort die replace-fillTimerList zum Tragen. Da wird dann die neue von DM gar nicht ausgeführt.
Daher ist man dafür als GP-User ein „schlechter“ Tester.
-
Alte Testtimer kannst du auch so erstellen:
- neuen Timer hinzufügen
- Datum des Timers mit Taste Links auf gestern stellen
- Timer speichernDavon dann 3 Timer erstellen.
(die Refreshprobleme treten meist nur bei mehr als 2 alten Timern auf)
Dann in der Timerliste „Aufräumen“ -
Ich hab gestern nochmal etwas im pzyP4T getestet.
Unter bestimmten Umständen wird die Timerlist trotz eines invalidate() nicht aktualisiert.
Es bleibt ein Eintrag in der Liste, der noch angezeigt wird, obwohl es ihn gar nicht gibt.
(drei alte Timer am Ende, Cursor auf letzten Eintrag, dann aufräumen)
Dabei bleibt der vorletzte Eintrag in der Liste stehen. Der letzte und der davor verschwinden.
Der Cursor rutscht dann auf den letzten wartenden Timer.Jetzt die komische Lösung:
Wenn ich das invalidate() 2 mal hintereinander aufrufe, sieht alles gut aus.Sollte da nicht 1 invalidate() reichen?
Liegt da vielleicht sogar das eigentliche Problem, dass die TimerEdit.py von 2006 nicht mehr refreshed hat? -
So wie latte0815 schrieb, funktioniert bei ihm das angepasste pzyP4T.
Ich habe dort einfach die beiden Funktionen "refill" und "fillTimerList" aus der angepassten TimerEdit.py aus Post #79 direkt in das Plugin integriert.
Damit ist das Plugin bezüglich dieser beiden Funktionen unabhängig von der TimerEdit.py.Nun muss man nur noch abwarten, was mit dem GP3 passiert.
Das überschreibt offensichtlich noch die neue Funktion fillTimerList der TimerEditor.py mit einer eigenen Funktion, wodurch kein Refresh der DreamOS-Timerliste erfolgt.
Hierfür hilft im Moment nur der patch aus Post #23. -
Ich hab das gerade mal in pzyP4T integriert.
Mal sehen, was beim Test durch latte0815 rauskommtBei mir lief es erstmal.
Wobei ich da kein guter Referenz-User bin -
Man könnte aber alle nötigen alten Funktionen direkt ins pzyP4T-Plugin integrieren.
Das probiere ich Abend mal.Hatte bisher immer versucht, den neuen Code der TimerEdit.py mit dem pzyP4T-Plugin in Einklang zu bringen.
Danke @gutemine für den Denkanstoß
-
Nutzt du aktuell die Variante aus #79 ?
Funktioniert das bei dir komplett?Ich nutze ja die Anpassung aus #23 in Verbindung mit der alten fillTimerList (Replace durch das GP3).
-
Dann kennst du zumindest einen Verursacher
-
@muelleimer321
Hast du GP3 installiert? -
'dre' hatte oben in #77 ja schon einen recht konkreten Hinweis gegeben.
Mit GP kann man das aber erst testen, wenn GP die eigene fillTimerList angepasst hat. Sonst dreht man sich ja im Kreis
Muss ich also noch warten, was da kommt. -
Ok, ich geb mich geschlagen und warte ab, was die Ersteller der Plugins machen.
Bis dahin ist der Workaround vielleicht doch eine LösungBeim pzyP4T bin ich mir gar nicht sicher, ob der Ersteller überhaupt noch aktiv dabei ist ???