BPanther's Neutrino Forum

Im Grunde relativ einfach:
schau in ../make/patches.mk > dort könnte man die Patche mit Pfade eintragen:
( oder ohne Pfad, wenn die direkt in Patches liegt )
Besser ist es aber das in Makefile.local einzutragen, dann kneift es nicht bei make update. Dann patcht das BS bei Neubau oder nach Neutrino distclean.
Oben in der .mk ist der Patch Helper, der es erleichtert diffs zu erstellen

Das mit dem errors=remount-rw in der fstab werde ich nochmal ändern in errors=continue, gibt kein rw sondern nur ro an der Stelle...

EDIT: Ist im GIT.

Im Grunde relativ einfach

Für steinalte Windoofies eher nicht

Ich liebe kleine, einfache Beispiele.

Ich schiebe frontend.conf immer nach /var/tuxbox/config
weil es logisch dorthin gehört. (Solange die Box am gleichen Ort steht, bleibt auch die Anschlusskonfiguration gleich)

Ich habe in build_source/neutrino-mp-ddt.org die erfoderliche Änderung durchgeführt und mir - in alter Gewohnheit - ein Diff erzeugt: und das nach ~development/my_patches/ddt/neutrino_mp_ddt/hd51 verschoben.

Was sollte ich jetzt machen, damit in Zukunft alle meine Boxen ihre frontend.conf in /var/tuxbox/config suchen ?

Für einfache, "festen Konfig-Dateien" ist kein Patch nötig. Nimm dazu einfach das own_build/neutrino-hd.boxname und packe die fertig da rein. Dabei einfach die benötigte Verzeichnisstruktur entsprechend dort anlegen. Da Du aber mit dem Verschieben (warum auch immer) somit wirklich patchen mußt, packe Deine Patches wie oben von DBO beschrieben ins Verzeichnis Deiner Wahl und gib sie entweder alle einzeln oder aber einfach das Verzeichnis selbst in der Makefile.local an, hier ein Beispiel für ein komplettes Verzeichnis:

warum auch immer

Weil ich z.B.auf dem PC 35 Verzeichnisse habe, in denen ich für jeden Broadcaster (Sat-Position von 45E bis 30W, Kabelnetzbetreiber und DVB-T2 Sendemast) einen einzelnen Scan durchführen und dessen Ergebnisse in überschaubarer Menge direkt auf dem PC bearbeiten kann. Da das über einen Symlink namens 'zapit' von einer beliebigen Box aus passieren kann- wenn sie Zugang zu dem gewünschten Broadcaster hat - kann ich dort keine frontend.conf (mit nur einem einzigen Broadcaster) gebrauchen.
Und weil eine damit verbundene Änderung der frontend.conf einen überflüssigen Neustart der Box erforderlich machen würde.
Und bei der Rückkehr nach getaner Arbeit wieder...

Leider haben die CST-Entwickler damals beim Wechsel von sat.conf zur multitunerfähigen frontend.conf auf meinen dahingehenden frühzeitigen "Einspruch" nicht reagiert.
Aber solange ich es selbst im Source richtig machen kann, ist es mir halt egal...

Dank Eurer Hinweise habe ich über Makefile.local ein paar meiner Gimmicks erfolgreich in den Neutrino-Source gepatcht.
Dazu den cifs-Zugriff auf den PC mit den Einzelverzeichnissen für die 'Programmpflege'.
Das habe ich allerdings erstmal "nach Art des Hauses" gemacht: In rcS - vor dem Start von Neutrino - nach rcS.local gesucht und dann darin die passenden Zeilen abarbeiten lassen. Passt aber mehr zu den beiden anderen Neutrino-Varianten auf der Box. War mir aber im Moment einfacher. Die 'richtige' Methode muss ich mir erst noch erlesen.

Als Nächstes werde ich mir mal "own" und "common" zu Gemüte führen. Scheint ja jede Menge Potential drin zu stecken.

Die Nachfolge-Box der HD51 soll wohl - wie die HD60 - auf dem HiSilicon-Chip basieren (und FBC wird als "schwierig" bezeichnet).

Ich hoffe daher, dass sich hier auf der VU+-Platftorm auch für die Duo4K was ergibt...

Janus hat geschrieben: Mo 7. Jan 2019, 14:25Ich hoffe daher, dass sich hier auf der VU+-Platftorm auch für die Duo4K was ergibt...

Wird sich zeigen ob das jemand einbaut, das Teil benötigt einen anderen Compiler soweit ich weiß. Ich kann das leider nicht, denn ich komme nicht mal mit dem MIPS für die normale (alte) DUO so wirklich klar.

Laut DataSheet ist da ein 64bit ARM-Prozessor verbaut...

ja ist eine 64bit proz , VU selber baut darauf auch nur 32bit.
http://code.vuplus.com/gitweb/?p=vuplus ... 88a660adb6
zeile 33

Hatte das auch schon bei der ersten 'Lesung' von User-Postings gelesen.
Hab's allerdings nicht wirklich geglaubt ... ist ja eigentlich auch unglaublich.
Hört sich aber insgesamt schon ziemlich zusammengestrickt an.

Mal sehen, was die 'freien' Imagebauer daraus machen!
Ich werde da wohl ausnahmsweise mal ein paar Monate warten.
Falls ich vorher keinen Sponsor finde...

mir kommt die box auch nicht ins Haus, aus den angekündigten 4096 MB RAM, sind nur 2048 MB RAM geworden aus koste gründen .

Also nehmen die wahrscheinlich einfach den gleichen Compiler wie bei der Solo4K. Na super, wird die CPU nicht mal richtig ausgenutzt. Probleme mit dem Image scheinen die aber auch so schon genug zu haben wie es scheint...

In meinem HD51 Image fehlt bzip2, deshalb geht meine Komplettsicherung nicht.
Auch ein neuerliches "make bzip2" erzeugt nur bunzip2.

Habe dann versucht, bzip2 mauell mit der busybox zu verlinken, kommt aber nur "applet not found",
während das vorhandene bunzip2 zumindestens auf --help richtig reagiert.

Schau einmal hier rein https://github.com/Duckbox-Developers/b ... bs.mk#L642
Da wird es wieder gelöscht , zeile auskommentieren und schon ist es im Image.

Ich habe lieber die Selektion (hd51 vusolo4k) zugefügt. Hat funktioniert und Image-Backup dann auch!

Ist ja auch schon so im GIT!