Aktuelles
Digital Eliteboard - Das Digitale Technik Forum

Registriere dich noch heute kostenlos, um Mitglied zu werden! Sobald du angemeldet bist, kannst du auf unserer Seite aktiv teilnehmen, indem du deine eigenen Themen und Beiträge erstellst und dich über deinen eigenen Posteingang mit anderen Mitgliedern unterhalten kannst! Zudem bekommst du Zutritt zu Bereichen, welche für Gäste verwehrt bleiben

Registriere dich noch heute kostenlos, um Mitglied zu werden! Sobald du angemeldet bist, kannst du auf unserer Seite aktiv teilnehmen, indem du deine eigenen Themen und Beiträge erstellst und dich über deinen eigenen Posteingang mit anderen Mitgliedern unterhalten kannst! Zudem bekommst du Zutritt zu Bereichen, welche für Gäste verwehrt bleiben

ICAM Patch oscam-emu

Status
Für weitere Antworten geschlossen.
Dann wird es wohl Zeit mal das Image neu zu machen, danke euch für eure Hilfe. Werde dann wohl auf OPENATV gehen, da gibt es wenigstens auch noch Updates.

Edit:
Über die Console ist es wohl besser.
Erster Screenshot mit icam, der zweite mit hd+

Du musst Regestriert sein, um das angehängte Bild zusehen.



Du musst Regestriert sein, um das angehängte Bild zusehen.
 

Anhänge

Du musst angemeldet sein, um die Anhangsliste zu sehen.
Zuletzt bearbeitet:
Ich habe mal eine Frage an die Linux Experten. Bei Windows (DVBViewer) gibt es jetzt eine einfache Lösung nur durch Austausch einer einzigen Bibliothek (ffdecsa.dll) wird Sky hell.
Keine besondere Oscam, kein Streamrelays kein Oscam Patch kein Radegast keine extra Senderliste erforderlich. Super Umschaltzeiten und keine Tunerblockierung . Bei Tvheaded wird es genauso gemacht. Könnte man diesen Ansatz auch für Enigma verfolgen ?
Ja es ist möglich die Benutzung von Oscam ohne Streamrelay oder radgast. nur oscam-svn trunk modifizieren mit Beachtung an nicht open source Module oder patch, die ändrung solte uns noch +12 Jahren zurück an Video_lan " libdvbcsa "
 
Hmm, geht das etwas genauer?
 
Zuletzt bearbeitet von einem Moderator:
Den versteht hier sowieso niemand. Kannst du ignorieren. Der Translator funktioniert nicht.
 
icb hat dazu doch schon die Antwort gegeben.
@Volker4123686 Problem ist, dass e2 keine Entschlüsselung vornimmt. Das macht die Hardware, die von Oscam mit den Codewords gefüttert wird. DVBViewer kümmert sich selber um die Entschlüsselung und ist so gebaut worden. Theoretisch kann man e2 anpassen. Ist aber nicht so einfach. UND geht nicht bei VTi, Dream.
Selbst wenn man e2 anpassen würde, würde es immer noch eine "softwaretechnische Entschlüsselung" bleiben da die Receiver eben nur CSA per Hardware können. Da haben wir genau das gleiche Problem wie jetzt, die Entschlüsselung benötigt Leistung. TVH entschlüsselt ja auch alles nur per Software emulation. Meistens ist die Hardware auf der TVH läuft performanter und man hat Leistungstechnisch keine Probleme. Somit sind trotzdem alle zu schwachen Receiver dafür immer noch nicht geeignet. Es würde zwar das ganze Gedöns mit der angepassten Senderliste usw. weg fallen, es wäre aber einfach nur ein anderer Weg zum entschlüsseln der aber immer noch über Software abgewickelt wird. Ob der ICAM Descrambler nun per Software in Streamrelay oder über ein angepasstest e2 emuliert wird spielt ja eigentlich keine Rolle. Vielleicht läuft eine Emulation/Implementierung vielleicht ein bisschen performanter, aber da wird sicher nicht so ein gravierender Unterschied sein das auf einmal alle alten Receiver mit ICAM laufen.
So zumindest mein Verständnis wenn ich das richtig geblickt habe.
 
Zuletzt bearbeitet:
So habe ich das auch immer verstanden. Einziger Parameter um die CPU Last zu verringern wäre somit eine codeseitige Optimierung des Entschlüsselungsvorgangs. Und da gibt es ja schon Fortschritte mit .... --> V7 --> V8
 
Zuletzt bearbeitet von einem Moderator:
Also wenn ich mir den Patch für die libdvbcsa ansehe, scheint das nicht super aufwändig zu sein.
Und das laufende tvheadend Binary zeigt für mich keine nennenswerte erhöhte Last im Betrieb. Klar, die CPU ist viel stärker als die im Receiver. Aber ich denke, da ist noch Luft drin.
Den Traffic zwischen den Prozessen via http hin- und her zu schicken gibt es auch nicht für umme.
 
Wie gesagt unter enigma2 läufts astrein...
Ja nee danke trotzdem, aber für oscam unter e2 brauch ich keine Hilfe... bin selbst über 20 Jahre schon in dieser Szene xD

Mir geht's nur um Neutrino mit Ni Image und oscam mit icam

Ja bitte einer, der Neutrino mit icam auf ner duo4k laufen hat
Hallo zusammen,
Erst einmal möchte ich mich für die gesamte Korrespondenz und das informative Testen und voran bringen bei allen beiteligten bedanken.
Es macht spass hier täglich vorbei zu schauen und sich mit dem Thema auf dieser Plattform aktiv auseinander zu setzen.

Ich habe eine Frage, wenn diese mir gestattet ist.
Gibt es zu dem o.g Beitrag einen Lösungsansatz?

Ich habe genau das gleiche Problem. Unter E2 läuft es nahezu fehlerfrei, Könnte es an der OScam Version liegen?
Hat jemand evtl eine aktuelle OScam Version die Neutrino NI (ARM/VUPlus4KunoSE) tauglich ist?

Suchfunktion genutzt, leider wenig brauchbares dazu gefunden.
Danke R
 
Also wenn ich mir den Patch für die libdvbcsa ansehe, scheint das nicht super aufwändig zu sein.
Und das laufende tvheadend Binary zeigt für mich keine nennenswerte erhöhte Last im Betrieb. Klar, die CPU ist viel stärker als die im Receiver. Aber ich denke, da ist noch Luft drin.
Den Traffic zwischen den Prozessen via http hin- und her zu schicken gibt es auch nicht für umme.
Ich kann da leider nicht viel mehr zu sage weil mir da das know how fehlt. Wollte nur sagen das es immer eine "Software Entschlüsselung" bleibt. Ob und wie viel "Last" das Abrufen und Bereitstellen der Streams über HTTP verursacht und ob eine implementierung direkt in e2 mehr Sinn ergeben würde kann ich nicht sagen.
Wie war das denn noch mit der ersten Zgemma closed Image ICAM Lösung? War da nicht laut Forum hier die e2 Binary verändert/angepasst worden? Vielleicht können Interessierte da etwas "reverse engineeren". Denke aber, dass das Interesse da eher gering ist und auch einen riesen Aufwand mit sich bringt. Die Open Images Devs werden da wohl auch kein allzu großes Interesse haben. Die jetzige Lösung funktioniert ja schon super und es wird aktiv dran gearbeitet danke @icb . Riesen Respekt an dieser Stelle übrigens nochmal dafür.
Wäre bestimmt eine interessante Sache zu sehen wie und ob das gut funktionieren könnte/kann und vielleicht eine Verbesserung zur jetzigen Entschlüsselung zu sehen wäre. Ich bin da aber mangels coding skills usw. komplett raus.
 
Das v8 gepatchte binary für die One/Two liegt doch hier von @icb

Nach meine tests, ist da weiterhin die v6 das bessere Wahl.
v8 hat ein Problem das Sender dunkel bleiben beim Zappen innerhalb der Sky Senderliste, und wenn man nicht zappt, irgendwann die Box komplett hängt.

Natürlich würde es mir auch freuen von andere User ihre Erfahrungen damit zur mitteilen.
 
Zuletzt bearbeitet:
Also wenn ich mir den Patch für die libdvbcsa ansehe, scheint das nicht super aufwändig zu sein.
Und das laufende tvheadend Binary zeigt für mich keine nennenswerte erhöhte Last im Betrieb. Klar, die CPU ist viel stärker als die im Receiver. Aber ich denke, da ist noch Luft drin.
Den Traffic zwischen den Prozessen via http hin- und her zu schicken gibt es auch nicht für umme.

Die CSA und ICAM Verschlüsselung unterscheiden sich nur in einer Kleinigkeit. Deswegen erzeugen die auch die gleiche Last. Bei tvheadend ist das nichts neues, da dort die Entschlüsselung immer in Software lief. Auf den E2 Boxen lief die aber immer in der Hardware ab. Jetzt muss sie in der Software ablaufen und einigen Boxen geht dabei die Luft aus.

Ich kann nicht abschätzen wie viel CPU Last das hin und herschieben des Streams (E2 -> Oscam -> E2) verursacht. Das geht ja bis auf Netzwerkebene runter. Also super wenig wird das nicht sein. Aber ob die langsamen Boxen, wenn man das weglassen würde, problemlos mit der Entschlüsselung klar kommen, würde ich schon bezweifeln. Aber nur ein Test könnte es zeigen.
Vielleicht findet sich ja ein e2 Entwickler, der sich das mal anschaut...
 
Man kann schlecht von einem Esel, ein Renn Pferd machen.
So was es immer in Computer leben.
Man holt sich lieber sofort RennPferd,und passt die Klienten an.
Ist halt die Frage,wie lange es gut geht mit diese Lösung und Sky.
 
Ich habe hier eine typische MIPS-Box (irgendwas Edision) mit 750 MHz (BMIPS 4380). Diese CPU dürfte sehr verbreitet sein.
Auf F1 sehe ich eine Last für den oscam-Prozess bei 80-90%. Die CPU hat zwei Cores, also in Summe 200% vorhanden. enigma2 (und der Rest) liegen bei weiteren 20%. Ein Core wäre also überlastet.
Bei Sachen aus dem Film-Bouquet liegt oscam hingegen bei 20-30%. enigma2 vielleicht noch bei 5%. Die Daten intern zu streamen kostet also in jedem Fall CPU-Zeit, das kann man am enigma2-Prozess sehen, der mit der hohen Datenrate ansteigt.
Die gute Nachricht ist hingegen, dass selbst die höheren Bitraten auf MIPS-Boxen gut zurecht kommen.

Edit:
Ich habe mal ein bisschen geschaut, wie man die CPU-Leistung der Box mit anderen Systemen vergleichen kann.
7zip hat einen Benchmark integriert, um die Leistungsfähigkeit zu testen.

Hier mal der grobe Vergleich (alle single-threaded via 7z b -mmt1):
Ryzen 4300GE: 3337 MIPS bei Compression
BMIPS: 217 MIPS bei Compression

Also Faktor 15.

Netter Seiteneffekt: Die Box lief für ein paar Minuten bei 98% für den 7z-Prozess. Irgendwann ist die Box abgeschmiert. Das deutet schon klar auf ein Hitzeproblem hin. Vermutlich ist die Kühlung für diese dauerhaften Stress nicht ausgelegt.
 
Zuletzt bearbeitet:
Zwei Vorschläge:
Github Repository für den ICAM-Patch anlegen. So können Optimierungen des Algorithmus von vielen Menschen eingebracht werden.
Einen Thread erstellen, in dem Besitzer von MIPSEL-Receivern ihre Geräte öffnen und Bilder vom Innenleben hochladen. Dann wird gemeinsam ausprobiert, ob man mit günstigen Kühlkörpern, Wärmeleitpads usw. deren Hitzetoleranz erhöhen kann.
 
Status
Für weitere Antworten geschlossen.
Zurück
Oben