USB DVB-C Hardware?

  • (see attachment)
    Excuse me for my english - my German is not so hot.


    I more or less copied the code from pctv452e.c (which has IR and CI support for the TT connect S2-3650-CI).
    IR tested successfully - I don't have a CAM handy; so I can't test the CI.


    Users trying to use this patch will _either_ need to download the sourcecode from v4l-dvb _or_ patch a vanilla kernel with Guy's patch before applying mine (as my patch assumes Guy's patch has already been applied).


    Needless to say I can't guarantee it will not set your device on fire.


    -- feedback from Dr. Seltsam made me updating (attachment) ct3650CI.diff.
    This should open CI CAM settings on VDR.
    I hope Dr. Seltsam updates his post on this as well

  • so, die Box ist heute angekommen, und ich habe auch gleich den Patch von walinsky eingespielt.


    Erste Resultate:


    -Empfang ist super, auch auf QAM256
    -der IR-Empfänger funktioniert
    -das CI wird erkannt, aber das eingesteckte Alphacrypt wird im CAM-Menü von vdr nicht angezeigt (update: inzwischen gelöst!)


    [ 506.943872] dvb-usb: found a 'Technotrend TT-connect CT-3650' in warm state.
    [ 508.944072] dvb-usb: recv bulk message failed: -110
    [ 508.944082] ttusb2: there might have been an error during control message transfer. (rlen = 0, was 0)
    [ 508.945364] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer.
    [ 508.946335] DVB: registering new adapter (Technotrend TT-connect CT-3650)
    [ 508.954552] ttusb2: CI initialized.
    [ 508.954557] DVB: registering adapter 0 frontend 0 (Philips TDA10023 DVB-C)...
    [ 508.955518] input: IR-receiver inside an USB DVB receiver as /devices/pci0000:00/0000:00:02.1/usb1/1-1/input/input7
    [ 508.955572] dvb-usb: schedule remote query interval to 500 msecs.
    [ 508.957817] dvb-usb: Technotrend TT-connect CT-3650 successfully initialized and connected.
    [ 508.957855] usbcore: registered new interface driver dvb_usb_ttusb2


    vdr 1.7.5:
    Jun 19 20:34:18 ubuntuvdr1 vdr: [2263] probing /dev/dvb/adapter0/frontend0
    Jun 19 20:34:18 ubuntuvdr1 vdr: [2263] creating cDvbDevice
    Jun 19 20:34:18 ubuntuvdr1 vdr: [2263] new device number 1
    Jun 19 20:34:18 ubuntuvdr1 vdr: [2267] CI adapter on device 0 thread started (pid=2263, tid=2267)
    Jun 19 20:34:19 ubuntuvdr1 vdr: [2263] frontend 0/0 provides DVB-C with QPSK,QAM16,QAM32,QAM64,QAM128,QAM256 ("Philips TDA10023 DVB-C")
    Jun 19 20:34:19 ubuntuvdr1 vdr: [2263] found 1 DVB device

    VDR 1: Silverstone LC20, Cougar A300/R, MSI C847MS-E33, passive Asus GT520, KNC One DVB-C, Cine CT V6, WD10EACS; Atric-IR-Einschalter. SW: yavdr 0.5 per SSD
    VDR 2: im Aufbau: ACT-620 mit Coba-NT, Asrock B75 Pro3-M, Celeron G540, Sundtek MediaTV Digital Home (DVB-C/T), passive Asus GT610. SW: Ubuntu 13.04 minimal (ohne grafische Oberfläche) per SSD

    Dieser Beitrag wurde bereits 1 Mal editiert, zuletzt von Dr. Seltsam ()

  • so, walinsky hat den patch nochmal etwas geändert (ist oben schon eingearbeitet). Nun wird auch das CAM im CI richtig erkannt! :)


    Noch ein Hinweis: wenn man den patch auf das aktuelle v4l-dvb hg im Stammverzeichnis anwendet, muss man die Pfade anpassen.
    --- a/linux/drivers/media/dvb/dvb-usb/ttusb2.c
    +++ b/linux/drivers/media/dvb/dvb-usb/ttusb2.c


    --- a/linux/drivers/media/dvb/dvb-usb/ttusb2.h
    +++ b/linux/drivers/media/dvb/dvb-usb/ttusb2.h

    VDR 1: Silverstone LC20, Cougar A300/R, MSI C847MS-E33, passive Asus GT520, KNC One DVB-C, Cine CT V6, WD10EACS; Atric-IR-Einschalter. SW: yavdr 0.5 per SSD
    VDR 2: im Aufbau: ACT-620 mit Coba-NT, Asrock B75 Pro3-M, Celeron G540, Sundtek MediaTV Digital Home (DVB-C/T), passive Asus GT610. SW: Ubuntu 13.04 minimal (ohne grafische Oberfläche) per SSD

  • Das ist ja super :-)


    Habs gleich mal ausprobiert. Empfang ist wirklich viel besser als mit dem HD-Receiver, den ich zwischenzeitlich in Betrieb hatte. Allerdings werden verschlüsselte Kanäle nicht immer sofort beim Umschalten entschlüsselt. Beim zweiten Versuch gehts meistens.


    :lovevdr

    Don't Panic !!!

    Zotac IONITX-P-E, DD Cine CT V6, yaVDR 0.5 plus media_build_experimental, ONKYO TX-SR 606, Panasonic TH-42PZ85E via HDMI

  • hmm, preislich nimmt die CT-3650 sich mit dem TV-Stick von Sundek ja nicht viel.... CT-3650 mit mindestens 105€ zu dem Sundek Stick mit mindestens 95€


    Was spricht jetzt FÜR die CT-3650 wenn man IR und CI nicht benötigt??

    :vdr1 VDR User #626:fans 
    VDR II: YeongYang A106, Fusi D1522, Celeron 2GHz, Frontend per DVB-s FF, 2xDVB-c, ATRIC-IR, YaVDR 0.3a
    VDR III HDTV: Inter-Tech 2008V mit iMonLCD, Atric, ASRock Extreme3 770 AM3, AMD Sempron 140 1x 2.70GHz AM3, 1,5TB WD15EADS, 2TB WD20EARS, 2x4GB DDR3-1600, NVidia GT520 passiv, 3x DVB-c, YaVDR 0.5 @ Samsung PS-50B550

  • Objektiv gesehen die Vor unt Nachteile beider Loesungen:
    Sundtek MediaTV:
    * Closed Source (Herstellerunterstuetzt)
    * die naechsten Geraete (z.B DVB-C2/DVB-T2) werden ebenfalls unter Linux unterstuetzt, sofern das Interesse weiter vorhanden ist. Wir bewegen uns derzeit ebenfalls in Richtung MacOSX.
    * Formfaktor/USB Stick
    * Wir sind aktiv dabei die User mit diversen Projekten zu unterstuetzen Dreambox 800
    * Ebenfalls gibt es teilweise Mustergeraete fuer Entwickler einiger Projekte


    Technotrend:
    * Opensource (kein offizieller Support vom Hersteller)
    * USB CI (dies ist ein offensichtlicher Vorteil)
    * DVB-T wird noch nicht unterstuetzt.


    Konkurrenz belebt das Geschaeft, nunja wir werden in kuerze unsere Software aktualisieren damit man die Geraete auch ueber das Netzwerk direkt im Windows mit DVBViewer sowie Windows Mediacenter etc. verwenden kann (wie z.B HDHomerun, eyetv netstream DTT)

  • Die Fritzbox wird derzeit noch evaluiert, wir gehen jedoch noch einen Schritt weiter als mit MuMuDVB indem wir das gesamte Geraet in das Netzwerk exportieren.


    Netzwerksupport, Sundtek MediaTV (DVB-T, DVB-C) via (W)-LAN verwenden
    http://support.sundtek.com/index.php/topic,178.0.html


    Wir sind derzeit noch dabei W-Lan bestmoeglichst zu optimieren.


    Man kann mit diesem Feature auf jedem Linux PC virtuelle DVB Geraete erstellen welche sich ueber das Netzwerk mit dem Master Server verbinden welcher das DVB Geraet angeschlossen hat. Ebenfalls wird es hierbei demnaechst ein Autoconnect Feature geben, z.B.: USB Stick an Host A anschliessen, und es wird automatisch auf Host B bereitgestellt, bei einem Disconnect werden die Clients automatisch entladen. Linux - Windows Kopplungen werden ab demnaechst ebenfalls funktionieren. Solange ein Transponder eingestellt ist koennen mehrfache Clients das Geraet laden.

  • Hmm... wäre wohl besser, dort zu antworten, aber neuer Account und Diskussion hier gestartet. Also:


    Euer Engagement ist sehr lobenswert. Dennoch wäre der Einsatz von Standards zu überdenken. Ich habe ein sehr heterogenes Netzwerk (Linux, Windows, Windows Mobile, iOS4, DLNA-Client, ...). Außer einem propritärem Protokoll: wo ist der Unterschied zu eurem Server? In beiden Fällen wird der Stick ins Netzwerk exportiert. Dank Multicast für "beliebig" viele Clients.


    Die Fritz!Box würde ich aus ökonomischen Gründen heranziehen. Wie verlaufen hier die Tests? Bisherige USB-Bandbreiten liegen hier ja bei ca. 4 (7270) / 7 (7390) Megabyte/s. Das sollte für mehrere SD- oder für einen HD-Stream reichen. Bisherige Versuche, AV-Geräte zum Laufen zu bringen scheiterten jedoch mehrfach. Hier könnte der Userspace-Treiber echte Vorteile haben.
    Sollte das eines Tages laufen, kenne ich einige, die sich daraufhin den Stick kaufen würden.

  • MuMuDVB wurde soweit zwar noch nicht getestet sollte aber auch funktionieren.
    Der Unterschied bei unserem System ist das wie erwaehnt direkt virtuelle DVB Geraete (entsprechend der linuxdvb API v3-5.x) auf den Remote Hosts angelegt werden und standard Programme damit funktionieren, man kann das Geraet vollkommen ueber das Netzwerk ansprechen als ob es lokal angeschlossen waere. Das Protokoll ist nur zur Treiberinternen Kommunikation zustaendig.


    Die Tests sind derzeit noch nicht abgeschlossen, dies kann noch 1-2 Wochen andauern da derzeit unter anderem auch verschiedene NAS Systeme evaluiert werden und die Dreambox Integration erst abgeschlossen werden muss.


    Ein DVB-C Transponder benoetigt idR ca 5-6 MB (konstant), mit Hardware PID Filter kommt man auf ca 1.5 MB/Sek fuer HDTV runter, ca 400-700 kbyte/Sek fuer SDTV. Wir setzen diese Filter soweit bereits bei der Dreambox ein.

  • Also dieser Netzwerksupport finde ich eine geniale Sache....
    Zb bei DVB-T. Da braucht man nur eine Fritzbox unters Dach stellen wo DVB-T Empfang 100% ist, und streamt die Sender in die Untergeschosse wo der Empfang unter aller Sa(u) ist ;)


    Dazu hätte mich interessiert: Sind das "nur" Treiberentwicklungen? Oder wird für die kommenden Features auch die Hardware erweitert?
    Sprich: funktionieren später die neuen Features auch mit einem Stick den ich heute kaufen würde?

    :vdr1 VDR User #626:fans 
    VDR II: YeongYang A106, Fusi D1522, Celeron 2GHz, Frontend per DVB-s FF, 2xDVB-c, ATRIC-IR, YaVDR 0.3a
    VDR III HDTV: Inter-Tech 2008V mit iMonLCD, Atric, ASRock Extreme3 770 AM3, AMD Sempron 140 1x 2.70GHz AM3, 1,5TB WD15EADS, 2TB WD20EARS, 2x4GB DDR3-1600, NVidia GT520 passiv, 3x DVB-c, YaVDR 0.5 @ Samsung PS-50B550

    Dieser Beitrag wurde bereits 1 Mal editiert, zuletzt von Tobias ()

  • Die Software wird laufend erweitert und steht immer allen Kunden zur Verfuegung. Auch unsere neuen kommenden Geraete bauen auf die derzeitigen Entwicklungen auf, somit entsteht fuer uns auch in Zukunft kein besonderer Mehraufwand die ersten Geraete welche wir angeboten haben zu unterstuetzen oder zu erweitern.
    Fuer Geschaeftskunden liefern wir zudem eine Garantie das die Geraete langfristig unterstuetzt werden (diese verwenden meist ebenfalls die normalen oder nur geringfuegig erweiterte USB Sticks/MiniPCIe Boards welche Endkunden angeboten werden) - dies kann durchaus auch als Vorteil fuer Endkunden gesehen werden.

  • Ich empfinde schon den direkten Kontakt zum Hersteller als Vorteil.


    Leider sind Sie z.T. nicht auf meine Fragen eingegangen:


    1. Wie verlaufen die Fritz!Box-Tests? Oder sind diese bisher nur geplant?
    2. Ließe sich die u.g. Funktionalität nicht über offene Standards abwickeln (Multicast RTSP usw.). Ein darauf aufbauender Client, der diese Streams als virtuelle Hardware offeriert, ist natürlich ein netter Ansatz.


    Man sollte bedenken: baut man etwas eigenes, so muss für jede Plattform etwas eigenes gebaut werden. Das kann und wird eine verhältnismäßig kleine Firma wie Sundtek nicht leisten. Ein Aufbau eines offenen Servers wäre doch für's erste der bessere Business Case?

  • Da der Treiber im Userspace ist, ist er unabhaengig von der jeweiligen Kernelversion. Die derzeitigen Builds sind fuer folgende Architekturen verfuegbar:
    * Intel/AMD x86 (32/64 bit)
    * ARM (EABI4/OABI)
    * IBM PowerPC (ppc64-be/ppc32-be/z.B. Sony Playstation 3 - erste Version)
    * MIPS
    * MIPSel (z.B Dreambox 800)


    Sollte der generische Userspace Transfer zu langsam sein kann ein Zusatzmodul kompiliert werden (Sourcen sind hierfuer verfuegbar). Die Dreambox 300 Mhz Mips benoetigt dieses Modul, die von uns getesteten ARM Systeme nicht.


    Die Antworten zu:
    1.) es steckt noch in Arbeit ist jedoch bereits vorgesehen, wie geschrieben in ca. 1-2 Wochen.
    2.) Der Treiber registriert Schnittstellen die der offiziellen Linux DVB API entsprechen, man kann damit so ziemlich alle existierenden Programme benutzen welche auch mit anderen Geraeten funktionieren (vdr, tvheadend, kaffeine, mplayer, vlc, ...) und damit auch machen was die jeweiligen Applikationen unterstuetzen.
    Die Virtuellen Geraete sind nur ein Feature, mehrere werden kommen.

  • iPhone, wird wohl ein ARM System sein? Eventuell laeuft der generische Treiber darauf ja. Starten laesst sich der soweit auch ohne Geraet.


    Hier ein Beispiel fuer eine manuelle Installation
    http://support.sundtek.com/ind…,303.msg1408.html#msg1408


    Zum Testen kann man das jeweilige Paket einfach entpacken und den darin enthaltenen mediasrv einfach manuell starten.

  • Das fand ich zwar sehr unwahrscheinlich aber anstatt lange zu diskutieren habe ich auf meinem 3Gs mal "sundtek_installer_100620" zerlegt und folgende Binaries gestartet:
    ./armoabi/opt/bin/mediasrv
    ./armsysv/opt/bin/mediasrv
    In beiden Fällen kommt "cannot execute binary file".


    Hab zwar noch nichts für's iPhone kompiliert, aber wenn ich mal in /usr/sbin/sshd schaue, sehe ich, dass hier kein ELF-Header vorhanden ist.