Verlängerter Bootvorgang seit Update

Benares · 23. April 2018, 20:37

Seit einem der letzten Updates meiner Duo2 dauert der Bootvorgang geschätzte 2-3 mal so lang als früher. Sonst funktioniert soweit alles. Entweder muss das bei dem Update von 13.0.3 auf 13.0.7 am 11.03.18 (102 Pakete) oder beim Update auf 13.0.9 am 13.03.2018 (90 Pakete) passiert sein, evtl. auch schon beim Update zuvor von 13.0.2 auf 13.0.3 am 11.02.2018 mit 165 Paketen, so genau weiß ich das nicht mehr. Ihr habt ja ganz schön gewirkt.
Aktuell ist alles "auf aktuellen Stand". Was da genau alles aktualisiert wurde, kann ich nicht mehr nachvollziehen.
Gibt es Erfahrungen dazu? Wie kann ich herausfinden, woran der Hänger liegt? In der Oberfläche äußert sich das nur in einer sehr langen "Loading..."-Phase.
Andere Modifikationen gab es außer den Updates seitdem keine.

Radar · 23. April 2018, 20:44

Ich würde das aktuelle Image komplett sichern, ebenso die Einstellungen etc.
Dann das aktuellste Image neu flashen.
Bevor Erweiterungen & Plugins installiert mit blau grün grün das Image auf
den neuesten Stand bringen.

hgdo · 23. April 2018, 20:57

Die Option, dass bereits aufgenommene Sendungen im EPG markiert werden, benötigt beim Start etwas Zeit. Stell das mal testweise ab.
Menü -> VTi -> Einstellungen EPG

Benares · 24. April 2018, 18:35

@Radar:
Danke, aber neu Flashen wollte ich allein deshalb nicht gleich. Ich wollte erstmal herausfinden, woran die verlängerte Startzeit liegt.
@hgdo
Danke auch. Das könnte ein Grund sein. Ich habe 2 NASe über Symlinks und automount in das Aufnahmeverzeichnis eingebunden. Eins der beiden ist aber meist aus.
Wie heißt die Option unter "Einstellungen EPG" genau? Ist das "Zeige Symbol wenn Sendung in der Datenbank vorhanden ist" ? Die steht momentan auf "Ja"
Hab sie ausgeschaltet und werde mal testen, ob das was bringt. Evtl. entferne ich auch den Link zum alten NAS, um Folgeprobleme auszuschließen.

Gibt es sonst noch irgendwelche bekannten Einstellungen, die die Bootzeit evtl stark negativ beeinflussen?

hajeku123 · 24. April 2018, 18:41

Ich würde das VTi Debug Log aktivieren und dort nachsehen, wo die Zeit bleibt.

Benares · 24. April 2018, 18:44

Und wo macht man das und in welcher Datei landet das dann?

hajeku123 · 24. April 2018, 18:49

Menü ⇒ VTi ⇒ Einstellungen - System
Die Datei findest du dann unter /media/hdd

Benares · 29. April 2018, 10:42

So, ich hab jetzt mal etwas weiter probiert. Die empfohlene Anpassung von hgdo hat nichts gebracht. Dann hab ich mal das Log aktiviert und mir die Logfiles angeschaut.
Die gesamte Bootzeit beträgt etwa 4,5 Minuten. Eigentlich gibt es keine größeren Lücken, bis auf eine Stelle bei 10:23.39, wo über eine Minute vergeht.

Quellcode

10:23:11.162 [e2-python] [AutoRes] got event evFramerateChanged
10:23:11.453 [e2-python] [AutoRes] determineContent
10:23:11.586 [e2-python] [VLC] Checking for buildin servicets ... no
10:23:11.589 [e2-python] [VLC] Checking for existing and usable servicets.so ... No module named servicets
10:23:11.589 [e2-python] [VLC] Checking for usable gstreamer service ... yes
10:23:11.828 [e2-python] EMC: Next[color=#FF0000][/color] trashcan cleanup in 877 minutes
10:23:12.212 [e2-core] [eEPGCache] start caching events(1524990192)
10:23:13.548 [e2-core] sdt update done!
10:23:13.924 [e2-python] EMC delPathFromCache /media/hdd/movie/trashcan
10:23:13.925 [e2-python] EMC: [EMCMS] trashcan cleanup: nothing to delete...
10:23:16.436 [e2-core] child has terminated
10:23:16.437 [e2-core] pipes closed
10:23:16.465 [e2-core] child has terminated
10:23:16.465 [e2-core] pipes closed
10:23:19.221 [e2-core] [eEPGCache] abort non avail viasat reading
10:23:19.221 [e2-core] [eEPGCache] abort non avail mhw reading
10:23:21.914 [e2-core] [eEPGCache] schedule other finished(1524990201)
10:23:22.022 [e2-core] [eEPGCache] nownext finished(1524990202)
10:23:26.178 [e2-core] [eEPGCache] schedule finished(1524990206)
10:23:26.179 [e2-core] [eEPGCache] stop caching events(1524990206)
10:23:26.179 [e2-core] [eEPGCache] next update in 60 min
10:23:30.232 [e2-core] no ancillary data in audio stream... abort radiotext pes parser
10:23:39.099 [e2-python] Timeout!
10:23:42.147 [e2-python] Timeout!
10:24:49.039 [e2-python] action -> InfobarMenuActions mainMenu
10:24:49.040 [e2-python] loading mainmenu XML...
10:24:49.047 [e2-python] Subtitles Subtitles
10:24:49.049 [e2-python] TimerEdit TimerEditList

Alles anzeigen

Könnt ihr mir sagen, was da passiert?

hajeku123 · 29. April 2018, 11:04

zu diesem Zeitpunkt ist der Bootvorgang bereits abgeschlossen.
Ohne ein vollständiges Debug-Log wird dir da niemand helfen können.

Kannst auch noch mal die Version 13.0.3 aus deiner Sicherung wieder herstellen, dort das Debug Log aktivieren und dann die beiden Log-Files miteinander vergleichen.

Benares · 29. April 2018, 11:17

ungern - es läuft ja sonst alles. Ich dachte, 3 paar Zeilen vor dem Timeout reichten für eine Eingrenzung aus.
Ich häng hier mal das komplette Log an.

hajeku123 · 29. April 2018, 13:09

du musst dein Log ja nicht zeigen. Ich habe kein Problem damit, wenn du deinen Fehler selbst suchst

so wie ich das sehe, hängt dein Problem mit Openwebif oder der Tunerconfig zusammen.

10:21:52.644 [e2-core] main thread is non-idle! display spinner!
10:21:53.669 [e2-python] remove DVI-PC because it does not exist.
10:21:53.680 [e2-python] set HDMI Colorspace : Edid(Auto)
10:21:53.682 [e2-python] hotplug on DVI
10:21:53.688 [e2-python] set Videomode DVI 1080p 60Hz
10:21:54.064 [e2-python] set aspect, policy, policy2, wss 16:9 panscan letterbox auto
10:21:56.777 [e2-core] resolve: resolve ${datadir}/enigma2/setup.xml
10:21:56.777 [e2-core] resolve: -> /usr/share/enigma2/setup.xml
10:21:56.777 [e2-core] resolve: resolve ${libdir}
10:21:56.777 [e2-core] resolve: -> /usr/lib
10:21:57.778 [e2-python] [OpenWebif] -D- tuner '0' 'Vuplus DVB-C NIM(SSH108)' 'Tuner A'
10:21:57.780 [e2-python] [OpenWebif] -D- tuner '1' 'Vuplus DVB-C NIM(SSH108)' 'Tuner B'
hier eine Minute Wartezeit ist nicht normal
10:22:57.909 [e2-core] resolve: resolve ${libdir}/enigma2/python/Plugins/SystemPlugins/TransCodingSetup/plugin.pyo
10:22:57.910 [e2-core] resolve: -> /usr/lib/enigma2/python/Plugins/SystemPlugins/TransCodingSetup/plugin.pyo
10:22:57.939 [e2-core] resolve: resolve ${datadir}/enigma2/
10:22:57.939 [e2-core] resolve: -> /usr/share/enigma2/

Benares · 29. April 2018, 15:59

Ich meinte ja nicht das Log, sondern das zurück auf 13.0.3.
Ups, diese Lücke hab ich ganz übersehen.
Die Tuner- und Openwebif-Einstellungen schau ich mir gleich mal an, aber eigentlich hab ich daran seit Ewigkeiten nichts mehr geändert.