Sundtek Support Forum
Deutsch => Sundtek MediaTV Pro => Thema gestartet von: tvpaul am Januar 17, 2015, 10:17:02 Nachmittag
-
Ich habe folgendes Problem mit meinem neu erhaltenen MediaTV Pro III.
Rechner A (opensuse 13.2):
mit DVB-T und kaffeine funktioniert.
Rechner B (opensuse 13.1):
mit DVB-T und kaffeine funktioniert ebenfalls
Aber:
Stick an Rechner A mit DVB-T.
netzwerk enabled mit:
/opt/bin/mediaclient --dtvtransfermode=bulk -d /dev/dvb/adapter0/frontend0
/opt/bin/mediaclient --enablenetwork=on
(Stick auch bereits einmal wieder abgezogen/neu angesteckt+ selbe Befehle)
wenn ich nun an Rechner B mounte, dann zeigen mediaclient und kaffeine den Stick an, aber sobald ich versuche in kaffeine einen Sendersuchlauf zu starten, oder eine Sender direkt anzuwählen, friert kaffeine ein und kann nur noch mit kill gestoppt werden. mediaclient sagt auf beiden Rechnern Standby.
was kann ich tun, um per Netzwerk zugreifen zu können?
(mit einem alten Stick kann ich von Rechner C (Raspberry) DVB_-C auf Rechner B streamen - prinzipiell kann Rechner B es also)
-
Es müssen überall die gleichen Treiberversionen installiert sein, ist dem denn so bei dir?
-
ja, überall zur sicherheit gerade noch einmal neintstall aufgerufen.
-
ist noch jemand dran an dem Problem?
-
ich hab w_scan laufen lassen. einmal auf dem Rechner, an dem der Stick physikalisch hängt, und einmal an dem Rechner, an dem übers Netz gemounted wurde.
Rechner, an dem der Stick physikalisch hängt:
hier läuft der scan flott durch, und liefert eine Liste mit Sendern.
w_scan
w_scan version 20140727 (compiled for DVB API 5.10)
guessing country 'DE', use -c <country> to override
using settings for GERMANY
DVB aerial
DVB-T Europe
scan type TERRESTRIAL, channellist 4
output format vdr-2.0
output charset 'UTF-8', use -C <charset> to override
Info: using DVB adapter auto detection.
/dev/dvb/adapter0/frontend0 -> TERRESTRIAL "Sundtek DVB-T (III)": good :-)
Using TERRESTRIAL frontend (adapter /dev/dvb/adapter0/frontend0)
-_-_-_-_ Getting frontend capabilities-_-_-_-_
Using DVB API 5.10
frontend 'Sundtek DVB-T (III)' supports
INVERSION_AUTO
QAM_AUTO not supported, trying QAM_64.
TRANSMISSION_MODE_AUTO
GUARD_INTERVAL_AUTO
HIERARCHY_AUTO
FEC_AUTO
FREQ (42.00MHz ... 1002.00MHz)
-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
Scanning DVB-T...
Scanning 7MHz frequencies...
177500: (time: 00:03.860)
184500: (time: 00:06.188)
191500: (time: 00:08.516)
198500: (time: 00:10.843)
205500: (time: 00:13.169)
212500: (time: 00:15.494)
219500: (time: 00:17.820)
226500: (time: 00:20.148)
Scanning 8MHz frequencies...
474000: (time: 00:22.474)
482000: (time: 00:24.802)
490000: (time: 00:27.128)
498000: (time: 00:29.453)
506000: (time: 00:31.780)
514000: (time: 00:34.105)
522000: (time: 00:36.432)
530000: (time: 00:38.758)
538000: (time: 00:41.082)
546000: (time: 00:43.409)
554000: (time: 00:45.737)
562000: (time: 00:48.064)
570000: (time: 00:50.388)
578000: (time: 00:52.714) signal ok: QAM_64 f = 578000 kHz I999B8C999D999T999G999Y999 (0:0:0)
QAM_64 f = 578000 kHz I999B8C999D999T999G999Y999 (0:0:0) : updating transport_stream_id: -> (0:0:12801)
QAM_64 f = 578000 kHz I999B8C999D999T999G999Y999 (0:0:12801) : updating network_id -> (0:12338:12801)
QAM_64 f = 578000 kHz I999B8C999D999T999G999Y999 (0:12338:12801) : updating original_network_id -> (8468:12338:12801)
updating transponder:
(QAM_64 f = 578000 kHz I999B8C999D999T999G999Y999 (8468:12338:12801)) 0x0000
to (QAM_16 f = 578000 kHz I999B8C23D0T8G4Y0 (8468:12338:12801)) 0x405A
586000: (time: 00:58.247) signal ok: QAM_64 f = 586000 kHz I999B8C999D999T999G999Y999 (0:0:0)
QAM_64 f = 586000 kHz I999B8C999D999T999G999Y999 (0:0:0) : updating transport_stream_id: -> (0:0:514)
QAM_64 f = 586000 kHz I999B8C999D999T999G999Y999 (0:0:514) : updating network_id -> (0:12290:514)
QAM_64 f = 586000 kHz I999B8C999D999T999G999Y999 (0:12290:514) : updating original_network_id -> (8468:12290:514)
updating transponder:
(QAM_64 f = 586000 kHz I999B8C999D999T999G999Y999 (8468:12290:514)) 0x0000
to (QAM_16 f = 586000 kHz I999B8C23D0T8G4Y0 (8468:12290:514)) 0x405A
594000: (time: 01:04.271)
602000: (time: 01:06.597)
610000: (time: 01:08.922)
618000: (time: 01:11.248)
626000: (time: 01:13.573)
634000: (time: 01:15.898)
642000: (time: 01:18.224)
650000: (time: 01:20.550)
658000: (time: 01:22.875)
666000: (time: 01:25.201)
674000: (time: 01:27.527)
682000: (time: 01:29.853)
690000: (time: 01:32.179) signal ok: QAM_64 f = 690000 kHz I999B8C999D999T999G999Y999 (0:0:0)
QAM_64 f = 690000 kHz I999B8C999D999T999G999Y999 (0:0:0) : updating transport_stream_id: -> (0:0:13057)
QAM_64 f = 690000 kHz I999B8C999D999T999G999Y999 (0:0:13057) : updating network_id -> (0:12339:13057)
QAM_64 f = 690000 kHz I999B8C999D999T999G999Y999 (0:12339:13057) : updating original_network_id -> (8468:12339:13057)
updating transponder:
(QAM_64 f = 690000 kHz I999B8C999D999T999G999Y999 (8468:12339:13057)) 0x0000
to (QAM_16 f = 690000 kHz I999B8C23D0T8G4Y0 (8468:12339:13057)) 0x405A
698000: (time: 01:32.929)
706000: (time: 01:35.253)
714000: (time: 01:37.579)
722000: (time: 01:39.905) signal ok: QAM_64 f = 722000 kHz I999B8C999D999T999G999Y999 (0:0:0)
QAM_64 f = 722000 kHz I999B8C999D999T999G999Y999 (0:0:0) : updating transport_stream_id: -> (0:0:13313)
QAM_64 f = 722000 kHz I999B8C999D999T999G999Y999 (0:0:13313) : updating network_id -> (0:12340:13313)
QAM_64 f = 722000 kHz I999B8C999D999T999G999Y999 (0:12340:13313) : updating original_network_id -> (8468:12340:13313)
updating transponder:
(QAM_64 f = 722000 kHz I999B8C999D999T999G999Y999 (8468:12340:13313)) 0x0000
to (QAM_16 f = 722000 kHz I999B8C23D0T8G4Y0 (8468:12340:13313)) 0x405A
730000: (time: 01:42.681)
738000: (time: 01:45.006) signal ok: QAM_64 f = 738000 kHz I999B8C999D999T999G999Y999 (0:0:0)
QAM_64 f = 738000 kHz I999B8C999D999T999G999Y999 (0:0:0) : updating transport_stream_id: -> (0:0:12290)
QAM_64 f = 738000 kHz I999B8C999D999T999G999Y999 (0:0:12290) : updating network_id -> (0:12336:12290)
QAM_64 f = 738000 kHz I999B8C999D999T999G999Y999 (0:12336:12290) : updating original_network_id -> (8468:12336:12290)
updating transponder:
(QAM_64 f = 738000 kHz I999B8C999D999T999G999Y999 (8468:12336:12290)) 0x0000
to (QAM_16 f = 738000 kHz I999B8C23D0T8G4Y0 (8468:12336:12290)) 0x405A
746000: (time: 01:54.005)
754000: (time: 01:56.331) signal ok: QAM_64 f = 754000 kHz I999B8C999D999T999G999Y999 (0:0:0)
QAM_64 f = 754000 kHz I999B8C999D999T999G999Y999 (0:0:0) : updating transport_stream_id: -> (0:0:12546)
QAM_64 f = 754000 kHz I999B8C999D999T999G999Y999 (0:0:12546) : updating network_id -> (0:12337:12546)
new transponder: (QAM_16 f = 0 kHz I999B8C23D0T8G4Y0 (8468:12337:12545)) 0x405A
QAM_64 f = 754000 kHz I999B8C999D999T999G999Y999 (0:12337:12546) : updating original_network_id -> (8468:12337:12546)
updating transponder:
(QAM_64 f = 754000 kHz I999B8C999D999T999G999Y999 (8468:12337:12546)) 0x0000
to (QAM_16 f = 754000 kHz I999B8C23D0T8G4Y0 (8468:12337:12546)) 0x405A
762000: (time: 01:59.859)
770000: (time: 02:02.184)
778000: (time: 02:04.511)
786000: (time: 02:06.838)
794000: (time: 02:09.164)
802000: (time: 02:11.491)
810000: (time: 02:13.815)
818000: (time: 02:16.142)
826000: (time: 02:18.467)
834000: (time: 02:20.792)
842000: (time: 02:23.119)
850000: (time: 02:25.445)
858000: (time: 02:27.772)
tune to: QAM_16 f = 578000 kHz I999B8C23D0T8G4Y0 (8468:12338:12801) (time: 02:30.099)
service = SAT.1 Gold (ProSiebenSat.1)
service = ProSieben MAXX (ProSiebenSat.1)
service = TLC (MEDIA BROADCAST)
service = TELE 5 (MEDIA BROADCAST)
tune to: QAM_16 f = 586000 kHz I999B8C23D0T8G4Y0 (8468:12290:514) (time: 02:44.631)
service = ZDF (ZDFmobil)
service = 3sat (ZDFmobil)
...
Rechner, an dem übers Netz gemounted wurde:
w_scan
w_scan version 20140727 (compiled for DVB API 5.10)
guessing country 'DE', use -c <country> to override
using settings for GERMANY
DVB aerial
DVB-T Europe
scan type TERRESTRIAL, channellist 4
output format vdr-2.0
output charset 'UTF-8', use -C <charset> to override
Info: using DVB adapter auto detection.
/dev/dvb/adapter0/frontend0 -> TERRESTRIAL "Sundtek DVB-T (III) (192.168.2.102)": good :-)
Using TERRESTRIAL frontend (adapter /dev/dvb/adapter0/frontend0)
-_-_-_-_ Getting frontend capabilities-_-_-_-_
Using DVB API 5.10
frontend 'Sundtek DVB-T (III) (192.168.2.102)' supports
INVERSION_AUTO
QAM_AUTO not supported, trying QAM_64.
TRANSMISSION_MODE_AUTO
GUARD_INTERVAL_AUTO
HIERARCHY_AUTO
FEC_AUTO
FREQ (42.00MHz ... 1002.00MHz)
-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
Scanning DVB-T...
Scanning 7MHz frequencies...
177500: (time: 00:03.143)
184500: (time: 00:05.746)
191500: (time: 00:08.302)
198500: (time: 00:10.867)
205500: (time: 00:13.426)
212500: (time: 00:15.958)
219500: (time: 00:18.479)
226500: (time: 00:21.106)
Scanning 8MHz frequencies...
474000: (time: 00:23.667)
482000: (time: 00:26.229)
490000: (time: 00:28.788)
498000: (time: 00:31.355)
506000: (time: 00:33.908)
514000: (time: 00:36.464)
522000: (time: 00:38.991)
530000: (time: 00:41.709)
538000: (time: 00:44.718)
546000: (time: 00:47.441)
554000: (time: 00:49.970)
562000: (time: 00:52.549)
570000: (time: 00:55.099)
578000: (time: 00:57.671) signal ok: QAM_64 f = 578000 kHz I999B8C999D999T999G999Y999 (0:0:0)
Info: no data from PAT after 2 seconds
deleting (QAM_64 f = 578000 kHz I999B8C999D999T999G999Y999 (0:0:0))
586000: (time: 01:06.320) signal ok: QAM_64 f = 586000 kHz I999B8C999D999T999G999Y999 (0:0:0)
Info: no data from PAT after 2 seconds
deleting (QAM_64 f = 586000 kHz I999B8C999D999T999G999Y999 (0:0:0))
594000: (time: 01:15.017)
602000: (time: 01:17.552)
610000: (time: 01:20.086)
618000: (time: 01:22.649)
626000: (time: 01:25.215)
634000: (time: 01:27.769)
642000: (time: 01:30.327)
650000: (time: 01:32.891)
658000: (time: 01:35.453)
666000: (time: 01:38.013)
674000: (time: 01:40.571)
682000: (time: 01:43.125)
690000: (time: 01:45.685) signal ok: QAM_64 f = 690000 kHz I999B8C999D999T999G999Y999 (0:0:0)
Info: no data from PAT after 2 seconds
deleting (QAM_64 f = 690000 kHz I999B8C999D999T999G999Y999 (0:0:0))
698000: (time: 01:54.337)
706000: (time: 01:56.954)
714000: (time: 02:03.917)
722000: (time: 02:06.470) signal ok: QAM_64 f = 722000 kHz I999B8C999D999T999G999Y999 (0:0:0)
Info: no data from PAT after 2 seconds
deleting (QAM_64 f = 722000 kHz I999B8C999D999T999G999Y999 (0:0:0))
730000: (time: 02:09.276)
738000: (time: 02:11.902) signal ok: QAM_64 f = 738000 kHz I999B8C999D999T999G999Y999 (0:0:0)
Info: no data from PAT after 2 seconds
deleting (QAM_64 f = 738000 kHz I999B8C999D999T999G999Y999 (0:0:0))
746000: (time: 02:15.258)
754000: (time: 02:17.782) signal ok: QAM_64 f = 754000 kHz I999B8C999D999T999G999Y999 (0:0:0)
Info: no data from PAT after 2 seconds
deleting (QAM_64 f = 754000 kHz I999B8C999D999T999G999Y999 (0:0:0))
762000: (time: 02:26.530)
770000: (time: 02:29.109)
778000: (time: 02:31.665)
786000: (time: 02:34.229)
794000: (time: 02:36.787)
802000: (time: 02:39.347)
810000: (time: 02:41.918)
818000: (time: 02:44.528)
826000: (time: 02:47.308)
834000: (time: 02:49.904)
842000: (time: 02:52.457)
850000: (time: 02:55.025)
858000: (time: 02:57.556)
ERROR: Sorry - i couldn't get any working frequency/transponder
Nothing to scan!!
-
Wir werden es uns im Laufe der kommenden Woche ansehen (ab 26. Jan)
Diese Woche sind bei uns leider alle mit der Produktion beschäftigt.
Eventuell benutzt das neuere w_scan ein paar Befehle welche vom Netzwerktreiber noch nicht erkannt werden.
-
Eventuell benutzt das neuere w_scan ein paar Befehle welche vom Netzwerktreiber noch nicht erkannt werden.
die w_scan - Versionen sind identisch!
-
Aber der Netzwerktreiber ist ein "anderer" Treiber - nicht zu vergleichen mit dem direkten Treiber.
Wie erwähnt wir werden es demnächst überprüfen - diese Woche wird wohl die letzte stressige Woche sein. Danach werden wir uns voll und ganz der Weiterentwicklung der existierenden Produkte widtmen können.
-
hat sich das inzw. schon jemand angesehen?
-
kann ich noch eine Antwort erwarten, oder muss ich davon ausgehen, dass der Stick kein DVB-T über Netzwerk kann?
-
leider noch etwas Geduld, es ist nach wie vor auf der Liste ...
Wir arbeiten daran, nur leider sind wir derzeit so ausgelastet das sich einige Dinge etwas verzögern.
-
...und wieder 3 Wochen später...
wird an dem problem inzw. gearbeitet?
-
Hallo,
wir haben w_scan via Netzwerk getestet und es hat funktioniert, kannst Du dich eventuell via Skype (sundtek) melden?
-
ich habe kein skype
seid ihr sicher, dass ihr mit DVB-T getestet habt? (mit DVB-C habe ich kein Probem)
gerade nochmal mit den neusten Treibern getestet - es funktioniert nicht.
wenn der Stick mit DVB-C an einem anderen Rechner betrieben wird kann ich übers Netz scannen.
-
jetzt wird es strange: es hängt vom Rechner ab, an dem der Stick steckt.
wenn der Stick mit DVB-T an einem Raspi steckt, dann klappt der scan übers Netzwerk.
wenn der Stick mit DVB-T an einem Desktop (Opensuse 13.2/64bit) steckt, dann klappt der scan übers Netzwerk nicht.
woran kann das liegen?
-
Also der Server ist bei dir x86-64bit und der Client auch x86-64bit?
Ich weiß jetzt nicht mehr was wir getestet haben, es wurden aber sicherlich nicht alle Architekturen getestet.
-
Also der Server ist bei dir x86-64bit und der Client auch x86-64bit?
Server x86-64bit auf client x86-64bit (beides opensuse 13.2) ist die Kombination, die nicht funktioniert.
von Raspi auf Opensuse 13.2 x86_64 geht.
-
Hast du eine Firewall auf dem Server konfiguriert?
-
Hast du eine Firewall auf dem Server konfiguriert?
ja
Port 9234 TCP/UDP ist sowohl auf dem Client als auch auf dem Server offen
-
Damit hast du das Problem gefunden, es wird ein weiterer Port benötigt welcher während der Laufzeit allokiert wird, der Port wird zufällig ausgewählt. Der weitere Port ist für die Datenübertragung zuständig während der erste Port nur zur Steuerung des Geräts verwendet wird.
Bei dir wird somit der Datenport geblockt und es können keine Videodaten übertragen werden. Dadurch wird Kaffeine dann wohl auch hängen bleiben.
Ich dachte erst du hast ein anderes Problem, aber nach unseren Tests kann's dann wohl nur die Firewall sein. Wir werden das mit dem Port wohl erst im laufe des kommenden Monats ändern, dann wird nämlich auch der Windows Server freigegeben.
Also die Lösung ist vorerst -> Firewall ausschalten auf dem Server bzw. auf dem Client, dann klappt es.
TCP 9234 = Port für Kontrollbefehle (z.B Setze Frequenz, etc.)
TCP frei allokierter Port welcher gerade frei ist = Port für die Video-Datenübertragung
-
liegt der frei allokierte port in einem bestimmten Bereich?
-
Nein, wir fragen das System nur ab das es uns einen Port geben soll, der Port wird dann auch an die andere Seite übergeben.
Wiegesagt derzeit ist es besser die Firewall auszuschalten, eventuell können wir das schon kommende Woche anpassen.
-
das war's - es klappt
(fast - aber deswegen mach ich einen neuen thread auf)