Image update problem april 2016

  • Ich habe jetzt die update blockiert im /etc/tuxbox/ durch:


    Blockieren:
    echo "tuxbox-common hold" | dpkg --set-selections


    Wieder herstellen:
    echo "tuxbox-common install" | dpkg --set-selections


    Kontrollieren
    dpkg --get-selections tuxbox-common


    Ich sehe mich an ob es mit dpkg-divert das nur auf satellites.xml fokussieren kann aber das wird später heute.

    DM.One AIO, DM920, DM7080 archiviert DM8000 aus Dezember 2008 und eine DM600.

  • Im Prinzip ist es nicht so wild wenn du das Update von diesem Paket verhinderst, viel ist da ja nicht drin.


    Trotzdem wär es schon wenn obi die satellites.xml mal "fixen" würde, denn die die im GIT liegt ist definitiv kaputt und gar nicht für Enigma2 geeignet. Diese enthält sogar ungültige Parameter für die Polarisation (L und R), außerdem liegt dort 28,2°E immer noch auf 28,4°E was vielen Usern immer wieder Probleme mit den Picons bereitet und die Satposition auch nach dem Update aus den Kanallisten verschwunden ist.


    Geb dir aber recht, ich würde auch gern meine persönliche satellites.xml in /etc/enigma2/ platzieren und dann diese immer bevorzugt behandeln. :winking_face:

  • Ich kann jetzt nur satellites.xml ausschließen von eine update.



    Wie man sehen kann wird eine saltellites.xml.distrib generiert und wenn es ein update gibt dan wird diese file überschrieben und die satellites.xml wird nicht geändert.


    Natürlich ist die Löschung durch die satellites.xml im /etc/enigma2/ zu platzieren besser als diese Methode um die update halb zu blockieren.

    DM.One AIO, DM920, DM7080 archiviert DM8000 aus Dezember 2008 und eine DM600.

  • vielleicht mal den apt cache unter /var/cache/apt/archives checken, um beim thema zu bleiben


    mit apt-get clean schafft man wieder platz da :winking_face:

  • Übrigens versteh ich immer noch nicht wieso sein Flash so voll ist, ich hab mehrere Buildverzeichnisse für das MediaPortal in meinem Flash und trotzdem mehr Platz frei als er.


    219MB frei, das Buildfolder hat 115MB + 123MB Picons, also ich kann beim besten Willen nicht verstehn wie man den Flash so voll bekommt. :grinning_squinting_face:

  • naja bei der git umstellung im nn² ist es mir auch passiert, war da ebenso einfach zu doof :grinning_squinting_face:

  • warum habe ich wohl das Überprüfen (read only, also ohne reparieren) des root Filesystems oder das Defragmentieren des Root Filesystems ins dBackup Plugin eingebaut ?


    Sichern und Neuflashen mit dem Recovery BIOS hilft auch um Müll von einem evt. korrupten Filesystem loszuwerden, weil dabei das ext4 root Filesystem komplett neu gemacht wird.


    LG
    gutemine

  • Die db liegt gem. der ausgabe auf der sdcard. 4 fhd-skins brauchen sicher auch platz. Der cache selbst kann auch keine 400 mb gross sein

    Gruss
    Dre


    Boxen (im Einsatz): DM920, DM900, DMOne
    Developer Project Merlin - we are OpenSource

  • Als erstem Danke an Gutemine fur dBackup und die plug-in hat oft meine A.... gerettet und ich werde die mal auch updaten vom v0.15 nach v0.33 Es lauft nun gerade eine EPGimport und die benötigt einige zeit bis die fertig ist.


    Meine epg.db ist mehr dan 100MB aber auch ohne die bleib /dev/root/ viel platz benotigen. Ich nehme an das epg.db im RAM gelesen wird. Meine epg.db liegt auf ein Speichermedium. Gerade noch ein Image Backup gemacht und die jetzt 182MB.

    DM.One AIO, DM920, DM7080 archiviert DM8000 aus Dezember 2008 und eine DM600.