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.
Eine Möglichkeit den VDR zu initialisieren sobald der Tuner verfügbar ist:
/etc/sundtek.conf
device_attach=service vdr restart
Display MoreDas war wohl ein Aprilscherz
Mein im Februar getätigte Bestellung wurde wohl storniert. Zumindest gab es eine PayPal Rückzahlung.
Kommentarlos, auf direkte Nachfrage gab es auch keine Antwort.
So wie ich das sehe gibt es nicht wirklich alternative dual DVB-C Hardware...
Offtopic zuende.
So langsam nerven mich die Störungen/Klötzchen im Bild!
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.
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"
Display MoreHallo Helmut,
ich kann hier ähnliches berichten.
Der Matrix VDR mit einer FFHD6400 erzeugt nicht so viele Diseqc-re-send Befehle, als der RaspberryPi mit USB-DVB-Tuner.Beide VDR’s waren heute knapp 6h mit EPG-Scan aktiv, Resultat siehe unten.
Aber der Patch funktioniert sehr gut!Man bekommt kein Blackscreen, wenn es mal beim zappen zum „re-send Diseqc“ kommen sollte.
Vielen Dank für den Patch an HelmutB und kls !
Code
- Apr 15 12:54:55 raspberrypi vdr: [771] frontend 1/0 did not switch to transponder 111053 for channel 16 (ONE HD) - re-sending SCR command
- Apr 15 13:55:46 raspberrypi vdr: [771] frontend 1/0 did not switch to transponder 111362 for channel 2 (ZDF HD) - re-sending SCR command
- Apr 15 14:49:03 raspberrypi vdr: [769] frontend 0/0 did not switch to transponder 211971 for channel 41 (MTV) - re-sending SCR command
- Apr 15 14:51:19 raspberrypi vdr: [769] frontend 0/0 did not switch to transponder 211347 for channel 14 (ZDFinfo HD) - re-sending SCR command
- Apr 15 16:12:15 raspberrypi vdr: [771] frontend 1/0 did not switch to transponder 111362 for channel 2 (ZDF HD) - re-sending SCR command
- Apr 15 16:12:50 raspberrypi vdr: [771] frontend 1/0 did not switch to transponder 111493 for channel 1 (Das Erste HD) - re-sending SCR command
- Apr 15 16:15:14 raspberrypi vdr: [771] frontend 1/0 did not switch to transponder 112226 for channel 34 (Eurosport 1 Deutschland) - re-sending SCR command
- Apr 15 16:21:51 raspberrypi vdr: [771] frontend 1/0 did not switch to transponder 111302 for channel 11 (ServusTV HD Deutschland) - re-sending SCR command
- Apr 15 18:49:30 raspberrypi vdr: [771] frontend 1/0 did not switch to transponder 112460 for channel 10 (SIXX) - re-sending SCR command
- Apr 15 19:08:07 raspberrypi vdr: [771] frontend 1/0 did not switch to transponder 112188 for channel 4 (RTL Television) - re-sending SCR command
Code
- Apr 15 14:37:30 matrix-vdr vdr: [797] frontend 1/0 did not switch to transponder 111053 for channel 16 (ONE HD) - re-sending SCR command
- Apr 15 16:59:22 matrix-vdr vdr: [797] frontend 1/0 did not switch to transponder 211624 for channel 39 (CNN Int.) - re-sending SCR command
- Apr 15 17:20:05 matrix-vdr vdr: [797] frontend 1/0 did not switch to transponder 111302 for channel 11 (ServusTV HD Deutschland) - re-sending SCR command
- Apr 15 19:03:55 matrix-vdr vdr: [797] frontend 1/0 did not switch to transponder 111362 for channel 2 (ZDF HD) - re-sending SCR command
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.
Muss sagen ihr habt da wirklich eine gute Arbeit geleistet 
Schöne Ostern dann noch!
transport_stream_id = bitstream_getbits(bs, 16);
Teil der SDT Tabelle. Es heißt auch transport_stream_id in der Spezifikation.
https://www.etsi.org/deliver/e…_60/en_300468v010301p.pdf
5.2.3 Service Description Table (SDT)
service_description_section(){
table_id 8 uimsbf
section_syntax_indicator 1 bslbf
reserved_future_use 1 bslbf
reserved 2 bslbf
section_length 12 uimsbf
transport_stream_id 16 uimsbf
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.
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.
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.
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:
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...
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.
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).
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)
Unsere Dual DVB-C Tuner werden wie es derzeit aussieht ab Donnerstag kommender Woche verfügbar sein. Sie verwenden von der USB Seite her die gleiche Technologie wie die Dual DVB-S/S2/S2X Tuner sprich das gleiche FPGA Design, und auch sehr große Hardware-Puffer.
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.
hmm vielleicht hab ich mich da verschaut... werde das mal mit Uwe abklären. Eventuell liegt's an seiner diseqc.conf.
Werde es mir morgen remote anschauen woher die Anfrage kommt.
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.
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)
Ich betreibe meinen Rotor mit einem Sundtek-USB-DVB-S2-Stick an einem Raspberry PI.
Das klappt stabil. Ich denke, dass die externe Stromversorgung vom Sundtek-Stick vorteilhaft für die Stabilität ist.
Das Netzteil wird bei unseren DVB-S/S2/S2X Tunern nur zur Stromversorgung der LNBs verwendet, bei den Single Tunern reicht eventuell auch die Stromversorgung des USB Ports für den LNB aus. Die Dual Tuner benötigen zwingend das 12V Netzteil.
Da würde wohl eine Slotblende mit Mutter für die F-Buchse ausreichend sein, von den Muttern hätten wir aktuell schon genug auf Lager.
Werd's mal aufnehmen und nächste Woche mit den Kollegen besprechen damit wir da was in den Shop geben.
