Hallo .
Also meine V13 Karte sollte gehen.
Transcoding
Streaming vom Nas SPRICH mkv, avi's dts tonformat
Wie sieht es mit Xbmc aus?
WOL
HBBTV
HDMI -IN mit Aufnahmefunktion?
Hallo .
Also meine V13 Karte sollte gehen.
Transcoding
Streaming vom Nas SPRICH mkv, avi's dts tonformat
Wie sieht es mit Xbmc aus?
WOL
HBBTV
HDMI -IN mit Aufnahmefunktion?
naja, du bekommst eine box mit einem betriebssystem, das vom hersteller weiter entwickelt wird. die hersteller deiner aufgeführten box haben sich lediglich alte software genommen und machen nur das notwendigste, damit diese alte software auf ihren boxen läuft und hofft, das die comunity ihre boxen aufpeppt ...
Würde heissen das wäre bei Einer Dreambox anders?
Da ich ja jetzt meine Anforderungen genannt habe .
Ist das alles realisierbar?
.
Und danke für die Ausführliche Antwort
Zitat
Also meine V13 Karte sollte gehen.
verstösst gegen die boardregeln, aber ja
Zitat
Transcoding
die hardware kann es. es ist aber diesbezüglich noch nichts implementiert
Zitat
Streaming vom Nas SPRICH mkv, avi's dts tonformat
das geht auch schon jetzt mit ner dreambox
Zitat
Wie sieht es mit Xbmc aus?
was hat das auf ner dream zu suchen? es gibt auf der 7080 eine medienverwaltung
Zitat
WOL
ka, ob das gehen wird. da muss ja auch die hardware mitspielen und netzwerk ist m.w. im SoC integriert
Zitat
HBBTV
geht auch schon jetzt auf ner dream
Zitat
HDMI -IN mit Aufnahmefunktion?
z.z. noch ohne funktion. soll aber was kommen
Ok Danke dir für deine Antworten.
2 Punkte die für mich jetzt nicht zufriedenstellend sind
.
Aber wenn da was kommen soll das wäre Klasse.
Und da ich jetzt auch eine gute Beratung hatte denke ich wird eine werden
Habe jetzt erstmal was ich wissen wollte .
wo kann man die Dreambox bestellen?
Gibt's da ein Board Sponsor oder ähnliches
Den ihr empfehlen würdet?
Euch noch einen schönen Abend.
Danke
[...]Fairerwaise sollte man potentielle Kaufinteressenten darauf hinweisen, dass die meisten Enigma2 Plugins nicht mehr auf der 7080 laufen werden.
Das stimmt doch gar nicht, was Du da schreibst!
Alle Open Source Plugins kann man innerhalb weniger Minuten anpassen.
Für das SerienRecorder Plugin hab ich keine 10 Minuten benötigt ohne den Souren Code vorher schon mal gesehen zu haben. Das gleiche gilt für das LCDPlugin.
Wenn jetzt Deine Closed Source Plugins nicht auf der 7080 gehen werden wird das rein an Dir liegen, an niemanden sonst.
Das solltest Du fairerweise den Leute sagen
Das stimmt doch gar nicht, was Du da schreibst!
.....
Wenn jetzt Deine Closed Source Plugins nicht auf der 7080 gehen werden wird das rein an Dir liegen, an niemanden sonst.
Das solltest Du fairerweise den Leute sagen
+1
Die anderen sind immer schuld.
Obwohl ich keine Closed Source Plugins brauche und nie welche bei mir installieren werde
Diese Wichtigtuerei nervt einfach. Entweder man stellt seine Plugins der Community zur Verfügung, oder man lässt es sein.
LG
ePicLoad muss auch angepasst werden.
Danke für die Info. Das bestätigt meinen Verdacht, dass es mehr Änderungen gab und wer weiß, welche Funktionen noch betroffen sind.
Warum gibt es seitens DMM keine offizielle Info für die Plugin Entwickler, was sich alles wie geändert hat? Das wäre sicher kein großer Aufwand für DMM für alle das Einfachste. Rätselraten welche Funktionen betroffen sein könnten macht nicht viel Sinn, erst Recht nicht, wenn man die Funktionen gar nicht testen kann.
Das stimmt doch gar nicht, was Du da schreibst!
Naja, wenn das stimmt, was ich hier gelesen habe, werden alle meine Plugins nicht mehr laufen und ich bin sicher nicht der einzige, der eTimer, eConsole, ePicLoad & Unbekannt in seinen Plugins benutzt. Aber das ist natürlich alles meine Schuld, schon klar
Wenn Du einen verallgemeinerten Satz wie "die meisten Plugins werden nicht mehr laufen" von Dir gibst, dann stimmt das halt einfach nicht. Alle können sehr schnell und vollkommen unkompliziert angepasst werden.
Aber egal, was kümmert es mich eigentlich...wenn wir jetzt schon bei angeblichen Schuldzuweisungen sind, die ich ja wohl ausgesprochen haben soll , wirds mir dann doch zu mühsam hier mit Dir...schon klar!
Sorry, aber statt rummotzen könntest du wirklich machen, was ich dir geschrieben hab: schwerkraft anschauen, was geändert wurde und die neue enigma.py.
Aber letztlich ist alles eine frage des willens und wenn der nicht vorhanden ist, dann ist das nun mal so. Dann aber bitte auch nicht motzen.
Sorry, aber statt rummotzen könntest du wirklich machen, was ich dir geschrieben hab: schwerkraft anschauen, was geändert wurde und die neue enigma.py.
Aber letztlich ist alles eine frage des willens und wenn der nicht vorhanden ist, dann ist das nun mal so. Dann aber bitte auch nicht motzen.
Naja, die Frage nach offiziellen APIs, Changelogs etc. finde ich nun nicht gemotze, sondern eigentlich eine Selbstverständlichkeit.
Wenn Du einen verallgemeinerten Satz wie "die meisten Plugins werden nicht mehr laufen" von Dir gibst, dann stimmt das halt einfach nicht. Alle können sehr schnell und vollkommen unkompliziert angepasst werden.
Nur wird das nicht jeder können.
Zudem werden viele Plugins auch in Zukunft auf OE2.0 entwickelt, da die Mehrheit aller Boxen auf dem Markt nun mal oe2.0 nutzen.
Wird wohl eher die Zeit zeigen, ob oe2.2 wirklich der richtige Schritt (für die Käufer) war.
Gibt es eigentlich schon genau Aussagen, ob nur DVB-S Versionen verkauft werden oder auch Boxen mit 2 DVB-C Tunern?
da braucht man nur mal in einen Shop schauen, 2xDVB-S2 + 2xDVB-C/T = einen Hunni mehr.
Wenn Du einen verallgemeinerten Satz wie "die meisten Plugins werden nicht mehr laufen" von Dir gibst, dann stimmt das halt einfach nicht.
Die meisten Enigma2 Plugins benutzen einen eTimer und damit laufen diese Plugins per se nicht auf der neuen Box. Was ist daran unwahr?
Alle können sehr schnell und vollkommen unkompliziert angepasst werden.
Eben nicht - alleine schon weil anscheinend niemand weiß, was sich alles geändert hat. Wenn nur ein eTimer in einem Plugin geändert werden muss, mag das schnell und unkompliziert gehen. Wenn ein Plugin 50 eTimer hat, die alle einen anderen Namen haben, kann man da auch mit Suchen/Ersetzen nicht eben mal schnell den Code anpassen. Und es ist sicher nicht unkompliziert, diverse Schwerkraft Plugins und einige Tausend Zeilen enigma.py Code nach einer Funktion oder ein Modul zu durchsuchen, um festzustellen, ob dieses nun geändert wurde oder durch ein anderes ersetzt wurde oder vielleicht auch komplett weggefallen ist. DMM mag ja nur ein kleines IT-Unternehmen zu sein und vermutlich nicht nach ITIL oder anderen Standards zu arbeiten , aber wenn man ein OS wechselt, wird es auch Dokus geben, was wie geändert wurde und wo ist das Problem diese Infos an die Plugin Entwickler weiterzugeben?
Naja, die Frage nach offiziellen APIs, Changelogs etc. finde ich nun nicht gemotze, sondern eigentlich eine Selbstverständlichkeit.
Wenigstens einer der mich versteht. Aber wenn die Argumente hier ausgehen, wird man gerne auch mal persönlich.
Sorry, die WENIGSTEN plugins verwenden einen eTimer. Und deine aussagen zum aufwand der anpassung zeigen, dass du nicht einen der commits von ghost auf schwerkraft angeschaut hast.
Hier mal ein beispiel für die anpassung bei eTimer:
also das handling der gesammten PSignals hat sich geändert.
das betrifft dann auch die eTimer.
Also anstelle dieser signal.get().append(self.func) .. und wenn man den timer nicht mehr braucht .get().remove(self.func) ...
Haben nun alle signals.. sei es eTimer... oder picload eine "connect" methode. Dieser bekommt beim Aufruf den namen der function/methode
Wichtig ist nun, dass die connect function ein object zurücklierfert. Ein sog. Connection object. Solange dieses Objekt existiert besteht der callback.
Sprich man macht nun z.b. self.timer_conn = self.timer.connect(self.timerFunc)
self.timer.start(1000, False)
Nun wird self.timerFunc jede sekunde immer wieder aufgerufen.
Das alte self.timer.callback.remove(self.timerFunc) ... gibt es so nicht mehr.. und auch bei anderen signals das .get().remove(self.timerFunc) nicht mehr.
Dieses erreicht man nun durch zerstören des connection objekts. Also self.timer_conn = None oder del self.timer_conn
Wichtig ist also, dass dieses connection Objekt irgendwo gespeichert wird, wo es nach Aufruf der Funktion in der es erzeugt wurde nicht verloren geht. Also innerhalb von Objekten also am besten immer self.bla_conn = .. aber für jeden timer ein eigenes.
Man könnte die connection objekte aber auch in eine liste packen wenn man nicht so viele self.xyz_conn obekte haben will. Alles ist möglich.
Im grossen und ganzen wars das auch eigentlich schon.
Ansonsten hat sich im ePicload die startDecode und getThumbnail methode geändert. Diese hatten im 4.0 e2 4 Parameter .. wobei die letzten 3 optional waren. (Filename, x, y, async) ... x und y sind nun weggefallen.
cu
kashmir
Wenn Du die Crashlogs liest, siehst Du SOFORT wo es crasht.
Wenn Du dann Dir die Plugins auf Schwerkraft ansiehst, brauchst Du den betreffenden Code fast immer nur zu kopieren.
Ich bin mir sicher, dass Dir Notfalls die User den Code anpassen
Vorausgesetzt Du lieferst die Py's mit. Denn mittlerweile dürften fast alle verstanden haben, dass es eine Kleinigkeit ist.
Statt Deine Energie verbal loszulassen und immer wieder drauf abzufahren, wenn man Dir aufzeigt, dass es ganz einfach geht, wäre nur ein Bruchteil der Energie nötig gewesen Deine Plugins anzupassen. 3-5min pro Plugin!
Und nun hat Dir das ganze auch nochmal Ghost bestätigt. Vielleicht hilft es ja, dass Du nun nicht mehr allen anderen widersprichst.