Ich habe die Karte mittlerweile mit kernel-2.6.39 am laufen.
PCIe DVB-C TV-Karte von Digital Devices bald verfügbar
- captainjack79
- Geschlossen
-
-
Thank you, Oliver
I've tried
with no luck. w_scan finds no channels.
When tuning in MythTV, it reports a constant 5% signal level, but never locks onto a channel with either DVB-T frontend.
A low signal level seems to be normal, but you should definitely get a lock.Strange. I checked with the current driver snapshot and it works perfectly for me:
finds all channels of the area.Did you install the DRXK firmware (drxk_a3.mc)?
CU
Oliver -
ich schließ mich der Frage an. Ferner würde mich interessieren, ob der Treiber eine "Insellösung" bleibt, oder eine Übergabe an linuxtv und damit der Einzug in den Kernel abzusehen ist. (Oder zumindest in Arbeit ist.)
Der Treiber http://www.vdr-portal.de/board16-video-disk-recorder/board85-hdtv-dvb-s2/105803-aktuelle-treiber-für-octopus-ddbridge-cines2-ngene-ddbridge-duoflex-s2-duoflex-ct-sowie-tt-s2-6400 ist für alle aktuellen Kernel geeignet, insbesondere auch für 2.6.38 und 2.6.39.Natürlich kommt der Treiber in den Kernel! Wenn es euch nicht schnell genug geht, könnt ihr euch gerne mal 2 Tage damit beschäftigen, die Treiberdateien an den beknackten Kernel-Codingstyle anzupassen. Und zwar möglichst, ohne dabei Fehler einbauen.
CU
Oliver -
Hi Oliver.
I've got both the drxk and ngene firmware in /lib/firmware. I think it must have been mistake on my part. I re-installed the kernel packages to clear anything I'd done, re-did make and make install and now I've got channels - more than I was expecting too!
Thanks for your help.
Now all I need to do is transfer all this to my live mythtv server...
-
Natürlich kommt der Treiber in den Kernel! Wenn es euch nicht schnell genug geht, könnt ihr euch gerne mal 2 Tage damit beschäftigen, die Treiberdateien an den beknackten Kernel-Codingstyle anzupassen. Und zwar möglichst, ohne dabei Fehler einbauen.
Vielen Dank für Deine Mühe, Oliver. Wollte auch gar nicht drängeln - Hauptsache, es wird in Angriff genommen -
Natürlich kommt der Treiber in den Kernel!
Aha, dann funktionieren:
- CI-Modul(e)
- ACPI-Wakeup ohne Workaround/Workaround-option
- Anzeige der Signalstärke (aka femon)oder:
- Bild/Ton stabil bei FTA, auch beim Umschalten
- Rest egalIch möchte keineswegs UFOs Leistung schmälern (erst durch Ihn habe ich meine DD-Karte zum Laufen bekommen) - Respekt! Allerdings scheint der Treiber wohl doch (ich beziehe mich auf die Micronas-Bridge) auf halbem Wege stecken zu bleiben. Zumindest das Pflichtenheft hat noch ein paar leere Stellen - ich kann mich aber auch irren.
BJ1
-
Aha, dann funktionieren:
- CI-Modul(e)
Ja, denn dies ist kein Problem des Treibers.Zitat
- ACPI-Wakeup ohne Workaround/Workaround-option
Ursache ist ein Bug des Motherboard-Chipsatzes. Wer dieses Problem hat, kann shutdown_workaround=1 angeben.
Mehr wird es von *meiner* Seite nicht geben. Wer mehr möchte, kann gerne Initiative entwickeln [1].
(Btw, der ngene-Treiber, den dies betrifft, ist bereits im Kernel - inklusive Workaround-Option.)Zitat
- Anzeige der Signalstärke (aka femon)
Offen, aber ganz sicher kein Hinderungsgrund, einen Treiber in den Kernel zu bringen.Zitat
oder:- Bild/Ton stabil bei FTA, auch beim Umschalten
- Rest egal
Was immer das auch heißen soll: Kann ich nicht nachvollziehen.Zitat
Ich möchte keineswegs UFOs Leistung schmälern (erst durch Ihn habe ich meine DD-Karte zum Laufen bekommen) - Respekt! Allerdings scheint der Treiber wohl doch (ich beziehe mich auf die Micronas-Bridge) auf halbem Wege stecken zu bleiben. Zumindest das Pflichtenheft hat noch ein paar leere Stellen - ich kann mich aber auch irren.
S.o.Bye
Oliver[1]
Wem der WA nicht reicht, hier das zugehörige Pflichtenheft von mir:
- Exakte Liste aller Chipsatzversionen ermitteln, die diesen Bug haben.
- Automatische Erkennung dieser Chipsätze implementieren.
- Workaround in genau diesen Fällen aktivieren.
- Und - natürlich - das ganze für die nächsten Jahre pflegen.Wer dies machen möchte, kann sich gerne melden. Patches are welcome.
-
Hallo
Ich habe nach Anleitung den Octopus Treiber installiert und alles funktioniert. Ich habe ein Duoflex-CT angeschlossen.Ich verwende sasc-ng/cccam um meine Cam zu verwenden, welche über dvbloopback zwei Adapter generiert.
Die Installation ist die Gleiche als mit meiner Technisat Skystar S2.Ein Zugriff ist nicht möglich. In folgende Thread is das Problem beschrieben, welche mit zwei Tuner auftritt:
http://www.dvbn.happysat.org/viewtopic.php?p=341894#p341894Mir fällt auf das innerhalb media_build_experimental das dvbdev.c angepasst wurde, aber out of sync ist für 2.6.38
diff ./media_build_experimental/experimental/ngene-octopus-test/linux/drivers/media/dvb/dvb-core/dvbdev.c ./media_build_experimental/linux/drivers/media/dvb/dvb-core/dvbdev.cDazu kommen folgende Beiträge wegen ein Locking Problem, welche in 2.6.38 gegenwärtig ist:
http://static.loping.net/bcode…fore-opening-driver.patch
https://aur.archlinux.org/packages.php?ID=48512Sind die viele Änderungen in dvbdev.c, welche für den Octupus gemacht wurden, für 2.6.38 relevant ? Kann ich die Distribution Version nehmen, sodass ich das Mutex Problem hinzufügen kann ?
Auf linuxtv.org Maillingliste, gab es am 3 Juli Patches Meldungen: http://www.spinics.net/lists/linux-media/msg34918.html
http://linuxtv.org/hg/~endriss/media_build_experimental/ sehe ich das die letzte Änderungen for 3 Wochen stattfanden.
In welche Hg sind die Patches reingekommen ?
Gibt es Anstrebungen, die Sources in Linux einzubinden, Version ? unverbindliches Datum ?Gruss
Simon -
Ich habe nach Anleitung den Octopus Treiber installiert und alles funktioniert. Ich habe ein Duoflex-CT angeschlossen.Ich verwende sasc-ng/cccam um meine Cam zu verwenden, welche über dvbloopback zwei Adapter generiert...
In diesem Forum gibt es keinen Support für Softcams! Vgl. Nutzungsbedingungen.Zitat
Mir fällt auf das innerhalb media_build_experimental das dvbdev.c angepasst wurde, aber out of sync ist für 2.6.38
diff ./media_build_experimental/experimental/ngene-octopus-test/linux/drivers/media/dvb/dvb-core/dvbdev.c ./media_build_experimental/linux/drivers/media/dvb/dvb-core/dvbdev.cDazu kommen folgende Beiträge wegen ein Locking Problem, welche in 2.6.38 gegenwärtig ist:
...
Sind die viele Änderungen in dvbdev.c, welche für den Octupus gemacht wurden, für 2.6.38 relevant ? Kann ich die Distribution Version nehmen, sodass ich das Mutex Problem hinzufügen kann ?
Die Änderungen in dvbdev.c haben *nichts* mit der Octopus zu tun.
Weder wurden sie für die Octopus gemacht, noch benötigt die Octopus diese Änderungen.
Die Änderungen kommen aus media_build, nicht aus dem Octopus-Treiber.Zitat
Auf linuxtv.org Maillingliste, gab es am 3 Juli Patches Meldungen: http://www.spinics.net/lists/linux-media/msg34918.html
http://linuxtv.org/hg/~endriss/media_build_experimental/ sehe ich das die letzte Änderungen for 3 Wochen stattfanden.
In welche Hg sind die Patches reingekommen ?
Gibt es Anstrebungen, die Sources in Linux einzubinden, Version ? unverbindliches Datum ?
Diese Patches sind der Versuch, den Treiber in den Kernel zu bringen. Voraussichtlich in Kernel 3.2.Die Patches sind in keinem Repository, denn es gibt keinen funktionalen Unterschied zu
http://linuxtv.org/hg/~endriss/media_build_experimentalEs gibt also keinen Grund, diese Patches direkt zu verwenden.
CU
Oliver -
Hallo,
wer kann mir erklären warum das Script zum Extrahieren verschiedener Firmwaredateien in den Kernelquellen unter "Documentation" abgelegt ist und nicht mit in den Buildprozess eingebunden ist? Gibt es dafür rechtliche Gründe oder ist das einfach ein Fehler? So wie es jetzt abgelegt ist wird keine Firmware im Buildprozess geladen und fehlt dann im fertigen Kernel.
Gruß BuddyHolly
Jetzt mitmachen!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!