Box startet nicht, wenn newnigma2.to down - gelöst :-)

Ich hab meinen obigen Code mal in ein gesondertes Test-Plugin verpackt, so dass man das Ganze auch unkompliziert auf der Box testen kann.
(es erfolgt dabei im e2Log zusätzlich aber auch eine gleichlautende Ausgabe)

Den Ordner "TestPluginCheckNN2" aus der zip-Datei inkl. aller enthaltenen Dateien in folgenden Ordner auf die Box kopieren:
/usr/lib/enigma2/python/Plugins/Extensions/

Dann einen GUI-Neustart machen und im Plugin-Browser das Plugin "TestPlugin - Check NN2-Feed" starten.
Dort dann den Test mit "Ok" ausführen.

Das "True" in der Zeile bedeutet wie gesagt, dass die url lt. Code erreichbar ist.
Bei "False" ist die url lt. Code nicht erreichbar.
Da muss man jetzt eben mal testen, welche check-Zeile (Zeile1 oder Zeile 2) hier zuverlässiger den tatsächlichen Url-Status wiedergibt.
Zeile 1 (socket connect) ist dabei der aktuell im NN2-updatecheck verwendete Code.

Interessant, da bei mir heute in der Nacht immer ein "Err 101 - network not reachable" angezeigt wurde.
Bei dir ist es die reine Timeout-Meldung.

Die Timeout-Meldung hab ich hier gelegentlich auch tagsüber, wenn der Server etwas träger ist, was man ja ab und zu auch hier bei den Antwortzeiten im Forum merkt.
Falls daher die bisherigen 2s für das Timeout zu knapp sind, könnte man da ggf. auf 3sek hochgehen.

Auf jeden Fall scheint der alternative Code zur Prüfung der Servererreichbarkeit etwas besser den tatsächlichen Serverstatus (insbesondere bei dir) zu erkennen. Also werde ich heute mal für dich eine updatecheck.py damit fertig machen, damit du die Check-Option auch wieder beim Box-Start nutzen kannst

PS:
Ich hätte auch noch eine Anpassung für den NN2-Paketmanager, wo man sich nun per zusätzlichem Filter nur die anstehenden Updates anzeigen lassen kann.
Oder gab es so eine Option schon und ich hab sie nur nicht gefunden?

Mal nur so zwischendurch nachgefragt. Ist der Updatecheck nicht in jedem DreamOS Image gleich, und hätten das "Problem" dann nicht alle Images?

NN2 scheint da eigene Wege gegangen zu sein.
Dort nutzt man u.a. python-apt, was auf dem DP-Feed glaube gar nicht zu finden ist.
Offensichtlich gibt es damit ein Problem (zeitliches Blockierung der Box beim Feed-Update), wenn der Feed nicht erreichbar ist.
Und vermutlich spielt hier auch die Netzanbindung (ISP) von @AlfredENeumann auch eine Rolle, weshalb bei ihm der Socket-Connect immer als erfolgreich angezeigt wird, während bei den meisten Usern, dieser Connect-Versuch nicht erfolgreich ist.
Man muss hier aber auch bedenken, dass ja nur wenige User ihre Box nach 01.00 Uhr (neu)starten, um das Problem festzustellen, sofern sie ein ähnliches Socket-Connect-Verhalten wie bei Alfred haben.

Hinzu kommt ja auch noch, dass die Feeds bei den meisten anderen Images grundsätzlich durchgängig erreichbar sind, so dass dort solche Probleme auch nur selten auftreten könnten. Auch wird dort deshalb keine zusätzliche Online-Prüfung für den Feed durchgeführt - max. ob generell eine Netzwerkverbindung (LAN/WLAN) verfügbar ist.

Ok, danke für die Erklärung. Da das ja jetzt ein spezielles Problem bei Alfred zu sein scheint, denkst du, dein "Fix" wird noch offiziell Einzug ins NN2 finden? Hier im Thread wird das für andere User schwer wieder auffindbar sein, und da deswegen der Feed nicht neu gebaut wird, ist mehr als wahrscheinlich.

Das wurde ja schon von NN2 beantwortet
Wegen der 2-3 User, die dieses Problem haben, lohnt es nicht, den Feed neu zu bauen.
Also kann man max. für die betroffenen User hier eine alternative Lösung anbieten, was ja vom NN2-Team auch so vorgeschlagen wurde.

Ob die neue zusätzliche Filter-Option "zeige Updates" im Paketmanager nun vielleicht doch ein Neubauen des Feeds rechtfertigt kann ich nicht beurteilen.
Denke aber, dass die Aussage möglicherweise genauso lautet wie zur Anpassung beim Updatecheck

Ist ja wirklich immer die Frage zum Aufwand und Nutzen.
Und die beiden kleinen Anpassungen sind dann wirklich nicht relevant genug

Es gab ja hier aber auch einige User, die selbst beim Öffnen des Paketmanagers (meist nach Nutzung des MediaPortal) dann auch den "buffer overflow" error bekommen.
Da wäre dann mal interessant, ob die User mit dem leicht angepassten NN2-Paketmanager das Problem dann immer noch haben.

Ich werde später die angepassten Files zum NN2-Paketmanager (plugin.py, updatecheck.py und Paketmanager.py) hier hochladen.

Dann hier mal die Anpassungen zum NN2-Paketmanager.

Änderungen:
- zeige nur Pakete/Updates für die aktuelle Architecture (mipel, armhf, amr64)
bisher waren z.B. über den Mediaportal-Feed immer 3 Einträge/Updatemeldungen zum MediaPortal-Plugin vorhanden (jeweils für alle Arch-Varianten)
- alternative Online-Prüfung zur Erreichbarkeit des NN2-Feed im Updatecheck bei Boxstart (auch wird das Feed-Update beim Boxstart jetzt nur noch ausgeführt, wenn die Updateprüfung bei Boxstart auch aktiviert ist - bisher wurde das Feed-Update immer ausgeführt)
- neue Filter-Option im Paketmanager "Show Updates", um lediglich die Updates anzuzeigen (kann auch mit anderen Filtern kombiniert werden - also zeige Updates bei Plugins)
- Fehler im Paketmanager behoben, wo zu viele Pakete mit "Aktualisierbar" angezeigt wurden (da wurde eine interne Variable nicht zurücksetzt, so dass nach einem aktualisierbaren Paket auch alle danach ermittelten Pakete in der Liste als aktualisierbar angezeigt wurden)
- Versuch, den "buffer overflow" error zu verhindern bzw. zu umgehen (keine doppelte Verwendung der vollständigen Paketlisten - könnte Speicher sparen)
- der Paketmanager wird jetzt beim öffnen sofort angezeigt (erst danach wird das Feed-Update inkl. der Zahnräder ausgeführt)

Edit:
Veraltete Anlage entfernt.
Der aktuelle Download ist im Post #102 zu finden

Test auf der TWO

Nachdem man jetzt im Paketmanager über gelb "Show Updates" ausführt, und danach sofort über blau das Image Update anstößt, knallt der Paketmanager weg, wenn man den Paketmanager verlassen will.

Ah, weil die Liste für die Updates nach dem Update dann leer ist, was ja vorher nie so war

Kannst du es hiermit nochmal testen ?

Hab auch noch eine Änderung reingenommen, dass der Paketmanager beim Aufruf sofort sichtbar ist und das Feed-Update (inkl. der Zahnräder) dann erst beim sichtbarem Paketmanager ausgeführt wird.

Edit:
Hab die Datei oben im Beitrag #92 aktualisiert

So scheint es zu laufen. Habe jetzt keinen Crash mehr beim Verlassen des Paketmanagers.
Kann aber auch im Moment nicht mehr als das testen, bin ja nicht vom Problem von Alfred betroffen.

Danke für den Test.
Hab die geänderte Datei jetzt direkt im ursprünglichen Beitrag #92 aktualisiert und in #94 wieder rausgenommen.

Ist das mit dem Paketmanager (Updates werden beim erneuten Öffnen nicht angezeigt) immer wieder nachvollziehbar?
Hast du dabei noch weitere Filter gesetzt?

Ich würde sagen, dass ich das bei mir schon erfolgreich ausgeführt habe. Also beim 2. Start des Paketmanagers ist dann ja der Update-Filter noch aktiv und es wurde dann auch ein zu aktualisierendes Paket angezeigt.

Falls das bei dir reproduzierbar auftritt, kannst du ja davon mal ein Log vom Öffnen des Paketmanagers machen.
Dann noch das Feed-Update abwarten (also die Spinner abwarten).