Was verursacht sehr langsamen Systemstart?

    • Was verursacht sehr langsamen Systemstart?

      Hallo, ich finde es sehr lästig, dass mein HDF 6.5, neueste Version, sehr lange braucht. Ein Neustart des Systems braucht bei mir mehr als 2.45 Min. Nun habe ich parallel ein Teamblue Image installiert, das weniger als die Hälfte der Zeit braucht - mit auch einigen Plugins. Vor einer aufwendigen Testreihe samt nackter Installation wollte ich erstmal fragen, ob es allgemeine Erfahrungen über typische Systembremsen gibt, seien es Plugins oder Systemeinstellungen, Skins usw... Wer hat da Tipps? Danke, Tom

    • Hm, habe mal Mounts entfernt, kein Effekt. Dann das Debug-Log eingeschaltet und hier sehe ich einen Zeitsprung wegen der Picons!

      Spoiler anzeigen
      07:20:20.5951 { } /usr/lib/enigma2/python/Components/Language.py:90 activateLanguage Activating language Deutsch
      07:20:20.8569 { } /usr/lib/enigma2/python/skin.py:234 load_modular_files [SKIN] loading modular skin file : Blue-Line-OCT-4HDF/mySkin/skin_AnalogClock_weather_grey_progress.xml
      07:20:20.8600 { } /usr/lib/enigma2/python/skin.py:234 load_modular_files [SKIN] loading modular skin file : Blue-Line-OCT-4HDF/mySkin/skin_Channel_Selection_3_Fields.xml
      07:20:20.8632 { } /usr/lib/enigma2/python/skin.py:234 load_modular_files [SKIN] loading modular skin file : Blue-Line-OCT-4HDF/mySkin/skin_Graphical_EPG_Full.xml
      07:20:21.1418 [ ] gdi/grc.cpp:211 thread [gRC] main thread is non-idle! display spinner!
      07:20:21.1635 { } /usr/lib/enigma2/python/Components/Renderer/Picon.py:30 onMountpointAdded [Picon] adding path: /usr/share/enigma2/picon/
      07:23:22.3469 { } /usr/lib/enigma2/python/Components/NimManager.py:1183 readTransponders Reading cables.xml
      07:23:22.6402 { } /usr/lib/enigma2/python/Components/NimManager.py:1185 readTransponders Reading terrestrial.xml
      07:23:22.8363 [ ] dvb/sec.cpp:1401 clear eDVBSatelliteEquipmentControl::clear()


      Ich habe keine Ahnung vom Lesen von Logs, aber das erscheint mir doch auffällig. Werde also mal schweren Herzens die Picons runterschmeißen, oder?

      Wenn es sinnvoll erscheint, kann ich auch gerne die gesamten ersten Minuten des Logs hier einstellen, aber diese Stelle dokumentiert doch eine erhebliche Verzögerung.

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Berniecat ()

    • Guten Morgen,
      Habe ebenfalls die neueste Version auf meiner Gigablue, und habe als Referenz meine Bootzeit bis zum ersten Bild mit Ton gemessen. Das waren 61 Sekunden.
      GigaBlue UHD QUAD 4K
      OpenHDF 6.5.97 (2021-01-31)
      Tuner A-H = 8 * DVB-S2X NIM(45308X FBC) (DVB-S2X)
      Tuner I - J = 2 * GIGA DVB-T2/C NIM (TT3L10) (DVB-T2)
      Disk = 4TB

    • Die Bootzeit hängt von vielen Dingen ab. Bei sehr langen Bootzeiten ist oft das Netzwerk Schuld.
      Aber auch viel hängt von den installierten Plugins ab. Wirklich vergleichen kann man die Images nur, wenn alles gleich eingerichtet wurde. Etwas schneller sind meist die Images welche auf PLI-Basis laufen.
      ____
      Hans



      Achtung: Kein Support über private Nachrichten!


      TV - TCL 65T8B Ulra HD
      Eutelsat 13°E und Astra 19,2°E Unicable-Matrix mit Wide-LNB

    • hallo

      Und wie Viele FavoritenListen hast Du den unter der Blauen Taste Favoriten ? und die haben vermutlich auch alle Picons.

      Ich zbs Lösche alle nicht benötigten Favoriten restlos von der Box.
      Und was hast Du benutzt? den Picon Manager oder PiconUpdater.

      gruss langer
      Edision OS Mega--2xFormuler F1--VU+solo se V2 DVB C--Xpeedlx Class C--2xET9200--LX1+2.
      HD+über Sat.
      2Play 50
      Philips 8654-JTC 2032TTV

    • Dein log zeigt ja leider nur einen Ausschnitt, aber wie du selber festgestellt hast wird ein Pfad zu "picon" gemountet.

      Ob bewusst oder unbewusst, das sieht sehr nach Auslagerung auf HDD aus.
      Ich vermute du hast via dem Piconmanager dies so aktiviert.

      Jetzt wird auf deiner Festplatte dort ein Pfad mit Symlink zu Picon liegen.
      Das ist für ungeübte sehr ärgerlich.
      Du musst den Symlink im Image löschen und die picon oder besser den "picon"-Ordner auf der HDD löschen.
      Den Picon manager deinstallieren.
      Dann System neu starten und gucken wie es mit dem Systemstart sich verhält.
      Wenn alles wieder gut, dann beim eventuellen reaktivieren des PiconManager drann denken dies intern zu lösen.
      Hab das Ding ewig nicht mehr genutzt, aber bin mir sicher das man das dort genauso einstellen kann.

      Grüße

    • Ich habe das jetzt gerade nochmal überprüft, es gibt definitiv keine Auslagerung auf die HDD, dort auch keinen Ordner und dafür liegen Ordner und enthaltene Picons im Standardpfad in /usr/share/enigma2/picon/.
      Mein log zeigt ja diesen Pfad auch in Nr. 1635. und genau da beginnt die Verzögerung von 121 Sek. Ich habe jetzt die Icons auch mal gelöscht und in den Einstellungen überall (?) die Anzeige der Picons abgestellt, aber leider ohne Erfolg. Ich werde dazu nochmal ein log ziehen. Aber erstmal Danke für die Hilfe

    • rantanplan schrieb:

      Da liegt irgendwo ein Symlink.
      Das sollte leicht überprüfbar sein. Auf der Kommandozeile:

      Quellcode

      1. cd /usr/share/enigma2/picon
      2. pwd -P

      "pwd -P" sollte dir das "echte" Verzeichnis anzeigen - wenn das irgendwohin versymlinkt ist, sieht man das.

      Beispiel (bei mir ist /usr/share/enigma2/picon kein Symlink, daher nehme ich ein anderes Beispiel):

      Quellcode

      1. root@vusolose:/var# cd /tmp
      2. root@vusolose:/tmp# pwd -P
      3. /var/volatile/tmp

      Um noch sicher zu sein, dass es kein Mountpoint ist, einfach "mount" prüfen.

      Was mir schon aufgefallen ist, und was bisweilen schon zu picon Problem führte: An diversen Stellen im E2-Quelltext sah ich verschiedene Picon-Pfade hartcodiert. Der Code prüft diese Pfade in bestimmten Situationen alle ab, wenn im eigentlichen Picon-Pfad das Picon nicht gefunden wird. Meines Erachtens ein Bug, oder sagen wir zumindest ein Design-Fehler.

    • Quellcode

      1. 07:20:21.1635 { } /usr/lib/enigma2/python/Components/Renderer/Picon.py:30 onMountpointAdded [Picon] adding path: /usr/share/enigma2/picon/
      und das macht mich daher ja stutzig.
      Daher auch meine Vermutung Symlink, möglich aber auch mehrere Pfade zu den picon.

      Irgendwas ist da faul. Das ist sicher kein direktes Image Problem.
      Dies wurde mit oben erwähnten Plugin unbewusst erstellt.
      Grüße

    • Habe mir das noch mal angeschaut. Der Quelltext hat sich in der Tat geändert. Die hartcodierte Verzeichnisliste ist jetzt ganz kurz (/picon und /usr/share/enigma2/picon), zusätzlich werden aber auch noch die entsprechenden Verzeichnisse in gemounteten Partitionen des Festplatten-Managers gesucht. (Das ist der Changelog-Entry von dir).

      Egal, durch das Kommando von mir oben kann man feststellen, ob da ein symlink ist oder nicht. (Ich glaube eher nicht ...).

      Weiterer Test @Berniecat wäre, alle HDDs, USB-Sticks, SD-Karten abhängen und noch mal testen.

      Wenn ich mich recht entsinne, gab es den Picon-Such-Quelltext nicht nur an einer Stelle sondern auch in Skins, vielleicht auch Plugins. (Für mich kaum verständlich - sowas sollte doch eine Kern-Api von E2 sein, und nicht für jeden neu zu erfinden und im Zweifel seine eigene Konvention verwenden).

    • Naja, ein Skin will unter Umständen die Picons in einer bestimmten Größe. Da könnte es schon Sinn machen, diese zu transponieren. Allerdings sollte das nur einmal gemacht werden, wenn man den einrichtet und die Picons dann so abgespeichert werden, wie man sie benötigt.
      ____
      Hans



      Achtung: Kein Support über private Nachrichten!


      TV - TCL 65T8B Ulra HD
      Eutelsat 13°E und Astra 19,2°E Unicable-Matrix mit Wide-LNB

    Flag Counter