Dreambox 900 GP4.2 suche neue Gstreamer Datei zum installieren wegen Ton Problem

[Little-Allien]

Hallo zusammen,

bei meiner DM 920 habe ich eine Datei gefunden und das Problem ist weg mit GP4.2 leider wird diese Version nicht als Erweiterung bei der DM900 erkannt.
Hat jemand eine neuere Version als 1.6.4 auf dem Nobody Feed

Danke

 

[salidos]

Es ist nicht so einfach gstreamer auszutauschen.

 

[chiefobrei]

Hast du beiden Boxen das gleiche Image installiert ?

 

[Token]

https://www.digital-eliteboard.com/resources/oe-2-5-gstreamer1-0-libav-1-6-4-r2-0.6393/download

 

[matze_1001]

Hallo

Könntest du kurz erläutern was es damit auf sich hat…..?

 

[chiefobrei]

Es gab Images, die enthielten (zu Beginn der ICAM) eine ältere gstreamer libav Version, dies hat dazu geführt, das beim Umschalten oft kein Bild oder Ton vorhanden war und man mehrmals hin und her schalten musste, bis man Bild und Ton hatte. Mittlerweile sollte auf allen Feeds die aktuelle Version verfügbar sein.

 

[cojo]

es ist bei allen Images die gleiche GStreamer , nur die bezeichnung ist teilweise eine andere, hat joye aus dem NN2 jedenfalls mal so geschrieben

 

[Token]

@cojo
ich kann zumindest hier sagen, das die "-r2.0" das Umschalt-Audio/Video-Problem etwas gemindert hat.
aber es ist halt noch nicht optimal gelöst - daher ja auch meinerseits die Anfrage an @Miese.Ratte,
ob er (s)eine icam-oscam auch für die Mipsel/ARM-Devices bereitstellen möchte.
leider konnte ich ihn noch nicht dazu überreden! ;-)

 

[Miese.Ratte]

Das wäre Voodoo! Für solche Hobbys gibt es doch schon die vielen Versionen mit Buffer und weiß der Kuckuck. Auf Mipsel- und ARM-Boxen läuft der Kram ausreichend gut. Damit kann man herum spielen bis es draußen dunkel und wieder hell wird oder gar der Winter vorbei ist ... wenn man mag.

Die Umschaltung der Sender und A/V-Dinge werden im Enigma abgehandelt. Folglich gehören diesbezügliche Experimente da hin. Das Machwerk von mir hat sich um das Enthoppeln des Logs gekümmert. Das war schließlich das spezielle Feature, welches die DM One/Two umgelegt hatte. Nicht mehr und nicht weniger.

Sorry!

 

[Token]

Das Machwerk von mir hat sich um das Enthoppeln des Logs gekümmert.

da ich aber auch die Logs der DM-Mipsel/ARM kenne, könnte man die evtl. auch auf diesen Wege "enthoppeln" ?!
vielleicht begründet das ja auch das hackelige A/V-sync. der 9xx zb. ?!
was du als "vodoo" bezeichnest, ist vielleicht eine/die Lösung für die 9xx - was ich aber nicht weis, mangels Fachwissen.

aber okay, es ist deine Entscheidung und dein Wissen, ob es Sinn macht, da mehr Zeit herein zu investieren.

 

[Miese.Ratte]

Die ARM-Kisten werden auch enthoppelt. Vor dem Gott sind sind die Receiver gleich. Die ARM-Kisten sterben aber nicht von der Randale an den Demuxen.

Die OSCam an sich kümmert sich nicht um A/V-Sync. Die schiebt nur einen entschlüsselten Stream ins E2. Das ist alles. Timestamps in den Audio- und Video-Streams für die Synchronisation interessieren die nicht. Das ist alleinige Sache des Receivers mit seiner Software. Der kann vielleicht wegen dem Randalierenden an den Demuxen aus den Tritt geraten. Aber eigentlich das hat das nicht zu passieren.

Das kann man prima mit OpenATV auf den 900ern testen. --== Laolawelle ==--

OpenATV hat eine lustige Einstellung, die Cryptinfo aus Streams zu ignorieren (Empfehlung gemäß Readme aus der allerersten Version mit Radegast). Damit kann man das Hoppeln gezielt aus und wieder anknipsen. Das liefert die Antwort, ob der Hoppelhase tatsächlich A/V aus den Sync bringt. Ich sage mal ganz frech: Nö!

 

[Token]

hmm, also liegt das A/V-Prob. alleinig am DreamOS? ... mist, dann hat man ja verloren - weil ja EOL.
ah okay, cryptinfo auf dem OATV habe ich mal angeschaut - und Nö! - es bringt den Hoppelhasen nicht aus dem Tritt.
(also wäre es nur ein "wegblenden fürs Auge" sozusagen ?!)

 

[Token]

@Miese.Ratte
ich würde gern das Thema DM9x0/arm und "kein Bild/Ton beim umschalten" gern mit Dir nochmal besprechen wollen.
was ist bereits bekannt:
1. bei einer non-icam-oscam tritt das Problem nicht auf
2. es tritt bei Open* und dreamOS auf, in Kombi mit einer icam-oscam
3. versch. Massnahmen wie buffer_v3, demuxer-fix, neon on/off, brachten bisher nicht die erwünschten/nachhaltigen Effekte
4. konkret nachvollziehbar ist es zZ. beim wechsel zw. HD+ und S*y (e.g. RTL/Pro7 und D***n 1/2)
wo könnte man denn noch ansetzen - nach 2. und 3. bin ich immernoch der Meinung, das das icam selber noch nicht sauber auf der DM9x0 arbeitet ?!
da du Zugriff auf die Sourcen der originalen icam-oscam hast, wäre es vielleicht für dich als Code-versteher möglich, da nochmal reinzuschauen ?!
oder eben mal eine ARM-Kopie deiner One/Two-Lösung mal intern zu testen, ob das wirklich am Reverse des icam und dessen Umsetzung liegt ?!
das würde zumindest klären, ob/wo man evtl. zur Fehlersuche ansetzen müsste! ... wenn es mit den original Sourcen bei dir läuft, dann liegt's am public-iCam! ;-)
Danke im voraus!

 

[ultima]

Nutzt ihr ein Dreamos Image mit GP 4.2 Erweiterung?

 

[Token]

@ultima
jein, ich verwende das dreamOS Image vom Ihad, mit deinstallierten GP4 ... aber letzteres ist nicht das Problem.
(es tritt ja auch im Open* auf ... ist also Image/GP4-unabhängig!)