ICAM Patch oscam-emu

[el_malto]

Ich nutze die PCR Werte zum berechnen, wieviel Zeit an Packets wir gebuffert haben. PCR tickt 90.000*300 = 27.000.000 mal pro Sekunde oder 27.000 mal pro Millisekunde.

Zudem werden nur Packets nach dem ersten entschlüsselten Packet mit Random Access Indicator (RAI) Flag berücksichtigt, da der Decoder sonst evtl. Packets einfach skipped und der Buffer damit für die Katz wäre. So meine Überlegung. RAI Packets kommen spätestens alle zwei Sekunden.

Habe mir gerade nochmal deine alten Beiträge durchgelesen um das irgendwie besser nachvollziehen zu können. Aber bin da überhaupt nicht in der Materie was das angeht.
Aber nochmal ganz "grob" gedacht:
Es ist doch worklich nur ein timing Problem zwischen Streamrelay und dem "Player". Alle Aufnahmen funktionieren ja ohne Fehler. Somit funktioniert das entschlüsseln usw. ja richtig. Ist es dann sinnvoll das so "kompliziert" zu machen und das Rechnen mit den ganzen Daten o.ä. aus dem TS Stream? Eigentlich müsste der Stream doch "nur" für n Milisekunden "zurückgehalten" werden und nicht in Streamrelay gecheckt werden ob ein Paket nicht scrambled wurde usw. Oder verstehe ich da was nicht ganz?

 

[ChrisOsgood]

Danke für den Patch, das funktioniert sehr gut.

Aber im Grunde habe ich die selben Probleme wenn ich einen Stream von einer anderen E2- Box im Homenet starte, die kurzen Aussetzer die erste Minute treten da auch auf, egal ob der Kanal entschlüsselt werden muss oder nicht... vielleicht eher ein Problem von E2 als von Oscam/ Streamrelay?

 

[Token]

@ChrisOsgood
also wenn dein Problem auch bei nicht codierten Stream's auftritt,
dann ist es eher kein Oscam/Streamrelay-Problem.
da würde ich eher auf den Gstreamer/player tippen.

 

[Drachentöter]

Der Buffer Patch scheint sich auch positiv auf andere Architekturen auszuwirken. Ich war mal so frei, und habe das testweise mit in die Oscam für meine dream one gepatcht.
Fazit: Bild und Ton sind beim Umschalten immer da!
Vorher gab es bei mir noch Probleme, dass gelegentlich ein Icam-Sender dunkel blieb nach dem Umschalten. Dies ist mir bisher noch nicht wieder aufgefallen.
Den Buffer hatte ich zuerst auf 2500 ms gelassen, dann auf 1250 ms gesetzt. Beides läuft gut und mit der Umschaltzeit kann ich leben, denn das Resultat kann sich sehen lassen!
Das Einfrieren bzw. Hämmern lässt bisher auch noch auf sich warten, es läuft hier bereits durchgehend seit ca. 5 Stunden. Aber ich möchte den Tag mal lieber nicht vor dem Abend loben ...


Vielen Dank an @putschi !

Anbei beide Versionen für die One / Two zum Testen

Edit:
So, nach ca 11 Stunden war es meiner Box dann zu viel und hat sich aufgehängt.
Dennoch bin ich mit dem Ergebnis zufrieden.

 

[dogfight76]

Wird es die Version mit buffer auch als fertige ipk für VTI und VU+ ARM-CPU geben ?


Gesendet von iPhone mit Tapatalk Pro

 

[Token]

ihr wisst aber schon, das @putschi das ganze lediglich erstmal als ProofOfConcept veröffentlicht hat ?!
insofern macht das verteilen von Binaries da noch keinen Sinn.

@Drachentöter
d.h. mit 1250ms hast du auf der One noch passable Umschaltzeiten?
... ich frage, weil es bei @el_malto seiner Box etwa 3-4sek waren (VU+ Uno4K SE).
das audio-hämmern dürfte/sollte unabhängig davon auftreten, weil es ja eigentlich vmtl. ein ALSA-problem ist.
aber das tritt hier sporadisch auf, entweder mehrfach pro Tag - oder auch mal einige Wochen garnicht.
P.S.:
deine Oscam's starten auf meiner One mit AIO übrigens, aber das komplette icam bleibt dunkel.

 

[Leo888]

Vorher gab es bei mir noch Probleme, dass gelegentlich ein Icam-Sender dunkel blieb nach dem Umschalten.

Sehr seltsam, da genau die one und die two dieses Problem eh nicht haben. Ich habe die two jetzt schon länger und bis jetzt noch nie ein Bild/Ton Problem gehabt.

 

[Drachentöter]

Ich kann da nur für meine Box sprechen, und da trat das Problem definitiv häufig auf.

@Token :
Es sind ca. 2 Sekunden Umschaltzeit bei 1250 ms. Manchmal auch etwas schneller.
Die Binaries von mir sind auch nur zum Testen gedacht.
PS:Hier läuft es auf Newnigma2.
Eventuell die Box einmal neu starten?

 

[Token]

ich habe hier das IHAD-Img. am Start ... naja, ich werde es dann nochmal probieren.

 

[Leo888]

PS:Hier läuft es auf Newnigma2.

Liegt vielleicht auch am Image, bei mir läuft original AIO und da tritt das nicht auf.

 

[Drachentöter]

Möglich. Aber da ich das AIO bisher noch nicht ausprobiert habe kann ich das für meine Box nicht bestätigen

 

[DarkStarXxX]

Ist zwar OT, aber macht auch keinen Sinn mehr auf das AIO zu wechseln, da nichts mehr Weiterentwickelt wird.
Man sollte bei einen Image bleiben was wenigstens noch Supported wird nachdem DMM Geschlossen wurde.

 

[Leo888]

Jepp OT, aber das ist schlicht nicht nachzuvollziehen wie man auf so eine Meinung kommt.
Für AIO wird derzeit mehr nachgereicht als für die Images davor, denn da ist auf alle Fälle Schluss, ob NN2 mehr machen kann, glaub ich auch nicht und dann immer noch, ich habe die Probleme mit dem AIO nicht. Zumal einige Verbesserungen die nie ins normale 2.6 eingeflossen sind, sind eben im AIO mit drin, somit müsstest das alte 2.6 erst mal auf einen vergleichbaren Stand wie das AIO bringen.
Das war übrigens auch ein riesen Fehler von DP (DMM ist lang her), dass sie zuerst die HW mit der alten SW auf den Markt gebracht hatten, die Boxen hatten so keinen wirklichen Mehrwert als die DM9x0, eher schlechter, da kein FCB Tuner verfügbar

 

[Token]

@DarkStarXxX
... also dann doch das AIO ;-)

@Drachentöter
so, deine "Oscam.1250" läuft erstmal auf dem AIO.

 

[DarkStarXxX]

Wer soll das weiterentwicklen? DMM ist weg vom Fenster. Und ohne DMM kein Sourcecode.

Aber das ist hier wirklich zu OT.