Jump to content

Octopus Net


Recommended Posts

Hmm mit dem Dauerbetrieb diverser CAM an DD-Hardware gab es ja schon öfters Probleme.

Könnte auch sein, dass das CI/CAM gar nicht mehr ansprechbar war?

Wie prüft man das mit der Octopus?

Ich benutze nach wie vor ein Alphacrypt light (ohne den bekannte Fehler den wir mal besprochen hatten). Dieses lief mit einer S02 Karte 5 Jahre ohne zu mucken im Dauerbvetrieb in meiner TT3650. Kann mir beim besten Willen nicht vorstellen, daß diese Teile jetzt daran schuld sein sollten.

Link to comment

@duddsig: Tritt das Problem bei der Umschaltung unverschlüsselt -> verschlüsselt auch mit der Einstellung CI #1 auf?

 

@Boris Müller: Das von dir beschriebene "Stottern" beim DVBViewer GE wurde schon von anderer Seite im Zusammenhang mit dem Recording Service berichtet. Die Symptome stimmen überein. Da es bei den meisten glatt läuft, nehme ich an, dass es sich um individuelle Probleme bei der Pufferung im Socket (der Windows-Netzwerkbasis) handelt, was wiederum mit Netzwerktreibern zusammenhängen könnte.

 

Deshalb für dich im Mitgliederbereich, Beta-Sektion, eine Testversion DVBViewer GE 3.4.3.1, die zusätzlich selbst puffert (was der DVBViewer Pro auch macht, aber es war fraglich, ob das nötig ist). Wir werden sehen...

 

Nochmal: Kannst du das Umschalt-Problem von duddsig nachvollziehen?

  • Like 1
Link to comment

s. http://www.DVBViewer.tv/forum/topic/43157-ci-reset-skript/

Gab es auch mal ein Firmware Update fürs Alphacrypt (light) wegen der Problematik.

Welche hast du drauf?

 

P.S. Trat mit meiner FireDTV (&alphacrypt light) auch nie auf!

Ja, auch meine FireDTV funktionierte mit dem Modul einwandfrei, und auch dieTBS 5980 funktionierte, produzierte allerdings auf einigen Services ab und an Streamfehler wenn das AC gesteckt war.

Da hier alles funktionierte habe ich keine Veranlassung gesehen an der Firmware rumzufummeln. Ich würde meinen, daß daß da die 1.18 rumwerkelt.

Link to comment

@duddsig: Tritt das Problem bei der Umschaltung unverschlüsselt -> verschlüsselt auch mit der Einstellung CI #1 auf?

Ja, da tritt es auch auf.

 

Werde jetzt noch mal mit Transedit testen, nob das da auch so ist.

Link to comment

Werde jetzt noch mal mit Transedit testen, nob das da auch so ist.

 

Auch mit TransEdit besteht dieses Problem. Ich konnte aber zusätzlich noch feststellen, das dieses nur bei Transponderwechsel auftritt. Habe auf dem Skytransponder 12032H "Skyselect FTA" finden können. Zwischen diesem und den verschlüsselten kann ich munter hin- und herzappen, auch mit der GE. Wenn ich von einem ARD-Transponder z.B. 10744H zu dem Sky-Kollegen zappe bleibt es in jedem Fall dunkel.

Link to comment

Deshalb für dich im Mitgliederbereich, Beta-Sektion, eine Testversion DVBViewer GE 3.4.3.1, die zusätzlich selbst puffert (was der DVBViewer Pro auch macht, aber es war fraglich, ob das nötig ist). Wir werden sehen...

 

Nochmal: Kannst du das Umschalt-Problem von duddsig nachvollziehen?

 

Ich habe gerade die Version getested. Problem besteht immer noch. Im DVBViewer Pro funktioniert es einwandfrei (natürlich bis auf die CI-Unterstützung)

Link to comment
Im DVBViewer Pro funktioniert es einwandfrei (natürlich bis auf die CI-Unterstützung)

 

@Boris Müller: Wie sieht es im DVBViewer GE aus, wenn du das RTSP-Gerät für "Kein CI" konfigurierst? Vom Code her dürfte es eigentlich keinen wesentlichen Unterschied zur Pro geben.

Link to comment

@duddsig: Für dich gibt es auch eine Testversion 3.4.3.2 im Mitgliederbereich, Beta Sektion. Nur mal auf Verdacht... irgendein Unterschied?

Nein leider kein Unterschied. Getestet mit beliebigem CI und #1. Ich befürchte, daß die Box hier der Verursacher ist. Wenn ich den gleichen Sender noch mals klicke, wird entschlüsselt. Wenn ich mit 2 RTSP Geräten arbeite und Sendergruppen benutze, wird entschlüsselt. Wenn ich den Transponder nicht wechsle, wird ebenfalls entschlüsselt.

Hm, und im Dauerbetrieb bleibt das Dingens auch noch hängen, was noch viel schlimmer ist :( .

Link to comment

@duddsig: Danke erst mal für die Tests. Sieht so aus, als müsse DD nachbessern. Ich werde deine Erfahrungen melden, weiß aber nicht, ob dort jemand zwischen Weihnachten und Neujahr aktiv ist. Also abwarten...

Link to comment

@duddsig: Danke erst mal für die Tests. Sieht so aus, als müsse DD nachbessern. Ich werde deine Erfahrungen melden, weiß aber nicht, ob dort jemand zwischen Weihnachten und Neujahr aktiv ist. Also abwarten...

Nichts zu danken, mach ich doch gerne.

 

Wünschenswert wäre es aber auch noch, wenn man bei der Auswahl eines RTSP Gerätes direkt einen einzelnen Tuner des OctopusNet zuweisen könnte

 

 

Geht per FrontEnd-Tweak in der Setup.ini. Entsprechend auch in der TransEdit.ini. Wenn es wichtig ist / häufig gebraucht wird (warum?), könnte es eventuell noch einen Platz im UI finden.

Da wäre ich auch dran interessiert, ich hatte ja schon mal geschieben, daß ich über Sendergruppen Tuner#4 dem 2. Ausgang meiner drehbaren zuordnen würde. Wenn das machbar wäre wäre es natürlich sehr schön, vor allem dann auch in der Pro.

Link to comment

 

@Boris Müller: Wie sieht es im DVBViewer GE aus, wenn du das RTSP-Gerät für "Kein CI" konfigurierst? Vom Code her dürfte es eigentlich keinen wesentlichen Unterschied zur Pro geben.

 

Habe ich gerade ausprobiert. Keine Besserung. Habe auch mal verschiedene Codecs ausprobiert. immer das selbe. Und wie gesagt der DVBViewer Pro auf der selben Maschine läuft einwandfrei.

Link to comment

Der Fehler "Graph too late" lässt sich unterdrücken, indem man auf der Eigenschaftsseite des DVBViewer Filters den Wert für Max. Queued Audio (TV/Radio) auf 0 setzt -> Übernehmen -> Sender wechseln. Hilft das irgendwie? Gibt es weiter Diskontinuitäten, oder hören die irgendwann auf?

 

Es muss irgendwas spezielles bei dir sein, weil es bei anderen nicht auftritt. Ein Vergleich des Pro- und GE-Codes hat bislang nichts ergeben.Ich bleibe aber dran...

Link to comment

Der Fehler "Graph too late" lässt sich unterdrücken, indem man auf der Eigenschaftsseite des DVBViewer Filters den Wert für Max. Queued Audio (TV/Radio) auf 0 setzt -> Übernehmen -> Sender wechseln. Hilft das irgendwie? Gibt es weiter Diskontinuitäten, oder hören die irgendwann auf?

 

Es muss irgendwas spezielles bei dir sein, weil es bei anderen nicht auftritt. Ein Vergleich des Pro- und GE-Codes hat bislang nichts ergeben.Ich bleibe aber dran...

 

Also der Fehler ist nach den setzen des Wertes auf Null immer noch da; nur das das Bild jetzt nicht 'stottert' sondern regelmäßig stockt. Das Problem tauch auch hauptsächlich bei dem sender SIXX auf.

 

Einen weiteren Fehler habe ich aber auch noch entdeckt. Bei DVBViewer GE gibt man ja neben dem Namen des SATIP Senders auch noch die IP an. Wenn das OctopusNet neu gestartet wird wird ihm vom DHCP-Server aber teileweise eine andere IP vergeben und DVBViewer GE empfängt nicht mehr. Man muß erst die IP wieder in der Einstellungen ändern. Bei DVBViewer pro besteht das Problem nicht.

Link to comment

Heute fing während des Zappens innerhalb von SD FTA-Sendern auch bei mir die Ruckelei/Stotterei an. Nach Umschalten > HD war nur noch Pixelmatsch mit hohem Grünanteil zu sehen. Das Problem bestand nach Neustart von GE und dann auch Rechner weiterhin. Auch bei mir verhielt sich die Pro normal. Ich fragte mich was ist hier unterschiedlich? Eigentlich nur die CI-Implementierung.

 

Ich hatte verschiedene RTSP-Konfigurationen angelegt. 1.) Eine mit CI nur Sendergruppe C; 2.) eine Ohne CI alle Sendergruppen bis auf C; und 3.) eine mit CI alle Sedergruppen auch C. Die Pro entspricht meiner Meinung nach der Variante 2 ohne CI. Ich hatte jedoch die Variante 3 noch in Betrieb.

 

Es stellte sich herraus, daß jetzt auch die Entschlüsselung nicht mehr funktionierte (Sendername blieb rot). Nach Umprogrammieren auf Variante 2 lief wieder alles flüssig (natürlich nur FTA wie bei Pro). Nach zurückprogrammierenauf Variante 3 war der Fehler wieder da.

Diskontinuitäten zählten bei vorhndenem Fehler narürlich auch hoch.

 

Abhilfe brachte ziehen - und stecken des AC-light Moduls. Vermutlich hätte auch "Resart Server" an der Octopus wieder geholfen.

Die Frage ist jetzt, wo klemmt die Säge? Im Moul oder in der Octopus? Ich gehe davon aus, daß das der gleiche Fehler wie in #77 war, nur, daß ich dort mit 2 RTSP Geräten gearbeitet hatte (Variante 1 und 2). Für FTA war dann kein CI ausgewählt und dadurch ruckelte es nicht. Das Modul lief wie bereits beschrieben 5 Jahre im Dauerbetrieb in einer TT3650.

 

@Boris Müller:

Was für ein Modul / Karte nutzt Du?

Tritt das Ruckeln auch auf wenn Du dem RTSP-Gerät sagst, es habe kein CI?

Tritt das Ruckeln auch auf wenn Du das Modul komplett ziehst?

 

Link to comment

Sollte das CAM regelmäßig abschmieren würde ich doch mal ein Firmware Update empfehlen.

Die Änderung kam nach 1.18 und das es mit einer anderen Karte problemlos lief sagt da nichts aus.

Das war bei mir ja auch so ...

Link to comment

Sollte das CAM regelmäßig abschmieren würde ich doch mal ein Firmware Update empfehlen.

Die Änderung kam nach 1.18 und das es mit einer anderen Karte problemlos lief sagt da nichts aus.

Das war bei mir ja auch so ...

Ja, ich hab es bei der Beschreibung der Updates bei Mascom gelesen. Es soll wohl bei neueren Receivern Probleme gegeben haben, und für Dauerbetrieb und Kopfstationen wird ab 1.23 empfohlen. Ich betrachte mich mal als Kopfstation und die OctopusNet als neuerer Receiver daher ab jetzt 1.27. Funktioniert jedenfalls erst mal wieder alles. Mal sehen wie lange....

Link to comment

Ich konnte jetzt mit Hilfe von Digital Devices bzw. einem Server-Log klären, wieso die Umschaltung von einem unverschlüsselten auf einen verschlüsselten Sender bei einem Transponderwechsel nicht funktionierte.

 

Der Fehler liegt im DVBViewer GE bzw. in TransEdit. Dort wird irrtümlich das Encrypted-Flag des zuletzt eingestellten Sender abgefragt, nicht das Flag des neu einzustellenden Senders. War leider wegen ähnlichen Bezeichnern schwer zu sehen.

 

Im Mitgliederbereich, Beta-Sektion, befindet sich eine neue GE-Testversion 3.4.3.3. Damit sollte die Umschaltung wie vorgesehen funktionieren.

Link to comment

Im Mitgliederbereich, Beta-Sektion, befindet sich eine neue GE-Testversion 3.4.3.3. Damit sollte die Umschaltung wie vorgesehen funktionieren.

Ja, das funktioniert jetzt wie es soll.

Besten Dank, und guten Rutsch!!

Link to comment

@Boris Müller:

 

Was für ein Modul / Karte nutzt Du?

Tritt das Ruckeln auch auf wenn Du dem RTSP-Gerät sagst, es habe kein CI?

Tritt das Ruckeln auch auf wenn Du das Modul komplett ziehst?

 

Ich nutze ein AlphaCrypt light.

Das Problem tritt auch auf, wenn kein Mudul im Gerät ist und die RTSP-Geräte ohne CI-Modul konfiguriert sind.

Link to comment

Leider habe ich noch keinen Ansatzpunkt gefunden, um das Problem zu bekämpfen. Ich habe auch keine Idee, wie es entsteht. Ein Vergleich von Pro- und GE-Code hat bislang keine Aufschlüsse gebracht.

 

Ich behalte das aber im Auge. Früher oder später hat sich bislang immer eine Lösung ergeben (wobei später allerdings durchaus ein Jahr oder so sein kann ;)).

Link to comment

Leider habe ich noch keinen Ansatzpunkt gefunden, um das Problem zu bekämpfen. Ich habe auch keine Idee, wie es entsteht. Ein Vergleich von Pro- und GE-Code hat bislang keine Aufschlüsse gebracht.

 

Ich behalte das aber im Auge. Früher oder später hat sich bislang immer eine Lösung ergeben (wobei später allerdings durchaus ein Jahr oder so sein kann ;)).

 

Kein Problem. Ist anscheinend auch nur bei einem Transponder.

Aber ich warte wahrscheinlich bis die Pro Version das CI unterstütz. Das habe ich auch das Problem mit dem wechselnden IP beim OctopusNet nicht.

Trotzdem bin ich schon sehr dankbar über die GE-version um ein paar Sachen auszutesten!

Link to comment

Hallo Griga!

 

Vielen Dank für Deine Arbeit bezüglich der CI-Unterstützung der Octopus Net!! Gibt es schon einen ungefähren Termin, wann das rs bzw. die pro Version soweit sind .-)

 

LG Albert

Link to comment
  • 1 month later...

Ich muss das nochmal hoch holen...

 

Werden diese x_pmt und x_ci Parameter noch standardisiert? Das ist doch Quatsch, dass das Octopus CI nur vom DVBViewer und RS angesteuert werden kann und sonst von keinem SAT>IP Client.

 

Auf den x_pmt Parameter hätte man ja verzichten können. Anhand der A/V-PIDs hätte man die PMT auch identifizieren können. Dann hätte es auf Client-Seite keine Erweiterungen benötigt. Außer dass die SAT>IP in der SDT als verschlüsselt markierte Kanäle nicht ausgefiltert werden.

 

Die Frage ist, ob, wenn SAT>IP Clients diese Parameter unterstützen, es auch mit RS DVB-Hardware möglich sein wird, die Entschlüsselung anzustoßen!? Oder wird da immer die komplette Tuner-Struktur benötigt.

Link to comment
Auf den x_pmt Parameter hätte man ja verzichten können. Anhand der A/V-PIDs hätte man die PMT auch identifizieren können.

 

Das liefe auf ein unschönes Such- und Ratespiel im Server hinaus. Bedenke, dass es Transponder mit -zig PMTs gibt (z.B. Astra 11568 V) - praktisch müsste der Server immer den gesamten Transponder scannen - und dass die Zuordnung A/V-PID -> PMT nicht eindeutig ist. Die selben A/V-PIDs können in verschiedenen PMTs auftauchen. Denke an die ORF-Regionalkanäle...

 

Weiteres hier.

Link to comment
  • 3 weeks later...

auch auf die gefahr mit dem thema zu nerven, beschäftigt mich die ganze zeit eine frage die ich bisher nicht verstehe.

wäre nett, wenn mich jmd. mit entsprechendem know-how da mal schlau machen könnte.

 

die unterstützung für das octopus.net wurde ja mittlerweile immerhin in den dvb ge viewer eingebaut und seitdem kann ich zumindest damit wieder sky sehen.

danke dafür!

 

was mich jedoch wurmt, ist, dass mit der software von dvblink & auch mit dem recording-service kein zugriff möglich ist.

bei dem thema hat es den anschein, als wenn sich z.b. der recording-service um den videostream UND um die dekodierung kümmern müsste.

 

bei zugriff mit vlc auf den rtsp stream bekomme ich einen entschlüsselten stream zu sehen.

irgendwie verstehe ich genau das nicht: rein logisch könnte man doch vermuten, dass die .net box die entschlüsselung vornimmt und dem client einfach

genau diesen stream zur verfügung stellt. vlc entschlüsselt doch nicht, oder?!

 

sprich: wie genau läuft die kommunikation/darstellung/auslieferung recording-service <-> octopus, wer entschlüsselt da wie genau und warum läuft das mit dem vlc player anders?

Edited by whity76
Link to comment

Ich hätte auch noch eine Frage - kann man denn mittlerweile schon das Octopus NET mit CIs und Recording Service nutzen?

Sind die CIs mittlerweile auch MTD-fähig?

 

Ich hab das Octopus NET zum Testen hier liegen, von der Arbeit aus... Will mir aber nicht die Arbeit machen, wenns eh zum Scheitern verurteilt ist...

 

 

LG Flo

Edited by Flo3787
Link to comment

Mit der Entschlüsselung ist es so:

Die Octopus benötigt einen Hinweis vom Client, dass der angeforderte Sender verschlüsselt ist und durchs CI muss.

In den URL's ist das der x_pmt Parameter und mit entsprechender URL funktioniert es dann auch im VLC.

Entschlüsselt wird dann natürlich von der Octopus Net.

 

Im normalen Sat>IP Standard ist das nicht enthalten und somit muss für die DD CI Lösung extra in die Clients (GE, Pro, RS) eingebaut werden.

Bis jetzt hat es dieses Sonderbehandlung nur in die GE geschafft.

Pro und RS folgen sicher irgendwann, aber wie @cinch schon gesagt hat ist das eigentlich völliger Quatsch.

 

 

P.S. Octopus NET kann kein MTD und DD äußerst sich auch nicht dazu.

  • Like 1
Link to comment

Ok, danke, habe ich auch schon festgestellt dass sich DD nicht dazu äußern mag.

Naja gut, dann werde ich das intern weitergeben, dann müssen wir diese Gerätschaften zurückgeben und was neues bauen.

Link to comment

Ok, danke, habe ich auch schon festgestellt dass sich DD nicht dazu äußern mag.

Naja gut, dann werde ich das intern weitergeben, dann müssen wir diese Gerätschaften zurückgeben und was neues bauen.

 

Starte doch mal eine Anfrage an DD. :)

Vielleicht kriegt ihr ja eine vernünftige Antwort.

Edited by nuts
Link to comment

Die Octopus benötigt einen Hinweis vom Client, dass der angeforderte Sender verschlüsselt ist und durchs CI muss.

In den URL's ist das der x_pmt Parameter und mit entsprechender URL funktioniert es dann auch im VLC.

Entschlüsselt wird dann natürlich von der Octopus Net.

 

 

super, vielen dank, jetzt kann ich das wenigstens nachvollziehen!

das heisst also, die einfachste lösung wäre - theoretisch - dass der client einfach einen sender anfordert, die octopus

merkt das der verschlüsselt ist, entschlüsselt und an den client ausliefert, richtig?

die frage ist jetzt, warum man diese aufgabe an den client abwälzt anstatt sich direkt selber darum zu kümmern?!

hört sich prinzipiell einfach nach besch**** software auf der octopus.net an, oder?

 

mittlerweile habe ich echt die befürchtung, dass ich die 300 flocken zu früh riskiert habe...

DD meinte, dass DVBViewer & dvblink das schon regeln würden, da beide immer schnell entsprechende lösungen in ihre software einbauen würden.

und dvblink hat da ebenfalls anscheinend keine lust drauf...

 

nur hab' ich das teil nach der aussage dummerweise gekauft. verstehe auch nicht, warum die octpus.net (aus den gleichen komponenten bestehend wie die klassische DD client hardware)

dann so viel weniger kann...

Link to comment

 

das heisst also, die einfachste lösung wäre - theoretisch - dass der client einfach einen sender anfordert, die octopus

merkt das der verschlüsselt ist, entschlüsselt und an den client ausliefert, richtig?

die frage ist jetzt, warum man diese aufgabe an den client abwälzt anstatt sich direkt selber darum zu kümmern?!

Naja das wäre fürs Ergebnis eine gute Lösung, aber nicht wirklich einfach, da der Server permanent den Stream untersuchen müsste um die Verschlüsselung zu erkennen.

Der RS macht das auch nicht so. Auch hier werden Custom-Parameter (DVBV => RS) in die Senderanforderung gepackt.

 

Die Behandlung gehört in den Sat>IP Standard, damit diverse Sat>IP Hardware auch miteinander funktioniert.

  • Like 1
Link to comment

beim nächsten kauf kümmere ich mich wieder vorher darum.
das hört sich noch nicht einmal halbgar an. eigentlich eine absolute schweinerei von DD das teil zu verkaufen und mit CI unterstützung zu werben, wenn dann verschlüsselte sender

maximal mit dem vlc player wiedergegeben werden können.

bei klassischen standalone sat2ip receivern wird's ja vermutlich auch eher schlecht aussehen wenn die sich an die spezifikation halten und das dort nicht entsprechend berücksichtigt

ist.

Link to comment

Hab schon Anfragen bei DD abgesetzt, aber leider antwortet mir man da nicht.

So wie es scheint, werden wir die Octopus NET zurückschicken und damit erst gar keine Tests fahren.

 

Danke euch für eure Hilfe.

 

 

LG Flo

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...