Schimmelreiter-Images für Vu+ Solo²-Clones (Sunray und Lonrisun)

[Schimmelreiter]

Die meisten Teams bauen Images nur für solche Boxen, für die sie aktiven Support vom "Hersteller" bekommen, d.h.
1. einen Ansprechpartner für Bug-Reports
2. Testboxen

Vu+ interessiert sich nicht sonderlich für einen breiten Image-Support und unterstützt OpenHDF nicht oder nicht in dem Maße, wie OpenHDF das gerne hätte.
Also baut OpenHDF - genauso wie seit kurzem auch OpenNFR - keine Images für neuere Vu+-Boxen, lediglich die alten Boxen Vu+ Solo, Vu+ Duo, Vu+ Zero und Vu+ Solo SE werden noch offiziell unterstützt.

Prinzipiell ist es aber möglich, jede beliebige Distro der oe-alliance (OpenATV, OpenBH, OpenHDF, OpenNFR, OpenSpa, OpenViX, ...) für jede durch irgendeine Distro unterstützte Box selber zu bauen und genau das mache ich im Falle von OpenHDF für die Vu+ Solo².
So gesehen könnte ich auch OpenEight (Die Haus-Distro von Octagon) für eine Gigablue oder teamBlue (Inoffizielle Nachfolge-Distro der Gigablue-Haus-Distro openMips) für eine Vu+ Solo² bauen ...

Was bzw. wie viel man bauen kann ist nur durch die Menge an zur Verfügung stehenden Ressourcen begrenzt, mit genug Build-Servern im Nacken kann man (fast) jede Distro für jede Box bauen ...

Da ich ja nun auch selber entwickle, brauche ich meinen einen Build-Server "leider" auch, um Test-Images für meine anderen Boxen (Vu+ Duo², Quadbox 2400, Octagon SF4008 und seit neuestem auch eine Gigablue Quad 4k) zu bauen und zwar momentan für drei Versionen von OpenATV fast parallel (Das aktuelle OpenATV 6.1, das kommende OpenATV 6.2 und die Machbarkeitsstudie OpenATV 7.0).

 

[Phantom]

Ich hatte mir eben das Lonsion openATV 6.1 auf eine Dragonworth gezogen da diese HW Fehler brachte. Kein Image außer die aktuellen Lonsion funktionierten. Dachte anfangs super, beim einrichten vom MP blieb die Box stehen. Timebomb. Die Box hatte nicht mal ein Datum geschweige eine aktuelle Uhrzeit

 

[Nordcappo]

Du musst dich Anmelden oder Registrieren um den Inhalt der Angebote zu sehen!

Für die Vu+ Solo2 schon lange

 

[Schimmelreiter]

Du musst dich Anmelden oder Registrieren um den Inhalt der Angebote zu sehen!

Dann hättest Du aber die einzig bekannte Dragonworth-Box, auf der Lonrisun-Images laufen ...

Du musst dich Anmelden oder Registrieren um den Inhalt der Angebote zu sehen!

Timebomb kann es nicht sein, die ist aus den Treibern rausgepatcht, auch aus den Lonrisun-Treibern, die diesen Patch ja eigentlich nicht brauchen.

Man muß sich bei dem China-Mist halt so langsam damit anfreunden, daß er den Geist aufgibt, bei der einen Box so und bei der anderen Box so.
Meine Lonrisun Solo² SE kann kein HDMI mehr und der Netzschalter ist hinüber und meine Lonrisun Solo² hat keine serielle Schnittstelle mehr ...

Ich kann auch nur noch einmal meine Warnung wiederholen:
Überlegt es Euch bitte zwei Mal, bevor Ihr Geld in Reparaturen/Reparaturversuche von Solo²-Clones steckt, insbesondere Dragonworth/Lonrisun.
Ich werde nicht ewig Images für diese Boxen bereitstellen (können), die Solo² stehen bei mir auch schon nur noch als zusätzliche Raumheizer und Testboxen.

Zum MediaPortal kann ich allerdings auch noch hinzufügen, daß es durch größere Umstellungen in letzter Zeit zu Problemen beim Update des MPs kommen kann.
Unter VTi läuft das aktuelle MediaPortal übrigens momentan gar nicht, das VTi ist einfach - ungeachtet der schwindelerregenden Versionssprünge ist es im Kern nie aktualisiert worden - langsam zu alt.

 

[Phantom]

Bin mir sicher das es eine Dragonworth war da es eine DEB Box gewesen ist. Diese waren alle Dragonworth. Das eintreten zum Brick war wie damals. Box friert ein, anschließend leuchtet nur noch der Power Touch

 

[Schimmelreiter]

Du musst dich Anmelden oder Registrieren um den Inhalt der Angebote zu sehen!

Auf Dragonworth laufen aber wirklich nur Images für Dragonworth (bzw. Lonrisun V2).
Wenn's nicht so wäre, würde ich mir unglaublich viel Arbeit sparen ...
... um Dragonworth-Images zu erstellen bleibt mir nämlich im Moment immer noch nichts anderes übrig, als es komplett aus den Quellen neu zu bauen und dem Build-Environment währenddessen den alten Kernel 3.3.8 unterzujubeln.

Das ist auch der Grund, weshalb es für die Dragonworth manche Images nicht gibt:

• OpenPLi
  In OpenPLi ist es deutlich umständlicher, abweichende Regeln für Unterboxen zu implementieren, weil OpenPLis oe-core keinen eigenen layer "meta-brands" hat, wo die ganzen Rezepte drin liegen, sondern die Original-"meta-bsp" der Hersteller einbindet.
  Auch das kann man übersteuern, ist mir aber für eines der eher schlechteren Images (Der Witz schlechthin: In OpenPLi braucht man ein extra Plugin, um den Loop-Through der Solo² zu aktivieren ... MediaPortal ging auch ewig nur mit Verrenkungen, ...) den Aufwand nicht wert.
• VTi
  VTi verwendet immer noch einen OE1.6/OE2.0-Hybrid, auch wenn sie es OpenVuPlus 3.0 nennen.
  OE1.6/OE2.0 kann man aber nur noch mit steinalten Linuxen als Bau-Server bauen, d.h. ich kann auf meinem Server gar nix für VTi bauen.
  Um VTi-Komponenten zu ersetzen, muß ich bei mir zuhause eine virtuelle Maschine mit altem Ubuntu starten, die Komponente darin bauen und sie auf den Server hochladen.
  Das Austauschen kriegt er dann hin ...
  Da VTi aber die GPL mit Füssen tritt und aus closed-source baut, kenne ich die exakte Kernel-Konfiguration für VTi nicht, schon der Lonrisun-Kernel war ein Schuß ins Blaue und nutzt einfach die öffentliche Config aus OpenVuPlus.
  
  Die Config für Kernel 3.3.8 müßte ich komplett raten bzw. so nah wie möglich an die von Kernel 3.13.5 bringen und das ist mir dieses Uralt-Image nicht wert.
  
  Abgesehen davon ist mir die Uralt-Linux-VM verlustig gegangen und da ich sie sonst für nix mehr brauche, setze ich sie auch nicht neu auf ...
  ... abgesehen davon wäre für VTi nichts einfacher zu überprüfen als die Kernel-Version. Kernel 3.3.8 kann es unter VTi Zweihundertachtundelfzig und höher ja eigentlich gar nicht mehr geben = Clone.
• OpenSPA
  OpenSPA wird mit Code gebaut, der nicht vollständig im oe-a-core enthalten ist (= lokale Ergänzungen auf deren Bau-Servern), jeder Build-Versuch allein aus den öffentlichen Quellen bricht mit Fehlern ab.

Darüber hinaus ist das komplette Selberbauen von Images sehr zeitaufwendig für den Build-Server, weshalb ich den Dragonworth-Support noch weiter runterfahren werde.
Ich habe nicht die Ressourcen, um Images für Dragonworth zu bauen, die dann von niemandem oder fast niemandem benutzt werden.

OpenBH, OpenDroid und OpenViX werde ich also in Zukunft vermutlich ebenfalls nicht mehr für Dragonworth bauen.

Du musst dich Anmelden oder Registrieren um den Inhalt der Angebote zu sehen!

Schon befremdlich.

 

[Nordcappo]

Oh bitte nicht für VU+ solo2 einstellen. Im Freundeskreis sind noch einige in Betrieb.

 

[Schimmelreiter]

Ich werde - zumindest vorerst - auf jeden Fall weiterhin OpenATV, OpenBH, OpenDroid, OpenPLi, OpenSPA und OpenViX für Sunrays und Lonrisun bereitstellen.


Sunray-Images sind ganz einfach zu erstellen, solange es Original-Images gibt:
Die lädt mein Server einfach nur runter, packt sie aus, patcht die Treiber, implantiert den opkg-wrapper und packt das Image wieder ein.

---

Das gilt für Lonrisun fast genauso:
Mein Server lädt einfach nur das Original-Image runter, packt es aus (bzw. verwendet das aus dem Sunray-Schritt weiter ), ersetzt die Treiber, entfernt kodi/gles, konfiguriert den opkg-wrapper für Lonrisun um (Installiert ist er ja noch aus dem Schritt Sunray erstellen) und packt das Image wieder ein. Nur das dieses Mal auch der Kernel durch einen von mir kompilierten ersetzt wird, denn original Vu+ und Sunray Solo² brauchen einen Patch mehr im Kernel als Lonrisun. Bis auf diesen einen Patch ist der Kernel aber identisch (Selbe Config, selbe Bauumgebung).
D.h. der einzige Zusatzaufwand für Lonrisun ist, daß ich nach jeder Änderung an der Kernel-Config im oe-a-core einmal den Kernel selber gebaut haben muß.
Für OpenPLi entfällt der "Sonder-Kernel" sogar komplett, weil OpenPLi immer noch das alte Treiber-Modell verwendet, da paßt der OpenPLi-Kernel sowohl für Sunray als auch Lonrisun.

Images für Sunray und Lonrisun stellen mich daher nicht vor Kapazitätsprobleme, das könnte sogar ein Raspberry Pi nebenher machen.

Ausnahme sind Images, die es original nicht für Vu+ Solo² gibt (OpenHDF, OpenNFR).
Da ich hier kein fertiges Image runterladen kann, muß/müßte ich es selber bauen, im Falle von OpenHDF tue ich das auch (Dann direkt für Sunray modifiziert, das wird dann analog zum oben beschriebenen Vorgang auch noch für Lonrisun umgebaut).

---

Ansonsten sind es nur die Images für Dragonworth, die ich halt derzeit immer noch komplett selber baue, jedes Image (OpenATV, OpenBH, OpenDroid, ...) und jede Version (z.B. OpenATV 6.0 vs. OpenATV 6.1) ist ein kompletter Neubau.
Ich baue also jeden Morgen je ein OpenATV, OpenBH, OpenDroid, OpenHDF und OpenViX für Dragonworth und zeitweise von OpenATV und OpenHDF sogar eine zweite Version.
Neu bauen dauert im Schnitt so 10-30 Minuten je Image und Version, ab und zu lösche ich aber auch alle Buildverzeichnisse komplett, um komplett sauber neu zu bauen und eventuelle Knoten wegzukriegen, danach dauert jedes Image und jede Version wieder einmalig Stunden ...

Momentan sind es nur die Dragonworth-Images, die von einer Einstellung bedroht sind bzw. die ich einstelle, zuerst einmal die Distros, die laut meiner Umfrage eh kein Schwein nutzt.

 

[Nordcappo]

So habe gerade openHDF auf der VU+solo2 clone installiert. Wo kann ich da oscam starten? Das fehlt in der Toolbox.

 

[Schimmelreiter]

Müßte schon drauf sein und laufen ...
Eigentlich solltest Du das oscam-Webinterface unter

Du musst dich Anmelden oder Registrieren um diesen link zusehen!

öffnen können.

 

[Nordcappo]

Ja das kann ich im Browser öffnen. Allerdings hatte ich in der Toolbox selbst ein Oscam geladen. Die config liegen nun unter var/etc/tuxbox/config/oscam

Habe dein Oscam gefunden und dort die config reingeschoben. Oscam geht auch. Trotzdem kann ich im Image irgends den Cardreader neustarten. Praktisch nur über den Internet Browser.

 

[Schimmelreiter]

Du musst dich Anmelden oder Registrieren um den Inhalt der Angebote zu sehen!

ich verwende ein ganz normales SysVinit-Script - wie man es auch auf älteren Servern vorfindet - für den Start meiner CAM.

Schema ist wie von OpenPLi bekannt:
Die Init-Scripts in /etc/init.d heißen "softcam.<softcam-name>", für jede SoftCam gibt es dort eine eigene, in diesem Fall "softcam.oscam-atv-smod".
Die jeweils aktive ist nach "/etc/init.d/softcam" verlinkt:

Du musst dich Anmelden oder Registrieren um den Inhalt der Codes zu sehen!

Wie erwähnt ist das in OpenPLi das Standardschema für SoftCAMs und wenn Du dort in den SoftCAM-Manager gehst, machst Du nix anderes als
- den Link /etc/init.d/softcam auf eine andere CAM zeigen zu lassen, wenn Du die CAM wechselst
oder
- "/etc/init.d/softcam stop" bzw. "/etc/init.d/softcam start" zum Stoppen/Starten der Softcam auszuführen.

Das Schema ist sehr geradeaus, funktioniert auch auf jedem beliebigen Debian/Ubuntu/MiNT/Raspbian (Tatsächlich habe ich das Start-Script für den oscam im Image von dem für meinen Server abgeleitet) und hat den Vorteil, daß die SoftCAM vom System selber (Also Linux) gestartet und gestoppt wird.
Das oft erwähnte Problem, daß alle Clients ebenfalls im Dunklen stünden, wenn man eine E2-Box als Server benutzt und dort mal die E2-GUI wegen Skin-Änderung oder Plugin-Installation neustartet, ist also bei dieser Methode hinfällig, da die CAM durchläuft (Anders als beim konkurrierenden Schema "Python-CAM-Start", wo die CAM erst mit der GUI gestartet und dafür auch mir ihr beendet wird und auch mit ihr abstürzt ...).

Manche andere Images (neben OpenPLi) unterstützen dieses Schema ebenfalls über die GUI, OpenHDF jedenfalls hat eigentlich irgendwo den OpenPLi SoftCam-Manager im Image, andere nicht.
Ich hatte es lokal auch schon in OpenATV drin, sind lediglich zwei kleine Dateien und eine Menüanpassung, aber OpenATV und sichtbarer SoftCAM-Support sind so eine Sache ...

Auf jeden Fall aber funktioniert dieses Schema als einziges auf wirklich allen Images, da es eben nicht auf irgendwelche Enigma2-Komponenten hofft, die mal da sind und mal nicht, sondern das überall darunter laufende Linux nutzt.

Ich habe mich dann auch nie weiter damit befaßt, meine CAM sichtbar in die GUI von OpenATV (oder OpenHF) zu bringen (Also Start- und Stop-Aktionen einzubauen), weil ich auch irgendwo den Sinn nicht sehe:
So wie sie startet, startet sie zuverlässig und läuft auch zuverlässig durch. Warum sollte ich sie stoppen und starten wollen?
Man wackelt ja auch nicht ständig an seinen physischen CA-Modulen rum ...

Und Konfigurationsänderungen die einen Neustart erforderliche machen würden, macht man doch eh per Web oder von mir aus auch telnet/ssh ...

Der Python-CAM-Start hat übrigens noch einen weiteren Nachteil:
Weil die SoftCAM dabei erst dann gestartet wird, wenn die E2-GUI schon fast fertig geladen ist, guckt man sich auch gerne mal ein paar Sekunden bis zu einer Minute lang einen schwarzen Bildschirm an, weil die CAM ja dann erst damit anfängt, sich, die Card-Reader und die Karten zu initialisieren und/oder die Proxy-Verbindungen zum HS/CS-Server aufzubauen.
Die Klage kenne ich von österreichischen OpenATV-Nutzern, die ja tendenziell auf ORF1 starten ... mit Das Erste HD als Startsender fällt einem das natürlich nicht so auf.

Soweit zum Start meiner CAM.
Ansonsten gäbe es noch zu sagen, daß sie in der aktuellen Version selbständig folgende Karten erkennt und automagisch einrichtet (solange Du keine eigene server.conf anlegst):
- Astra HD+ HD01
- Astra HD+ HD02
- Sky V13
- Sky V14
- Sky/Unitymedia V23
- Unitymedia UM01
- Unitymedia UM02
- ORF
- Redlight incl. korrekter Konfiguration für Dorcel & Co auf Astra
- viele weitere mehr, die schlichtweg keine spezielle Konfiguration benötigen (SRF, diverse XXX, ...)
plus
- eingebauter Emu für SRF.

Mit lokalen Karten und/oder SRF-Emu arbeitet mein oscam also konfigurationslos wie ein Universal-Modul und man kann mit dem nackten Image gleich losgucken.

Nichtsdestotrotz steht es Dir natürlich frei, eine andere CAM zu nutzen, dazu einfach enigma2-plugin-softcams-oscam-atv-smod deinstallieren und eine beliebige andere installieren.

 

[Nordcappo]

Danke für die Ausführungen. Ich denke ich habe den Sinn dahinter verstanden.

Ich kannte bisher nur die original Image von HDF und habe wie immer erstmal die oscam und config mit der Toolbar installiert. WebIF gestartet und die Config angepasst. Als ich dann den Cardreader Manager zum starten gesucht hatte fehlte dieser. Oh Panik was nun.

Mit dem DCC hatte ich dann deine vorinstallierten oscam config gefunden und da dann die Dateien ausgetauscht. Somit war dann der Aufruf über WebIF und oscam Neustart kein Problem mehr. Auf die Idee oscam mit WebIF unter IPvusolo2:8888 wäre ich nicht gekommen. Ich hätte mir natürlich auch deine oscam.conf ansehen können , dann wäre es auch klar gewesen. Ich war nur nicht davon ausgegangen, dass oscam schon direkt aktiv war.

 

[Schimmelreiter]

Ist quasi Service des Hauses, da ich ja nun ursprünglich hauptsächlich OpenATV gebaut habe und dort die Nachinstallation von SoftCAMs etwas aufwendiger ist.
Bei OpenATV installiere ich z.B. auch gleich den secret feed mit.

 

[Nordcappo]

Hatte ich ganz vergessen zu fragen. Am Dienstag Abend war es nicht möglich zusätzlich Plugins über Erweiterungen zu installieren. Auch per Telnet ging es mit dem Mediaportal nicht. Es wurden nicht alle Abhängigkeiten installiert. War da nur der Server nicht online oder gibt es da generell Probleme? Ich kann es jetzt nicht mehr testen, da mein Bruder die VU schon zurück hat.