Hallo,
ich habe mir den neuen Dual-USB Receiver vom Sundtek angeschafft, bekomme damit aber einfach kein TV-Bild.
Ich habe mich übers Wochende schon intensiv mit dem Problem beschäftigt.
Ich wollte den Dual-Receiver eigentlich bei meinen MiniPCs (wie Asus-PN40 und Nuc-8i3) alterantiv zu SatIP verwenden.
Auf diesen Systemen mit installierter MLD 5.5 habe ich Sundtek zuerst getestet und dazu dvb-sundtek installiert.
Mit angeschlossenem Sundtek und installiertem Treiber sowie deaktiviertem SatIP aber leider kein TV-Bild.
Im VDR-Menü werden jedoch 2 Tuner und davon einer mit grünen Balken angezeigt.
Im Internet hatte ich gelesen, dass die neuen Sundtek Receiver (auch der Ultimate VIII) evtl. Probleme mit USB 3.0 haben.
Daher habe ich den Receiver auch auf meinem Intel i3-System mit MLD 5.4 testing und eingebauter CineS2 getestet.
Dazu CineS2 ausgebaut und den Receiver an einem der 4 "echten" USB 2.0 Ports angeschlossen und dvb-sundtek Paket installiert.
Nach einem Reboot auch wieder kein TV-Bild im VDR-Menü aber wieder zwei Tuner, davon einer als DVB-S2 mit grünen Balken.
Danach habe ich auf diesem System sowohl die 5.4 testing als auch die 5.5 mit den aktuellen Net-Inst Images neu installiert.
Der Dual-Tuner wird nicht automatisch erkannt und nach dem nachinstallieren der Sundtek-Treiber wieder kein TV-Bild.
Gleicher Zustand, wie bei den bereits vorher installierten MLD-Systemen.
Ich habe mir dann mal bei per SSH mit mediaclient einige Infos abgefragt.
Mit mediaclient -e sieht man, dass der Treiber den SkyTV Dual erkannt hat:
**** List of Media Hardware Devices ****
device 0: [ Dual S2] DVB-S/S2, REMOTE-CONTROL, DVB-S/S2
[INFO]:
STATUS: STANDBY
[BUS]:
ID: 1-8
[SERIAL]:
ID: U201009191038
[DVB-S/S2]:
FESTATUS: ACTIVE
LNBVOLTAGE: ENABLED
LNBSUPPLY: USBPOWER
LNBSTATUS: OK
FRONTEND: /dev/dvb/adapter0/frontend0
DVR: /dev/dvb/adapter0/dvr0
DMX: /dev/dvb/adapter0/demux0
[REMOTECONTROL]:
INPUT0: /dev/mediainput0
[DVB-S/S2]:
FESTATUS: STANDBY
FRONTEND: /dev/dvb/adapter1/frontend0
DVR: /dev/dvb/adapter1/dvr0
DMX: /dev/dvb/adapter1/demux0
Ausgabe von mediaclient --frontendinfo=/dev/dvb/adapter0/frontend0
LinuxDVB API v5.10
Devicename: Sundtek DVB-S/S2 (VIII)
Current Mode: DVB-S/S2
Supported Delivery Systems:
SYS_DVBS2
SYS_DVBS
Mit mediaclient --lc sieht man, dass der VDR darauf zugreift.
**** List of Media Clients ****
/dev/dvb/adapter0/frontend0:
2097 ... vdr
/dev/dvb/adapter0/dvr0:
2097 ... vdr
/dev/dvb/adapter0/demux0:
2097 ... vdr (13ed)
2097 ... vdr (13ee)
2097 ... vdr (13ef)
2097 ... vdr (13f2)
2097 ... vdr (13f1)
2097 ... vdr (13f0)
2097 ... vdr (0012)
2097 ... vdr (0014)
2097 ... vdr (0000)
2097 ... vdr (0011)
2097 ... vdr (0010)
/dev/mediainput0:
No client connected
/dev/dvb/adapter1/frontend0:
2097 ... vdr
/dev/dvb/adapter1/dvr0:
No client connected
/dev/dvb/adapter1/demux0:
2097 ... vdr (0012)
2097 ... vdr (0014)
2097 ... vdr (0000)
2097 ... vdr (0011)
2097 ... vdr (0010)
Aber mit mediaclient --tsscan=/dev/dvb/adapter0/frontend0 sieht man, dass eigentlich beim VDR keine Video-Daten ankommen können.
media scan tp: 0
Timed out after 1 seconds
Total found: 0 PMTs (incl. unknown 0x0000)
Scan finished after 0 packets (0 bytes)
Hier noch ein Auszug aus einem Massages-Log von heute, wo man sieht, dass der VDR die beiden Frontends erkennt und verwendet:
Dec 7 12:44:51 MLD user.info kernel: [ 1.858259] usb 1-8: new high-speed USB device number 3 using xhci_hcd
Dec 7 12:44:51 MLD user.info kernel: [ 1.985827] usb 1-8: New USB device found, idVendor=2659, idProduct=1802, bcdDevice= 0.00
Dec 7 12:44:51 MLD user.info kernel: [ 1.985831] usb 1-8: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Dec 7 12:44:51 MLD user.info kernel: [ 1.985833] usb 1-8: Product: Dual S2
Dec 7 12:44:51 MLD user.info kernel: [ 1.985836] usb 1-8: Manufacturer: Sundtek
Dec 7 12:44:51 MLD user.info kernel: [ 1.985838] usb 1-8: SerialNumber: U201009191038
...
Dec 7 12:45:24 MLD user.debug vdr: [2097] detected /dev/dvb/adapter1/frontend0
Dec 7 12:45:24 MLD user.debug vdr: [2097] detected /dev/dvb/adapter0/frontend0
Dec 7 12:45:24 MLD user.debug vdr: [2098] video directory scanner thread ended (pid=2097, tid=2098)
Dec 7 12:45:24 MLD user.debug vdr: [2097] probing /dev/dvb/adapter0/frontend0
Dec 7 12:45:24 MLD user.debug vdr: [2097] creating cDvbDevice
Dec 7 12:45:24 MLD user.debug vdr: [2097] new device number 1 (card index 1)
Dec 7 12:45:24 MLD user.info vdr: [2097] DVB API version is 0x050A (VDR was built with 0x050A)
Dec 7 12:45:24 MLD user.info vdr: [2097] frontend 0/0 provides DVB-S2,DVB-S with QPSK ("Sundtek DVB-S/S2 (VIII)")
Dec 7 12:45:24 MLD user.debug vdr: [2100] frontend 0/0 tuner thread started (pid=2097, tid=2100, prio=high)
Dec 7 12:45:24 MLD user.debug vdr: [2100] cTimeMs: using monotonic clock (resolution is 1 ns)
Dec 7 12:45:24 MLD user.debug vdr: [2097] cTimeMs: using monotonic clock (resolution is 1 ns)
Dec 7 12:45:24 MLD user.debug vdr: [2101] device 1 section handler thread started (pid=2097, tid=2101, prio=low)
Dec 7 12:45:24 MLD user.debug vdr: [2097] probing /dev/dvb/adapter1/frontend0
Dec 7 12:45:24 MLD user.debug vdr: [2097] creating cDvbDevice
Dec 7 12:45:24 MLD user.debug vdr: [2097] new device number 2 (card index 2)
Dec 7 12:45:24 MLD user.info vdr: [2097] frontend 1/0 provides DVB-S2,DVB-S with QPSK ("Sundtek DVB-S/S2 (VIII)")
Dec 7 12:45:24 MLD user.debug vdr: [2102] frontend 1/0 tuner thread started (pid=2097, tid=2102, prio=high)
Dec 7 12:45:24 MLD user.info vdr: [2097] found 2 DVB devices
Daraufhin habe ich aus meinen DVB-Karten Fundus einen alten Sundtek SkyTV UltimateII ausgebuddelt.
Diesen habe ich zuerst mal auf dem Intel CoreI-System mit der installierten 5.4 testing ausprobiert.
Und mit diesem alten Sundtek-Stick hatte ich sofort ein TV-Bild.
Bei einer erneuten Neuinstallation auf USB-Stick wurde der auch von dvb-autodetect erkannt und nach abschlossener Installation hatte ich sofort ein TV-Bild.
Mit mediaclient --tsscan=/dev/dvb/adapter0/frontend0 sieht man, dass mit dem UltimateII beim VDR (Das Erste HD eingestellt) Video-Daten (hier ARD-HD-Transponder) ankommen.
media scan tp: 0
** NO GROUP GIVEN **
** NO GROUP GIVEN **
** NO GROUP GIVEN **
** NO GROUP GIVEN **
PMT PID: 0x13ec
Program Number: 0x283d
TransportstreamID: 1019
Encrypted: No
Service type: 19
Service running: Yes
Provider Name: ARD
Service Name: Das Erste HD
--> 0x0492 (ITU-T Rec. H.222.0 | ISO/IEC 13818-1 private_sections)
--> 0x0498 (ISO/IEC 13818-6 type C)
--> 0x087b (ISO/IEC 13818-6 type B)
--> 0x13ed (27)
--> 0x13ee (ISO/IEC 11172 Audio)
--> 0x13ef (ISO/IEC 11172 Audio)
--> 0x13f0 (ITU-T Rec. H.222.0 | ISO/IEC 13818-1 PES packets containing private data)
--> 0x13f1 (ITU-T Rec. H.222.0 | ISO/IEC 13818-1 PES packets containing private data)
--> 0x13f2 (ITU-T Rec. H.222.0 | ISO/IEC 13818-1 PES packets containing private data)
--> 0x13f4 (ITU-T Rec. H.222.0 | ISO/IEC 13818-1 PES packets containing private data)
--> 0x1434 (ISO/IEC 13818-6 type B)
PMT PID: 0x13f6
Program Number: 0x283e
TransportstreamID: 1019
Encrypted: No
Service type: 19
Service running: Yes
Provider Name: ARD
Service Name: arte HD
--> 0x04f6 (ITU-T Rec. H.222.0 | ISO/IEC 13818-1 private_sections)
--> 0x04fc (ISO/IEC 13818-6 type C)
--> 0x13f7 (27)
--> 0x13f8 (ISO/IEC 11172 Audio)
--> 0x13f9 (ISO/IEC 11172 Audio)
--> 0x13fa (ITU-T Rec. H.222.0 | ISO/IEC 13818-1 PES packets containing private data)
--> 0x13fb (ITU-T Rec. H.222.0 | ISO/IEC 13818-1 PES packets containing private data)
--> 0x13fc (ISO/IEC 11172 Audio)
--> 0x13fd (ISO/IEC 11172 Audio)
--> 0x13fe (ITU-T Rec. H.222.0 | ISO/IEC 13818-1 PES packets containing private data)
--> 0x13ff (ITU-T Rec. H.222.0 | ISO/IEC 13818-1 PES packets containing private data)
PMT PID: 0x1400
Program Number: 0x283f
TransportstreamID: 1019
Encrypted: No
Service type: 19
Service running: Yes
Provider Name: ARD
Service Name: SWR BW HD
--> 0x055a (ITU-T Rec. H.222.0 | ISO/IEC 13818-1 private_sections)
--> 0x087b (ISO/IEC 13818-6 type B)
--> 0x09ac (ISO/IEC 13818-6 type C)
--> 0x1401 (27)
--> 0x1402 (ISO/IEC 11172 Audio)
--> 0x1403 (ISO/IEC 11172 Audio)
--> 0x1404 (ITU-T Rec. H.222.0 | ISO/IEC 13818-1 PES packets containing private data)
--> 0x1405 (ITU-T Rec. H.222.0 | ISO/IEC 13818-1 PES packets containing private data)
--> 0x1406 (ITU-T Rec. H.222.0 | ISO/IEC 13818-1 PES packets containing private data)
--> 0x1436 (ISO/IEC 13818-6 type B)
PMT PID: 0x140a
Program Number: 0x2840
TransportstreamID: 1019
Encrypted: No
Service type: 19
Service running: Yes
Provider Name: ARD
Service Name: SWR RP HD
--> 0x055b (ITU-T Rec. H.222.0 | ISO/IEC 13818-1 private_sections)
--> 0x087b (ISO/IEC 13818-6 type B)
--> 0x09ac (ISO/IEC 13818-6 type C)
--> 0x1401 (27)
--> 0x1402 (ISO/IEC 11172 Audio)
--> 0x1403 (ISO/IEC 11172 Audio)
--> 0x1406 (ITU-T Rec. H.222.0 | ISO/IEC 13818-1 PES packets containing private data)
--> 0x140e (ITU-T Rec. H.222.0 | ISO/IEC 13818-1 PES packets containing private data)
--> 0x140f (ITU-T Rec. H.222.0 | ISO/IEC 13818-1 PES packets containing private data)
--> 0x1438 (ISO/IEC 13818-6 type B)
Total found: 4 PMTs (incl. unknown 0x0000)
Scan finished after 15 packets (2820 bytes)
Da ich bei beiden Sundtek-Receivern ansonsten die geleiche HW verwende, sollte es an der Sat-Anlage bzw. dem Antennenkabel nicht liegen, dass mit dem SkyTV-Dual beim VDR keine Video-Daten ankommen.
Und auch der in MLD verwendete Sundtek-Treiber funktioniert auf jeden Fall mit den älteren Sundtek Stick.
Eigentlich sollte der Treiber in der aktuellen MLD 5.4 testing und MLD 5.5 unstable so aktuell sein, dass auch die neuesten Sundtek-Receiver damit funktionieren.
Ich hätte zwar noch ein paar Ideen, komme an diesem Punkt nicht mehr weiter, da ich unsicher bin, wie ich das bei MLD am Besten umsetzte.
An den Konfigurations-Datein von MLD (z.B. /etc/sundtek.conf) hab ich daher bewusst nichts verändert.
Auch tiefergehende Kommandos von mediaclient um z.B. PID-Filter, Transmisson-Mode und DVB API Options (--setver=5.0) zu verwenden, habe ich mir bewusst verkniffen.
Evtl. hat ja jemand im Forum eine Idee, wie ich SkyTV-Dual doch zum Laufen bringen könnte.
Mittlerweile vermute ich aber, wenn es nicht am Treiber liegt, einen HW-Defekt bei der SkyTV-Dual.