AW: Imagesammlung für Solo2 Clones - Downloads,Wünsche und Anfragen bitte hier einste
@ Schimmelreiter, inwiefern unterscheidet sich dein Sunray OpenATV 4.3 von dem von gjstroom (DreamOEM)?
Siehe Hinweis 1: Aus dem Original-Image vom 18.3.2015 erzeugt (Kein Update eines alten Images, kein Nachbau!)
Ich habe das Image direkt von OpenATV heruntergeladen, geflasht und dann
- die Vu+-Treiber durch die Sunray-Treiber ersetzt
- meinen Clone-Updater e2up eingespielt
Der erkennt jetzt, ob er auf einer Sunray läuft oder auf einer Lonrisun.
Bei Sunray erlaubt er auch xbmc & Co. und verhindert nur Kernel-Updates;
bei Lonrisun verhindert er Kernel-Updates, entfernt xbmc und gles sofern als Abhängigkeit mitinstalliert und spielt immer wieder eine nicht crashende Enigma2-Binary ein.
- zwei Verbesserungen angewandt, bei denen ich noch nicht dazu gekommen bin, sie im git einzubauen:
- externer Streamproxy wie bei Dream statt des von OpenPLi verhunzten internen Streamings (Das ist auch für's git in der Pipeline, aber captain muß noch den streamproxy mergen
)
Das löst Probleme beim Streaming Auth und der Streamproxy kann so auch IPv6.
Im git muß es außerdem so eingebaut werden, daß es mit allen Maschinen funzt, auch denen die einen Multitranscoder auf Port 8001 mitbringen (Xtrend, Mutant, ...), sprich, da darf er nicht eingespielt werden.
- Samba startet über inetd statt als Daemon (Dadurch läuft er nur wenn er gebraucht wird und nicht ständig, außerdem unterstützt er so auch IPv6)
Hauptproblem hier ist, daß ich beim Einbauen im git erst noch einen Weg brauche, um 100% sicherzustellen, daß es auch bei Updates richtig umgesetzt wird.
Im Nachgang ersetze ich dann die Sunray-Treiber wiederum durch Lonrisun-Treiber und mache wieder ein Backup ... meine Sunray- und Lonrisun-Images entstehen also in einem Aufwasch
Der Kernunterschied ist also:
gjstroom baut das ATV-Image aus den Sourcen komplett selber, ich nehme das Originalimage.
Im Idealfall käme bei gjstroom aber auch exakt das selbe raus, muß aber nicht.
Aus zwei Gründen mag
ich ein gepatchtes Original lieber als ein selbst gebautes Image:
- Wenn gjstroom ein Image um 22 Uhr baut und der offizielle Build Server baut erst um 23 Uhr, dann sind Änderungen von 22:30 Uhr nur im offiziellen Build und umgekehrt.
Fehler und Fixes des Nachbaus und des Originals sind also nie 100% synchron, gjstrooms Build kann Fehler enthalten, die im Originalimage des selben Tages schon behoben wären, aber auch umgekehrt.
- Theoretisch kommt zwar das selbe raus, wenn man denselben Quellcode mit derselben Toolchain an verschiedenen Orten kompiliert, in der Praxis stimmt das aber nicht.
Du erhältst definitiv unterschiedliche Binaries, abhängig davon, ob Du mit Ubuntu 12 oder mit Ubuntu 10 oder Debian x,y,z baust.
Es gibt z.B. Patches im git, die werden unter Ubuntu 12 mit einer Warnung nicht eingespielt, unter Ubuntu 10 aber ohne Warnung ganz normal eingebaut. Um das Problem bei mir zu lösen habe ich bei mir z.B. den "patch" im Ubuntu aus einer alten Ubuntu-Version gezogen und vor Updates geschützt.
Umgekehrt hast Du natürlich bei gjstroom den Vorteil, daß er automatisiert ständig frisch baut, ich werde das nicht tun, weil ich zwar auch automatisiert patche, dazu aber immer erst flashen muß.
Normalerweise flasht man aber auch nicht jeden Tag neu, sondern nur wenn es notwendig ist.
Zusätzlich packe ich noch den aktuellen oscam-modern mit rein, vorkonfiguriert für Emu, die gängigen
HD+- und Sky-Karten sowie einen HS-/CS-Server.
Der ist soweit ready-2-go, einfach die Karten wie im Interface genannt einstecken und die Reader aktivieren bzw. IP/DynDNS, Benutzername und Kennwort des Servers eintragen, fertig.
Man kann natürlich auch einfach seine Configs reinhauen, wenn man schon welche hat.
Bspw. ein bereits installierter Softcam Feed wäre was schönes...
Könnte ich machen.
Allerdings solltest Du wissen, daß z.B. der oscam vom Feed oftmals Probleme mit Vu+ hat. Im normalen oscam fehlen Vu+-Patches, die im oscam-modern enthalten sind.
Da dürften die meisten User mehr davon haben, wenn sie dieselbe
oscam-Binary kriegen, die auf allen Vu+ in meinem Umfeld kampferprobt auch im Servereinsatz über Wochen durchläuft.
Das (Vu+-dauererprobt) kann der oscam vom Cam-Feed nicht leisten, weil er für alle mipsel-Maschinen gleichermaßen genutzt wird.
Last but not least ist mein oscam natürlich auch schon IPv6-tauglich
Ach ja:
Der oscam startet OpenPLi-style per SysVinit-Script, falls Dir das was sagt.
Das hat den Vorteil, daß es in identischer Weise auf wirklich allen Images funktioniert, sogar VTI.
Es ist einfach die technisch sauberste Startmethode, da sie nur Systemmittel von Linux braucht, d.h. sie funktioniert so auch auf Debian-, Ubuntu- usw. Servern und vServern und mit kleinen Abwandlungen auch auf CentOS usw..
Das Web-Interface des vorinstallierten oscam erreichst Du auf Port 8888, also
Sie müssen registriert sein, um Links zu sehen.
(Wenn Du eine eigene Config einspielst, hast Du natürlich auch wieder den Port aus Deinen Configs)
