Posts by HelmutB

    Vielleicht liegt es an der Konfiguration deiner VM, ich habe damit aber leider keine Erfahrung.

    Mit dem Treiber hat es sicher nichts zu tun, VDR setzt die Zeit über die Informationen aus der TDT (Time and Date Table) die im DVB Datenstrom mitgesendet wird.

    Helmut

    Weiß jemand, wie genau diese Uhrzeit ist?

    Das hat mich jetzt auch interessiert und habe dazu zuerst die Systemzeit verstellt, dann von VDR aktualisieren lassen und danach mit ntpdate überprüft:


    ORF1 über DVB-T2:

    Dec 11 21:01:33 gentoo64vdr vdr[4409]: [4437] system time changed from Wed Dec 11 20:43:58 2019 (1576093438) to Wed Dec 11 21:01:33 2019 (1576094493)

    ntpdate:

    Dec 11 21:02:26 gentoo64vdr ntpdate[4657]: step time server 178.255.158.14 offset 1.339549 sec


    3SAT auf S19.2E:

    Dec 11 21:07:25 gentoo64vdr vdr[5231]: [5253] system time changed from Wed Dec 11 20:44:14 2019 (1576093454) to Wed Dec 11 21:07:25 2019 (1576094845)

    ntpdate:

    Dec 11 21:07:55 gentoo64vdr ntpdate[5367]: step time server 178.255.158.14 offset 1.068156 sec


    es sind also nur 1 bis 2 Sekunden Zeitunterschied.
    Helmut

    obwohl die Karte dort auch unter tvheadend angezeigt wird).

    Hast du immer noch solche Fehermeldungen?

    Code
    1. 2019-11-12 01:56:35.778 diseqc: failed to set high voltage 0 (e=Vorgang wird nicht unterstützt)
    2. ..
    3. 2019-11-12 01:56:48.292 diseqc: failed to send diseqc cmd (e=Die Wartezeit für die Verbindung ist abgelaufen)
    4. ..
    5. 2019-11-12 01:59:45.934 mpegts: 12544.75H in Astra192 - tuning on Montage Technology M88DS3103 #0 : DVB-S #0
    6. 2019-11-12 01:59:45.934 en50494: transponder value bigger then 1023 for freq 1944750 (42508)
    7. 2019-11-12 01:59:45.934 en50494: invalid tuning freq
    8. ..
    9. 2019-11-12 02:05:28.793 diseqc: failed to set high voltage 1 (e=Vorgang wird nicht unterstützt)

    Das wäre seltsam, weil der/die Linux Treiber die ioctls FE_SET_VOLTAGE und FE_DISEQC_SEND_MASTER_CMD schon unterstützen.

    Und wenn der diseqc Befehl nicht gesendet werden kann geht es natürlich nicht, die SIgnalstärke sagt da wenig aus.

    Welche demod-Firmware verwendest du?

    Helmut

    Ich habe 0.3.1g damals nicht auf github gelegt weil mir damals schon das Problem mit xhci aufgefallen ist. Außeden waren da ein paar Anpassungen für Yuri666 drin die ich mir auch noch genauer ansehen wollte.


    beta : dein Modul ist auch eine SMIT - mit etwas längerer Reaktionszeit. Damit treten die Fehler seltener auf als mit einer Neotion oder Alphacrypt.


    Ich bin der USB3 Sache aber gearade auf der Spur und glaube schon einen Fehler im Treiber gefunden zu haben. Ich habe nur einen urb_complete Callback für IN und OUT. Das klappt bei USB2 weil hier die Daten über die 2 Datenleitungen nicht gleichzeitig gelesen und geschrieben werden können, Mit USB3/xhci scheint es hier aber Kollisionen zu geben.
    Helmut

    So einen Nvidia Chip habe ich vor ein par jahren bei inem HP Notebook auch so ähnlich "repariert". Da ist das Problem aber nach einer gewissen Zeit wieder aufgetreten. Vielleicht hast du beim Dell mehr Glück (oder es besser gemacht).


    Die 0.3.1a läuft bei mir auch ziemlich zuverlässig. Wenn sich nach den Umschalten auf einen unverschlüsseltes Programm das Modul nicht mehr ansprechen lässt, versuche die Version 0.3.1g mit dem "sync2" Patch (das kann, muß aber nicht vorkommen und ist auch Modul abhängig).


    Für USB3 und dem Neotion Modul habe ich noch keine Lösung. Ich habe nur festgestellt, dass bei den fehlerhaften TS-Paketen die ersten 2 bis 40 Bytes falsche Daten enthalten, der restliche Datenblock ist korrekt. Es scheint als würden sich da Schreib- und Lesevorgänge in die Quere kommen. Das ist aber nur bei Neotion und der Alphacrypt so extrem, die SMITs und ein SmarDTV Modul sind da weniger empfindlich.

    Ich werde da noch etwas nachforschen.


    Zum wintv-CI ein Tipp: die USB Buchse ist nur sehr "zart" auf der Platine angelötet und sollte vorsichtig behandeld werden. Ich habe sie schon einmal nachlöten müssen. Am besten also schon bevor sie sich lockert den Schutzlack rundherum etwas entfernen (= Masse) und "richtig" anlöten.


    LG Helmut

    Meine S950 ist doch V3 -deshalb SMIPCIE.

    Für deine V2 ist wird der Conexant cx23885 'CONFIG_VIDEO_CX23885' zuständig sein.


    Ich verwende die demod Firmware von https://github.com/OpenELEC/dv…re/dvb-demod-m88ds3103.fw

    Diese unterscheidet sich etwas von der im dvbsky Frmware Paket http://www.dvbsky.net/download/linux/firmware.zip

    Code
    1. ov 12 18:32:06 gentoo64vdr kernel: m88ds3103 2-0068: found a 'Montage Technology M88DS3103' in cold state
    2. Nov 12 18:32:06 gentoo64vdr kernel: m88ds3103 2-0068: downloading firmware from file 'dvb-demod-m88ds3103.fw'
    3. Nov 12 18:32:09 gentoo64vdr kernel: m88ds3103 2-0068: found a 'Montage Technology M88DS3103' in warm state
    4. Nov 12 18:32:09 gentoo64vdr kernel: m88ds3103 2-0068: firmware version: 3.B

    Astra 19.2E 10714H (Franken Fernsehen HD) zeigt eine SNR von ca. 11 dB SNR und eine Signalstärke von ca. -30 dBm.


    Helmut

    Die dmesg Ausgaben sehen ok aus, d.h. der rictige Treiber und Firmware ist vorhanden. Meine Signalwerte kann ich dir am Abend sagen SNR 12dB scheint mir aber "normal".

    Es siehr eher nach einer fehlerhaften diseqc Einstellungen aus:

    Code: TVHeadend log
    1. 2019-11-12 02:01:35.960 mpegts: 10714.25H in Astra192 - tuning on Montage Technology M88DS3103 #1 : DVB-S #0
    2. 2019-11-12 02:01:36.325 diseqc: failed to send diseqc cmd (e=Die Wartezeit für die Verbindung ist abgelaufen)
    3. 2019-11-12 02:01:36.325 en50494: error send tune command
    4. ...
    5. 2019-11-12 02:00:01.281 mpegts: 11464.25H in Astra192 - tuning on Montage Technology M88DS3103 #1 : DVB-S #0
    6. 2019-11-12 02:00:01.281 en50494: transponder value bigger then 1023 for freq 1714250 (5984)
    7. 2019-11-12 02:00:01.281 en50494: invalid tuning freq

    Wie hast du diseqc/scr konfiguriert?

    Helmut

    Nach einer kleineren Anpassung an der 'Waits' in den diseqc Zeilen klappt nun Unicable auch mit der TBS5520se/5580.

    Sowohl das Neotion Modul als auch die Alphacrypt Classic laufen über den ehci USB2 Controller fehlerfrei, aber nicht auf einem xhci USB2/3 Port. Ein dazwischengeschalteter USB2-Hub hat auch keine Verbesserung gebracht.

    Ich werde mir xhci ganauer ansehen, vielleicht finde ich etwas.

    Helmut

    Nein, dem Wintv-Ci geht es gut. Es ist nut die Kombination Neotion/xhci_hcd. Die "sync" Fehler im Log habe ich mit der Neotion auf dem J3345 genau so. Beim Notebook gibt es keine Fehler- allerdings nur mit dem ts-troughput getestet, da ich immer noch versuche die TBS mit Unicable zum laufen zu bekommen.

    Ich melde mich wenn ich etwas mehr weiß.

    LG Helmut

    Ich habe inzwischen auch die Neotion CAM gefunden und tw. ausprobiert Am Noteboork (USB2) habe ich keine Fehler beim ts_troughput.pl,, am VDR mit dem J3455 und dem xhci_hcd USB3 Controller bekomme ich Datenmüll mit CAM Reset aber kein Bild.

    Ich will das jetzt am Notebook mit der TBS-5580 oder 5520se versuchen, bekomme diese aber mit Unicable noch nicht zum Laufen.


    Zu deiner message.txt - kann es sein, dass hier noch der Git-Treiber ohne Patch läuft? Die Meldungen bei ci_isoc_allocate sollte nämich so aussehen:

    Code
    1. Nov 9 19:13:39 gentoo64vdr kernel: wintv_usb2ci: ts_rb_alloc : EP(06) ringbuffer size 1467904 bytes (8 x 480 + 128 | 3968 TS-packets)
    2. Nov 9 19:13:39 gentoo64vdr kernel: wintv_usb2ci: ci_isoc_allocate : EP(06) init 10 urbs (120 uframes | 480 TS-packets each urb)
    3. Nov 9 19:13:39 gentoo64vdr kernel: wintv_usb2ci: ci_isoc_setup : EP(06) initialize 10 urbs (DIR_OUT)
    4. Nov 9 19:13:39 gentoo64vdr kernel: wintv_usb2ci: ts_rb_alloc : EP(82) ringbuffer size 1467904 bytes (8 x 480 + 128 | 3968 TS-packets)
    5. Nov 9 19:13:39 gentoo64vdr kernel: wintv_usb2ci: ci_isoc_allocate : EP(82) init 10 urbs (120 uframes | 480 TS-packets each urb)
    6. Nov 9 19:13:39 gentoo64vdr kernel: wintv_usb2ci: ci_isoc_setup : EP(82) initialize 10 urbs (DIR_IN)
    7. Nov 9 19:13:39 gentoo64vdr kernel: wintv_usb2ci: isoc_tsnull_alloc : Init 2 spare out-URBs with 32 TS-NULL packets (8 uframes)

    Helmut

    Edit: mitmodinfo wintv_usb2ci sieht man die installierte Version: 0.3.1a (Git) bzw. 0.3.1g (mit sync2.patch)

    Ok, dann vielleicht mit dem gepatchtem Treiber. Ich habe irgendwo eine Neotion-CAM für die ORF Smartcard. Ich werde mir diese am Wochenende ansehen, vielleicht liegt es am Modul (deine reagiert viel schneller als meine SMIT).


    Bei DVB-Karten mit internem CI ist das Löschen von ca0 nicht notwendig. Ich kann die TBS-5580/CI gemeinsam mit dem Wintv-CI und ddci2 betreiben, und es ist egal in welchem Gerät sich das SimpliTv Modul befindet.

    LG Helmut

    Das es keine externen USB2 Anschluß gibt macht s natürlich etwas komplizierter. Bevor du mit dem löten beginnst vielleicht noch ein anderer Versuch, da das Wintv-Ci grundsätzlich schon auch auf einem USB3 Port läuft: verwende deine TT CT2-4650 und lösche /dev/dvb/adapter0/ca0 und starte dann VDR mit ddci2 (ich bin aber nicht sicher ob das technisch überhaupt funktionieren kann - muß ich Abend selbst ausprobieren).

    Helmut

    Ein kleiner Nachtrag -ich habe das Wintv-Ci immer an einem USB2-Port angeschlossen. Mein altes Notebook hat nichts anderes und beim VDR mit einem J3455 habe ich mit den USB3 Ports ganz allgemein Probleme.

    Helmut

    Leider nicht zu kurz sondern zu lange. Die Meldungen beziehen sich auf Verzögerung beim Schreben einer Message an das ca0 Device und das sollte innerhalb von 32ms möglich sein.

    Aber: vom Wintv-CI werden TS-pakete und CA-Messages nur nacheinander verarbeitet. Und manchmal bleibt nach dem Schreiben vom TS-Paketen die Hardware/Buffer in einem Zustand in dem CA-Meldungen noch nicht gleich angenommen werden können und zuvor auf zumindest ein weiteres TS-Paket gewartet werden muß. Wenn die TS-Datenrate zu gering ist, dauert das auch länger (...95ms).

    Und wenn die CA Message überhaupt zu lange braucht versucht VDR/ddci2 ein CAM Reset (wie in deinem Log) das dann allerdings auch nicht unbedingt klappt.


    Gerade bei ORF-HD sollte die Datenrate mit ca. 5Mb/s aber hoch genug sein, das Problem kenne ich bei 2Mb/s oder weniger (Puls4). Bei dir sieht es so als wäre der USB Durchsatz zu gering.

    Ich habe im Post #124 eine Patch zum Git-Stand gepostet bei dem u.a. dieses Hängenbleiben erkannt und behoben wird. Kannst du es einmal damit versuchen.

    Helmut

    /dev/dvb/adapter1:
    ca0 sec0

    Gut, damit sollte ddci2 das CI erkennen und du kannst dich mit den Eigenheiten des Wintv-Ci Treibers beschäftigen :).

    Sundtek legt keine "richtigen" dvb-devices an, weshalb sie sich mit anderen Kerneldevices überlagern können

    Dann wäre es besser dem Sundek eine eigene - hohe -Adapternummer vorzugeben.

    Code: /etc/sundtek.conf
    1. #Lowest adapter number to start with, e.g. /dev/dvb/adapter5/frontend0
    2. #first_adapter=5
    3. #Lowest videodevice number to start with, e.g. /dev/video5
    4. #first_videodev=5

    Dabei dürfte es bei bestimmten Konfigurationen aber auch Einschränkungen geben: Synology package: Unable to specify first_adapter

    Helmut

    Da sieht nach einem Fehler im Sundtek Treiber aus - so, als ob er sich nicht richtig im System registriert.

    Was passiert denn, wenn du Sundtek und TT-CT2 anschließt? Gibt es dann 2 Adapter?


    Mit nur einem Adapter findet das ddci2 Plugin das Wintv-Ci nicht, weil es ein "standalone"-Ci sucht, und dabei Adapter mit Frontends überspringt.

    Du kannst noch versuchen den Wintv-Ci mit dem Modul Parameter adapter_nreine fixe Nummer zuzuweisen. Vielleicht kann man das Problem so umgehen.


    Helmut

    Interessant, dass nur 1 Adapter angelegt wird. Versuche einmal das:

    Bei gestopptem VDR) den Sundek Stick und das WintvCi abstecken. dann zuerst den Sundtek und danach das Ci anschließen. Dann ls-R /dev/dvb. Un dann umgekehrt, zuerst das Ci anstecken, dann den Sundtec Stick- und wieder ls -R /dev/dvb .

    Helmut