Posts by Sundtek

  • TBS 6902 in 2020 - zu empfehlen?

    jrie wrote:

    Die DD Treiber werden hauptsächlich von Ralph Metzler ( rjkm ) entwickelt.

    Wegen Ärger mit Mauro Chehab werden die aber schon lange nicht mehr eingereicht.

    nst hat es auf sich genommen, die DD Treiber auf der kernel-media Liste einzureichen.

    Vor 2 Jahren hatte er dann aber auch von Mauro genug.

    Sein git gibt es noch.

    Deshalb haben wir vor 12 Jahren bereits Treiber in's Userspace verfrachtet und das komplette Framework dort auch neu entwickelt um keine Abhängigkeiten mehr zu haben.

    Es brachte viele Vorteile mit sich, vor allem was die Kompatibilität anging. Ein Treiber Binary für Linux 2.6.16 (2006!)- 5.x, und neue Versionen müssen wir auch nicht beachten.

    Das Build System benötigt bei uns gute 5-10 Minuten um Treiber für X86, ARM, MIPS, PPC, SH4 (und deren verschiedenen Variationen) zu erstellen und zu deployen.


    Kunden starten einfach das (einmal heruntergeladene) Netinstall-Skript und das zieht sich immer den aktuellen Treiber, auf allen Architekturen.

    Und das gilt auch nach wie vor für 12 Jahre alte Tuner.

    Diverse Distributionen haben das Netinstall Skript auch integriert, oder greifen direkt auf die fertigen Treiber zu.

    Auch beisst sich die Geschichte nicht mit anderen Webcam/DVB Treibern die es im Kernel gibt, da wir die ja überhaupt nicht anrühren.


    Der Dual S2 USB Tuner ist n Tuner für die Hosentasche :-)

  • Kein TV Bild bei Neuinstallation

    seahawk1986 wrote:

    Oder den mediasrv tatsächlich unter die Kontrolle von systemd stellen:

    https://github.com/yavdr/yavdr…ystemd/sundtek.service.j2 - dazu muss man dann allerdings die udev-Regel übersteuern, die vom sundtek-Treiber installiert wird, damit der mediaclient nicht dazwischen funkt.

    Mit dem --wait-for-devices Flag blockiert der Treiber dann so lange bis alle Geräte initialisiert wurden.

    Das Dynamite Plugin ist die beste Wahl.

  • [Gelöst] WinTV dualHD - Moduloption um nur einen Tuner zu nutzen?

    Schau mal in die Email.


    Die Dual Tuner sind nicht abgesagt, wir müssen noch etwas mehr testen da es diese Woche große Treiberänderungen gab die zum Teil große Änderungen mit sich gebracht haben, ob's eine neue HW Revision gibt wird dann in den kommenden Tagen festgelegt. Ein paar Tuner haben wir ja noch fertig bestückt (welche während der Tests aber erst mal den Testern vorbehalten sind).

    Der Chiphersteller hat uns zur Zeit auch auf dem Radar mit den Geräten und will da bei den Kabelnetzen bei denen wir Zugriff haben auch noch etwas überprüfen.

    Genauere Antworten gibt's dann im Laufe der nächsten Werk-Tage.

  • Ztw. kein Bild nach Umschalten mit VDR ab Version 2.3.9

    HelmutB wrote:

    Einen kleinen Fehler im Patch hätte ich schon gefunden: statt "%ld ms" sollte es "%lu ms" für den uint64_t Rückgabewert von Elapsed() sein (auf einem 64-Bit System, "%llu" bei 32-Bit).

    Für sowohl 32 als auch 64 Bit sollte "lld" mit (unsigned long long) typecast gehen.

    dsyslog(">>> %s(%d/%d): %llu ms (18V->13V)", __func__,adapter, frontend, (unsigned long long)ExecTimer.Elapsed())

    Schau dir mal inttypes.h an


    %"PRIu64"

  • Ztw. kein Bild nach Umschalten mit VDR ab Version 2.3.9



    Der Tuner auf dem Matrix blockiert ja auch die Leitung bei Dir.

    Ich weiß nicht wie es bei den anderen Tunern mit den Timings aussieht, eventuell haben diese auch Sleeps in den Treibern wenn sie die Spannungsversorgung hochdrehen (eventuell um sicherzugehen dass dann wirklich 18 oder 13V an der Leitung anliegen).

    Das Re-Tune ist ja nur der "After"-Effekt wo die Leitung bereits belegt war.

  • Ztw. kein Bild nach Umschalten mit VDR ab Version 2.3.9

    kls wrote:

    Meine Idee geht mehr in die Richtung, die tatsächlichen Daten zu checken.


    Der beliegende Patch prüft, ob die gewünschte SID in der PAT enthalten ist und löst einen Retune aus, wenn sie nicht innerhalb von 2 Sekunden gefunden wird. Eine hunderprozentige Lösung ist das freilich auch nicht, denn unterschiedliche Transponder können die selben SIDs verwenden. Eventuell müssen noch weitere Daten mit einbezogen werden (am liebsten ja die Transponder-ID, aber da habe ich auf die Schnelle keine Stelle gefunden, wo man sicher sein kann, die ID des tatsächlich getunten Transponders zu erhalten - falls da jemand drauf deuten kann, bitte her damit!).


    Bitte probiert es mal damit. Aber Achtung: der Patch ist experiementell und hat noch einige Debug-Ausgaben. Das soll nur mal ein erster Ansatz sein...


    das ist gut, wie wär's auch die Transport Stream ID zu benutzen? Dann sollte es eindeutig sein.

    Uwe meinte (nachdem ich das geschrieben hab) dass die Transport Stream ID in der channels.conf hinterlegt ist.

  • Ztw. kein Bild nach Umschalten mit VDR ab Version 2.3.9

    HelmutB wrote:

    Uwe : versuche es einaml mit einer längeren Verzögerung nach dem setzen von 18V und vor dem zurückschalten auf 13V, z.B 100ms: S19.2E 11700 V 9750 t V W100 S0 [71 00 00 00] W100 v

    Helmut

    Die längere Verzögerung blockiert die 18V doch nur noch länger auf der Leitung (für den anderen Teilnehmer). Nehmen wir an dass der 2. Teilnehmer gerade EPG scannt... da wird eine Kollision dann schon deutlich wahrscheinlicher.


    Wenn VDR 2 nun folgende Dinge einstellt während der VDR 1 die Leitung oben hat

    Alter Transponder Symbolrate: 22msym; Modulation QPSK

    Neuer Transponder Symbolrate: 22msym; Modulation QPSK


    Tuner wird da dann ein OK und Locked zurückgeben, egal ob der LNB nun den Transponder wechseln konnte oder nicht - und genau das passiert hier.


    Wenn VDR 2 von 22msym; Modulation QPSK auf 27.5MSYM/8PSK wechseln würde dann würde der Tuner im nachfolgendem Schritt kein Hardware-Lock zurückgeben und der VDR würde versuchen Diseqc erneut abzuschicken.

  • Ztw. kein Bild nach Umschalten mit VDR ab Version 2.3.9

    kls wrote:

    Sundtek Kann man sich darauf verlassen, dass ein ioctl()-Aufruf an den Treiber erst dann zurückkehrt, wenn das Signal-Handling auf der Antennenleitung vollständig erledigt ist? Oder ist es möglich, dass der Treiber da was puffert und asynchron abarbeitet?


    Ich frage deshalb, weil innerhalb eines VDR ja durch einen Mutex sichergestellt ist, dass immer nur *ein* Tuner die Leitung benutzt. Was aber nicht funktionieren würde, wenn der Treiber asynchron arbeitet.


    Sobald ein weiteres Gerät die gleiche Leitung benutzt (anderer VDR oder Receiver) besteht die Möglichkeit einer Kollision natürlich unabhängig davon und bedarf einer Lösung im VDR.

    Ist synchron. Es geht im Fall von Uwe soweit ich weiß auch um 2 oder mehrere Systeme die auf der Unicable Leitung sitzen.

  • Ztw. kein Bild nach Umschalten mit VDR ab Version 2.3.9

    Das schwarze Bild kommt bei folgender Situation (bei Unicable)


    1. Ein externer Receiver zieht die Leitung auf 18V und schaltet um (z.B ein anderer VDR während er EPG scannt)


    2. Es wird ein Sender eingestellt welcher die gleichen Transpondereinstellungen hat wie der vorige. (Modulation & Symbolrate bleiben gleich). Der Tuner liefert ein Hardware Lock und VDR ist glücklich.


    Sofern der neue Transponder eine andere Modulation & Symbolrate hat und VDR kein Lock bekommt versucht VDR den Transponder erneut zu tunen (also die Diseqc Befehle erneut abzusetzen).


    3. VDR hängt nun auf dem falschen Transponder rum, der liefert zwar Daten aber nicht die richtigen.


    Dies wurde mittels folgendem Befehl überprüft (folgender Befehl analysiert den Transportstream der aktuell übermittelt wird, die Befehle greifen auf die Interne Schnittstelle bei den Sundtek Tunern zu):

    /opt/bin/mediaclient --tsscan /dev/dvb/adapter0/dvr0


    4. Unser Treiber loggt die Diseqc Befehle, wenn Uwe die Befehle manuell absetzt (also ein Re-Tune wie bei einem fehlendem Lock durchführt) bekommt er ein Bild.


    /opt/bin/mediaclient -V H

    /opt/bin/mediaclient --diseqc "aa bb cc dd ee"

    /opt/bin/mediaclient -V V


    ("aa bb cc dd ee" nimmt er aus unserer Logfile, was VDR halt geschickt hat)


    Die SDT (Service Description Table) sollte überprüft werden ob der eingestellte Sender auch wirklich auf dem Transponder vorhanden ist. Falls nicht sollte der Transponder wie bei Punkt 2 behandelt werden (=re-tune)

    https://en.wikipedia.org/wiki/Service_Description_Table


    Das Problem tritt wohl sehr selten auf.


    --- und hier noch wie Uwe es reproduziert hat ---


    Jetzt habe ich wieder nachgestellt:

    Code
    1. Apr 1 16:07:42 raspberrypi vdr: [2028] switching to channel 26 S19.2E-1-1039-10378 (SR Fernsehen HD)
    2. Apr 1 16:07:42 raspberrypi vdr: [2217] device 1 TS buffer thread ended (pid=2028, tid=2217)
    3. Apr 1 16:07:42 raspberrypi vdr: [2216] buffer stats: 389348 (7%) used
    4. Apr 1 16:07:42 raspberrypi vdr: [2216] device 1 receiver thread ended (pid=2028, tid=2216)
    5. Apr 1 16:07:43 raspberrypi vdr: [2031] frontend 0/0 locked on channel 26 (SR Fernsehen HD), tp 111053 after 284 ms
    6. Apr 1 16:07:43 raspberrypi vdr: [2218] device 1 receiver thread started (pid=2028, tid=2218, prio=high)
    7. Apr 1 16:07:43 raspberrypi vdr: [2219] device 1 TS buffer thread started (pid=2028, tid=2219, prio=high)


    Mit dem mediaclient-Tool geschaut, was empfangen wird:

    hr-fernsehen HD war der Sender, der davor eingestellt war.


    Jetzt schaue ich in Logfile, was der Sundtek Treiber für ein Diseqc Kommando für hr-fernsehen HD abgesetzt hat:



    Sobald ich das Diseqc Kommando abgesetzt hatte (2), war sofort ein Bild auf sr-fernsehen HD zu sehen. Das sieht man auch im syslog: rpihddevice: set...


    Code
    1. Apr 1 16:10:53 raspberrypi vdr: [2218] rpihddevice: set video codec to H264
    2. Apr 1 16:10:53 raspberrypi vdr: [2043] rpihddevice: set HDMI audio output format to 2ch PCM, 48.0kHz
    3. Apr 1 16:10:54 raspberrypi vdr: [2042] rpihddevice: video stream started 1280x720@50p, PAR=1/1
    4. Apr 1 16:10:54 raspberrypi vdr: [2042] rpihddevice: display PAR=1,000, setting video render PAR=1/1

  • [Gelöst] WinTV dualHD - Moduloption um nur einen Tuner zu nutzen?

    vdr_rossi wrote:

    Leider ist das nicht eingehalten worden. Im Namatek Store sind die nach wie vor als Lagernd gekennzeichnet.

    Das schreibt ein Kunde der immer noch auf Ware wartet...

    Wir sind dabei und liefern schnellst möglichst aus. Im Laufe der kommenden Woche wird's soweit sein.

    Bei Dual S2 fehlen noch die gelaserten Acrylplatten, Dual C ist nun in der Fertigung.

    Das Debugging bei Uwe hat auch ein paar Tage gekostet (aber dort ist soweit auch alles gut).

    Da die Geräte neu sind gehen wir da jedem Problem sehr genau nach, auch wenn nicht alle Probleme bei uns liegen. Vor allem um zu vermeiden dass andere Kunden auch die gleichen Probleme bekommen und wir nicht mit der Hardware in merkwürdige Situationen laufen; Sollte es schwerwiegende Probleme geben werden die Tuner aus dem Verkauf genommen/storniert und gar nicht erst verschickt (soweit sind die Tuner aber alle in Ordnung).


    Wir haben die Geräte zwar äußerst genau getestet, aber haben auch nur unsere definierten Tests durchgeführt (24/7, bei DVB-S/S2/S2X Quad LNB bzw. Signalgenerator mit Last; bei DVB-C Primacom & Signalgenerator)


    Dual C und Dual S2 verwenden die gleiche Firmware und den gleichen FPGA Core.

  • [Gelöst] WinTV dualHD - Moduloption um nur einen Tuner zu nutzen?

    Der Tuner den Vu+ damals als Zusatztuner angeboten hat war Technik Stand 2009, und die werden alle weiterhin unterstützt. Soweit ich weiß war bei den alten Tunern die Netto Umschaltzeit noch 600-900ms (also eher um's 2-3fache höher als bei den aktuellen Tunern).


    https://tinyurl.com/ttufrxs


    Soweit wir das überprüft haben ist der Tuner bei niedrigeren Frequenzen im Kabelnetz noch ein Stückchen besser als die MediaTV Digital Home/Pro III, Verfügbarkeit ab 9. April 2020 (wir sitzen zur Zeit in der Fertigung und sind auch dabei weitere Dual S2 zu bauen)

  • Bildstörungen mit Kernel > 4.9.x

    SurfaceCleanerZ wrote:

    Hi,

    Der Raspi 1-3 sind ja USB-technisch lahm, der 4 soll ziemlich schnell sein.

    Mfg Stefan

    Wir haben 320 Mbit via USB 2.0 (4x DVB-S/S2 via Single USB 2.0 Port) auf einem Raspberry PI 3 getestet, das zum Stichwort lahm.


    USB 3.0 eignet sich für 8x USB Tuner, wobei wir auf dem Raspberry PI 3 "nur" 7 Tuner zum Laufen gebracht haben, beim 8. Tuner wurde das USB Keyboard gelockt, nach Beendigung des Streams funktionierte das Keyboard wieder. Hier könnte man natürlich noch Hardware PID Filter einsetzen das würde dann wohl auch mit 8 Streams ohne Probleme funktionieren.

  • Ztw. kein Bild nach Umschalten mit VDR ab Version 2.3.9

    Na es ist nur aufgefallen dass nach den 18V auf einem Tuner der andere Tuner auch auf 13V zurückgeschalten wird (was ja eigentlich nicht notwendig ist da sie nie auf 18V geschalten wurden). Je nach Treiber kann der Umschaltvorgang einfach ein paar Millisekunden zusätzlich andauern. Wenn sich einige andere Tuner im Standby befinden kann das eventuell zu deutlichen Umschaltverzögerungen führen.

  • Ztw. kein Bild nach Umschalten mit VDR ab Version 2.3.9

    Was mir beim VDR aufgefallen ist (hinsichtlich Unicable):


    Ein Tuner wird auf 18V geschalten, danach werden die DISEQC Befehle geschickt, und anschließend werden (im Falle unserer Dual Tuner) beide Tuner auf 13V zurückgeschalten. Das ist ein 13V Request zu viel.


    Was ich hier für etwas besser halten würde wäre:

    Es wird nur ein Tuner für die Spannung und Diseqc verwendet (gut wir können das im Treiber auch noch umlenken), dennoch würde VDR dann den 2. Tuner auch noch auf 13V schalten, eigentlich könnte die LNB Spannungsversorgung des 2. Tuners komplett ausgeschalten werden.


    Das er kein Bild erhalten hat lag eventuell an uns da der Treiber die Spannung inkl. dem Diseqc für mehr als 250 Millisekunden belegt hat, aktuell belegt der Tuner die Leitung für ca. 100 Millisekunden (plus was in der diseqc conf so eingestellt ist)