Ohne Netzwerk-Anschluß geht meine Receiver bei Timeraufnahmen nicht in den Standby.
Ich hab das mal beobachtet. Zum einen braucht er statt <1min nun >2min zum Booten. Das ist an sich nicht weiter schlimm, aber danach bleibt er an. Und soweit ich weiß ist die Regel, ist er bei der Aufnahme an bleibt er das auch nach der Aufnahme.
Normalerweise sollte er sich
- booten
- in Standby gehen
- Aufnahme machen
- Ausschallten
Könnt ihr mir helfen diese Verhalten auch ohne Netzwerk zu bekommen?
Vielen Dank.

(PS.: Man kann das Netzwerk wahrscheinlich auch einfach gar nicht konfigurieren - aber mal habe ich und mal nicht. Sollte bitte immer gehen.)

Netzwerk-Laufwerk ist nicht dran. Wetterplugin und Wetterplugin-Handler hab ich deinstalliert.
Was kann es noch sein? So ein autoupdate für IP-TV oder so? Wo kann man das einstellen?

Wo/wann wird denn entschieden, dass sich die Box wegen einer Aufnahme wieder schlafen legen kann. Also wie sieht die Logik aus: Wenn x und y , dann z und wo passiert das?
Vielleicht wird durch das boot-delay etwas verzögert und kommt dadurch durcheinander? Läßt sich das evtl umkonfigureren, wenn es sich nur um eine Zeitkonstante handelt?

Vom Linux kenn ich "dmesg" aber hier gibt es keine Zeiten zu sehen und das was hier verzögert könnte auch in der Anwendung sein ... für mich nicht zu unterscheiden.

Was im Kernel log noch aufgefallen ist:

Built against headers 4.4.35_hi3798mv2x #1 SMP Tue Dec 12 14:16:24 CST 2017 arm
Running on kernel 4.4.35 #1 SMP Fri May 14 17:53:44 UTC 2021 armv7l
WARNING: Running kernel does not match configured kernel headers the driver was built with! The driver needs to be rebuilt with the correct kernel headers!

Das sollte nicht sein, oder?

Weitere Erkenntnis: Wenn das WAN (Internet) nicht erreichbar ist ist es egal, solange es wenigstens ein lokales Netzwerk gibt. Funktionial bringt das zwar nichts, aber hier macht es einen Riesenunterschied.
Zum Test hab ich in der FB den Zugang gesperrt (konnte das überprüfen) - da hab ich nach 45s ein Bild und nicht erst nah 2:10 ohne Netz. Vielleicht hilft die Info das einzugrenzen. Per Ping antwortet die Box in diesem Fall nach ca 19s.

Das ist (wie zu erwarten war) kein Problem.
Aber bitte nicht als Workaround vorschlagen der Nutzer solle das Netzwerk manuell ein- und wieder ausschalten müssen. Außerdem müsste man beim Ausschalten schon wissen ob es beim Anschalten da ist.
Mir wäre an einer echten Lösung gelegen. Ein PC oder anderes Gerät bootet ohne Netzwerk auch nicht länger (obwohl die Zeit nicht das Hauptproblem ist, aber möglichweise eine Ursache). Ich würde das bei der Gelegenheit auch gern verstehen was und wie das vor sich geht. Dazu hab ich bisher noch nichts erfahren.

Moment. Ich fordere nicht - ich frage, ob sich jemand auskennt WARUM das so ist und ob man (oder auch ich selbst durch Konfiguration oder Abschalten von Diensten) dem abhelfen kann.
Wenn ich unterwegs bin (Camping) - dann ändern sich die Situationen (nur als Beispiel). Ich möchte nicht mein Leben an die Maschine anpassen sondern andersrum. Es ärgert mich ein wenig wenn ich so viel Zeit in meine Begründung/Verteidigung investeren muss, das würde ich lieber in die Lösung bzw die Erforschung der Ursache stecken. Das mir das wichtig ist, habe ich glaube ich schon bewiesen.

Und nein, es ist Internet oder kein Internet. Es geht nur um den Zustand zur Bootzeit. Es ist völlig klar das es Probleme macht wenn das Internet beim Start da ist und dann weggeht. Aber bitte zurück zum Thema. Warum weicht ihr aus? Wenn ihr es nicht wisst ist das keine Schande. Und wenn euch das egal ist, kann ich auch nichts machen. Ich kenn mich ein bisschen mit Linux aus, aber das hier ist soweit ich weiß alles Python. Wo findet eigentlich die Entwicklung des Grundsystems (git?) ab? Oder ist das ein Problem eines Plugins? Ich hab echt keine Ahnung....

Ich verweise noch mal auf Post 3, da stehen alle Fragen drin. Es ist normal das beim Starten von Diensten "geprobt" wird und auch ein bisschen gewartet. Aber hier ändert sich die Funktion! Man kann das ignorieren oder als PAL* betrachten, richtig ist es imho nicht.

*Problem anderer Leute

@Koivo:Ich schätze euch und eure Arbeit sehr, das vorab. Aber hier frage ich mich: Was soll das? Habt ihr gelesen was ich geschrieben hab? Bitte, bitte, bitte: Sagt nicht was andere Menschen wollen oder brauchen. Das ist anmaßend. Es geht hier auch nicht nur um mich, sondern eine Freundin, der ich das System empfohlen hab, weil ich es toll finde. @zeini: der will ich nicht sagen wenn du Internet hast machst dies sonst jenes. Wer will den das dauernd umstellen? Hätte ich auch keine Lust zu.
Wenn ihr dazu nichts wisst, kann man das auch einfach zugeben. Oder gar nichts sagen, wenn einem das egal ist. Es ist zwar auch nicht schön ganz ohne Feedback, aber das brauch ich nicht.

Kein Wort auch zu den nicht zum Kernel passenden Headern (hat nichts mit dem Problem zu tun, klar) oder wo die Quellen liegen oder irgendwas das zu einer Lösung führt außer den Hinweis auf Plugins.

So, vielleicht bannt ihr mich jetzt, aber auch Leuten die man schätzt muss man mal was Sagen können. Und bitte wartet zwei, drei Stunden vor einer Antwort und lasst es euch noch mal durch den Kopf gehen.
Ein schönes Wochenende.

Das ich so fordernd rüberkam war mir nicht klar - das nehme ich an und entschuldige mich - das war nicht so gemeint. Es ist auch an Anspruch an mich selbst, Lösungen zu finden - da will ich Teil davon sein.
Netzwerk disabled Test: Post #5, kann man aber vielleicht auch überlesen. Das geht dann, ist aber keine Lösung für uns.
Das mit dem Debug-Log wußte ich nicht - und wahrscheinlich habt ihr angenommen das ich das schon kenne. Das hätte ich mir selbst als erstes angesehen, den Kernel-Log hatte ich bereits gecheckt. (Post #3). Mir ist klar durch die Glaskugel kann man Fehler nicht finden.

Den Link (auch für mich selbst wenn ich da noch mal suchen:
Debug Log im openHDF Image erstellen )

Log folgt ... Timeraufnahmen dauert immer wegen der Vorlaufzeit ...

Ganz so hart ist es nicht. Das Netzwerk auf der Box soll konfiguriert sein: ja.
Ist es sicher das es verbunden ist beim Start: nein.
Das geht so mit Millionen PC, Laptops und embedded Geräten und ist erst mal keine Zumutung für ein Gerät. Nicht immer ist ein WLAN da bspw. Das Gerät testet: geht was, ok dann mach - wenn nicht, dann können alle Dinge die Netzwerk verlangen nicht funktionieren. Aber alles was nicht mit Netzwerk zu tun hat geht normalerweise.

Das log hat ergeben das der Zeitverzug beim Booten durch "running HDFreaks autostart scripts" und da insbesondere durch das checken nach updates entsteht. Das ist soweit auch normal und keine Kritik, wußte ich aber nicht, das dies überhaupt passiert.
Ich konnte leider (auf die Schnelle) keine Einstellung finden, das es mir erlaubt den Update-Check zu disablen und die Toolbox installiert zu lassen. Ich hab daher testweise die HDF Toolbox deinstalliert und nun bootet die Box auch ohne Netzwerk schnell.

Nun geht es aber gar nicht (hauptsächlich) um die Bootzeit, sondern darum das die Box bei einer Timeraufnahme aus den Off-Zustand nicht in den Standby geht (und sich daher am Ende der Aufnahme auch nicht wieder ausschaltet). Diesen Mechanismus hab ich nicht verstanden und konnte mir noch keiner erklären. Ich spekuliere mal:
* das Timing mit den Aufwachzeiten gerät durcheinander. Da gibt es eine Kette von Einschalten (x minuten vor der Aufnahme) , Vorbereitung (mounten der USB-Laufwerke) ... ich hab gesehen, da gibt es Optionen, die mir allerdings noch nicht vollkommen klar sind.
* es gibt ein Problem, weil keine Zeit vom Netzwerk (NTP) kommt
* oder ganz anderes.

So - während ich das geschrieben hab hat auch der Test funktioniert:
* Timeraufnahme programmieren
* Box runterfahren (off, nicht standby)
* 5 Min vor der Aufnahme fährt die Box hoch und geht in den Standby (hurra!)
* Aufnahme erfolgt im Standby
* Box fährt runter.

Frage: Kann man das Checken auf updates in der HDF-Toolbox unterbinden? Das wäre eine Lösung (die allerdings noch nicht erklärt was dadurch durcheinander gerät).

Ja, hat den Nachteil das bei einer Aufnahme während man TV sieht dann zumindest die Abfrage kommt, ob die Box runtergefahren werden kann. Aber ja, wäre ein Workaround.

Ich hab mal die HDF Toolbox wieder installiert und auf Verdacht die "Bootzeit vor Aufnahme aus dem Deep Standby" von Standard 5min auf 8min erhöht. Das sollte die verlängerte Bootzeit ausgleichen. Leider kann ich grad nicht testen, weil mich die bessere Hälfte vertrieben hat und tatsächlich gucken will.

@Koivo: Das hab ich nicht verstanden. Man kann nicht wirklich den Check unterbinden aber komplett deaktiviert werden?
Nein, das alles hat nichts direkt mit Aufnahme zu tun, nur stimmen dann evtl voreingestellte Zeiten nicht mehr. Wie schon mehrfach gesagt weiß ich nicht, WAS genau die Bedingung ist, dass die Box nach Booten in den Standby geht (oder eben in meinem Fehlerfall nicht). Das interessiert mich.

Edit: aus dem Log (mit Netzwerk): Sollte mir das Sorgen machen?
Collected errors:
* opkg_solver_install: Cannot install package iptv-player-xxx.
Couldn't find anything to satisfy 'iptv-player-xxx'.
Unknown package 'iptv-player-xxx'.
/usr/lib/enigma2/python/Plugins/Extensions/HDF-Toolbox/scripts/autostart.sh: line 73: /etc/rc3.d/S50streamlinksrv: Permission denied