nuts Posted December 27, 2013 Share Posted December 27, 2013 Discontinuities auch zu sehen? Quote Link to comment
Boris Müller Posted December 27, 2013 Share Posted December 27, 2013 Ja, werden auch angezeigt. Würde gerne einen Screenshot hochladen, bin aber wohl zu doof dafür! Quote Link to comment
playboy Posted December 27, 2013 Share Posted December 27, 2013 Vielleicht kommen die EMMs nicht an? Meinst sicher ECM-s , emm brauchts nur für verlängerungen Quote Link to comment
Derrick Posted December 27, 2013 Share Posted December 27, 2013 ..nö, ich meine EMMs. Es wird ja auch bei umschalten auf einen anderen sender nicht mehr entschlüsselt. Quote Link to comment
duddsig Posted December 27, 2013 Share Posted December 27, 2013 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. Quote Link to comment
nuts Posted December 27, 2013 Share Posted December 27, 2013 (edited) 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! Edited December 27, 2013 by nuts Quote Link to comment
Griga Posted December 27, 2013 Share Posted December 27, 2013 @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? 1 Quote Link to comment
duddsig Posted December 27, 2013 Share Posted December 27, 2013 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. Quote Link to comment
duddsig Posted December 27, 2013 Share Posted December 27, 2013 @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. Quote Link to comment
duddsig Posted December 27, 2013 Share Posted December 27, 2013 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. Quote Link to comment
Boris Müller Posted December 27, 2013 Share Posted December 27, 2013 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) Quote Link to comment
Griga Posted December 27, 2013 Share Posted December 27, 2013 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. Quote Link to comment
Griga Posted December 27, 2013 Share Posted December 27, 2013 @duddsig: Für dich gibt es auch eine Testversion 3.4.3.2 im Mitgliederbereich, Beta Sektion. Nur mal auf Verdacht... irgendein Unterschied? Quote Link to comment
duddsig Posted December 27, 2013 Share Posted December 27, 2013 @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 . Quote Link to comment
Griga Posted December 27, 2013 Share Posted December 27, 2013 @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... Quote Link to comment
duddsig Posted December 27, 2013 Share Posted December 27, 2013 @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. Quote Link to comment
Boris Müller Posted December 27, 2013 Share Posted December 27, 2013 @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. Quote Link to comment
Griga Posted December 28, 2013 Share Posted December 28, 2013 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... Quote Link to comment
Boris Müller Posted December 29, 2013 Share Posted December 29, 2013 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. Quote Link to comment
duddsig Posted December 30, 2013 Share Posted December 30, 2013 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? Quote Link to comment
nuts Posted December 30, 2013 Share Posted December 30, 2013 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 ... Quote Link to comment
duddsig Posted December 30, 2013 Share Posted December 30, 2013 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.... Quote Link to comment
Griga Posted December 31, 2013 Share Posted December 31, 2013 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. Quote Link to comment
duddsig Posted December 31, 2013 Share Posted December 31, 2013 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!! Quote Link to comment
Boris Müller Posted January 2, 2014 Share Posted January 2, 2014 @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. Quote Link to comment
Griga Posted January 2, 2014 Share Posted January 2, 2014 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 ). Quote Link to comment
Boris Müller Posted January 2, 2014 Share Posted January 2, 2014 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! Quote Link to comment
Haifisch Posted January 7, 2014 Author Share Posted January 7, 2014 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 Quote Link to comment
CiNcH Posted February 11, 2014 Share Posted February 11, 2014 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. Quote Link to comment
Griga Posted February 12, 2014 Share Posted February 12, 2014 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. Quote Link to comment
whity76 Posted February 27, 2014 Share Posted February 27, 2014 (edited) 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 February 27, 2014 by whity76 Quote Link to comment
Flo3787 Posted February 27, 2014 Share Posted February 27, 2014 (edited) 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 February 27, 2014 by Flo3787 Quote Link to comment
whity76 Posted February 27, 2014 Share Posted February 27, 2014 (edited) CI funktioniert aktuell nur in verbindung mit dem DVBViewer GE... Edited February 27, 2014 by whity76 Quote Link to comment
nuts Posted February 27, 2014 Share Posted February 27, 2014 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. 1 Quote Link to comment
Flo3787 Posted February 27, 2014 Share Posted February 27, 2014 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. Quote Link to comment
nuts Posted February 27, 2014 Share Posted February 27, 2014 (edited) 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 February 27, 2014 by nuts Quote Link to comment
whity76 Posted February 27, 2014 Share Posted February 27, 2014 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... Quote Link to comment
nuts Posted February 27, 2014 Share Posted February 27, 2014 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. 1 Quote Link to comment
whity76 Posted February 27, 2014 Share Posted February 27, 2014 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. Quote Link to comment
Flo3787 Posted February 27, 2014 Share Posted February 27, 2014 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 Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.