Ich kenne die Situation auf Deinem Rechner nicht, ich hatte nur selber vor Kurzem das Vergnügen eines defekten Lüfters bei einem Notebook. Wenn das Notebook ein bißchen Last bekam ging die Performance in den Keller da die CPU langsam überhitzt wurde.
Beiträge von Sundtek
-
-
hier ein paar Befehle:
ls /sys/devices/system/cpu/
cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq
-
Eventuell ist der CPU Scheduler auf Ondemand eingestellt, je weiter die CPU runtergetaktet wird desto höher ist natürlich die Last aller Prozesse. +150% usw. kann da dann natürlich durchaus zustande kommen.
-
Du kannst den VDR durch den Sundtek Treiber neu starten.
Ich denke das war:
/etc/sundtek.conf
device_attach=service vdr restart # (oder service vdr restart in ein Skript stecken, und das ausführen).
bulknotification=on # dadurch wird device_attach soweit ich mich erinnere nur einmal ausgeführt sobald der gesamte Tuner Detection Cycle durchlaufen wurde
-
Kannst Du eventuell mal nen remote Zugang zu dem System bereitstellen?
Was ich da machen würde wäre ein kleines Testprogramm mit entsprechenden Filtern, vielleicht wird da irgendetwas gematched was im Filter eigentlich nicht gematched werden sollte. Wir haben einen eigenen Demuxer in der Software-Chain, der hat einige spezielle Features für spezielle Anwendungen.
Hat Das bei Dir sonst irgendwelche Nebenwirkungen?
Wenn ich hier einen EIT Filter auf diesen Transponder loslasse sehe ich keine Probleme (aber ich kenne halt auch nicht die genauen Filter Settings die VDR da loslässt und auf diese wird es ankommen).
-
SIGNAL: [ ] ( 0%) SATQUALITY: 0% SNR: 9 BER: 0 FREQ: 11817000 Hz LOCKED: NO SYS: DVB-S2 SYM: 29700000 FEC: FEC_2_3 MOD: PSK_8 VOLTAGE: V(13V) TONE: ON
SIGNAL: [ ] ( 0%) SATQUALITY: 0% SNR: 0 BER: 0 FREQ: 11597000 Hz LOCKED: NO SYS: DVB-S SYM: 22000000 FEC: FEC_5_6 MOD: QPSK VOLTAGE: V(13V) TONE: OFF
überprüfe mal was das für Transponder sind, vielleicht ist ja nur ein Parameter falsch. Die treten in der Logfile ein paar mal auf.
-
Lass mal /opt/bin/mediaclient --readsignal=0 -d /dev/dvb/adapterN/frontend0 --band universal
irgendwo mitlaufen und schreibe die Ausgabe in eine Datei, vielleicht wird ja umgeschalten oder neu getuned.
N natürlich die nummer des Adapters
-
Hast Du first_adapter=N in /etc/sundtek.conf eingetragen damit unsere Tuner nicht mit den anderen kollidieren?
-
Also, egal wen ich vorher starte... Sundtek schnappt sich die beiden ersten frontends...
Code
Alles anzeigenDez 30 20:16:05 server01 vdr[20513]: [20513] found 6 DVB devices Dez 30 20:16:05 server01 vdr[20513]: [20513] frontend 5/0 provides DVB-T,DVB-C,DVB-S,DVB-S2 with QPSK,QAM16,QAM64,QAM128,QAM256 ("vTuner proxyFE DVB-Multi") Dez 30 20:16:05 server01 vdr[20513]: [20536] device 6 section handler thread started (pid=20513, tid=20536, prio=low) Dez 30 20:16:05 server01 vdr[20513]: [20513] new device number 6 (card index 6) Dez 30 20:16:05 server01 vdr[20513]: [20513] creating cDvbDevice Dez 30 20:16:05 server01 vdr[20513]: [20535] frontend 4/0 tuner thread started (pid=20513, tid=20535, prio=high) Dez 30 20:16:05 server01 vdr[20513]: [20513] probing /dev/dvb/adapter5/frontend0 Dez 30 20:16:05 server01 vdr[20513]: [20531] frontend 3/0 tuner thread started (pid=20513, tid=20531, prio=high) Dez 30 20:16:05 server01 vdr[20513]: [20513] frontend 4/0 provides DVB-T,DVB-C,DVB-S,DVB-S2 with QPSK,QAM16,QAM64,QAM128,QAM256 ("vTuner proxyFE DVB-Multi") Dez 30 20:16:05 server01 vdr[20513]: [20529] device 4 section handler thread started (pid=20513, tid=20529, prio=low) Dez 30 20:16:05 server01 vdr[20513]: [20526] device 3 section handler thread started (pid=20513, tid=20526, prio=low) Dez 30 20:16:05 server01 vdr[20513]: [20532] device 5 section handler thread started (pid=20513, tid=20532, prio=low) Dez 30 20:16:05 server01 vdr[20513]: [20528] frontend 2/0 tuner thread started (pid=20513, tid=20528, prio=high) Dez 30 20:16:05 server01 vdr[20513]: [20513] new device number 5 (card index 5) Dez 30 20:16:05 server01 vdr[20513]: [20513] creating cDvbDevice Dez 30 20:16:05 server01 vdr[20513]: [20513] probing /dev/dvb/adapter4/frontend0 Dez 30 20:16:05 server01 vdr[20513]: [20513] frontend 3/0 provides DVB-T,DVB-C,DVB-S,DVB-S2 with QPSK,QAM16,QAM64,QAM128,QAM256 ("vTuner proxyFE DVB-Multi") Dez 30 20:16:05 server01 vdr[20513]: [20513] new device number 4 (card index 4) Dez 30 20:16:05 server01 vdr[20513]: [20513] creating cDvbDevice Dez 30 20:16:05 server01 vdr[20513]: [20513] probing /dev/dvb/adapter3/frontend0 Dez 30 20:16:05 server01 vdr[20513]: [20513] frontend 2/0 provides DVB-T,DVB-C,DVB-S,DVB-S2 with QPSK,QAM16,QAM64,QAM128,QAM256 ("vTuner proxyFE DVB-Multi") Dez 30 20:16:05 server01 vdr[20513]: [20513] new device number 3 (card index 3) Dez 30 20:16:05 server01 vdr[20513]: [20513] creating cDvbDevice Dez 30 20:16:05 server01 vdr[20513]: [20513] probing /dev/dvb/adapter2/frontend0 Dez 30 20:16:05 server01 vdr[20513]: [20525] frontend 1/0 tuner thread started (pid=20513, tid=20525, prio=high) Dez 30 20:16:05 server01 vdr[20513]: [20513] frontend 1/0 provides DVB-S2,DVB-S with QPSK ("Sundtek DVB-S/S2 (IV)") Dez 30 20:16:05 server01 vdr[20513]: [20524] device 2 section handler thread started (pid=20513, tid=20524, prio=low) Dez 30 20:16:05 server01 vdr[20513]: [20513] new device number 2 (card index 2) Dez 30 20:16:05 server01 vdr[20513]: [20513] creating cDvbDevice Dez 30 20:16:05 server01 vdr[20513]: [20513] probing /dev/dvb/adapter1/frontend0 Dez 30 20:16:04 server01 vdr[20513]: [20514] video directory scanner thread ended (pid=20513, tid=20514) Dez 30 20:16:03 server01 vdr[20513]: [20518] frontend 0/0 tuner thread started (pid=20513, tid=20518, prio=high) Dez 30 20:16:03 server01 vdr[20513]: [20513] frontend 0/0 provides DVB-S2,DVB-S with QPSK ("Sundtek DVB-S/S2 (IV)") Dez 30 20:16:03 server01 vdr[20513]: [20513] DVB API version is 0x050B (VDR was built with 0x050B) Dez 30 20:16:03 server01 vdr[20513]: [20517] device 1 section handler thread started (pid=20513, tid=20517, prio=low) Dez 30 20:16:03 server01 vdr[20513]: [20513] cTimeMs: using monotonic clock (resolution is 1 ns) Dez 30 20:16:03 server01 vdr[20513]: [20513] new device number 1 (card index 1) Dez 30 20:16:03 server01 vdr[20513]: [20513] creating cDvbDevice Dez 30 20:16:03 server01 vdr[20513]: [20513] probing /dev/dvb/adapter0/frontend0 Dez 30 20:16:01 server01 vdr[20513]: [20515] epg data reader thread ended (pid=20513, tid=20515) Dez 30 20:16:01 server01 vdr[20513]: [20515] reading EPG data from /home/media/records/epg/epg.data Dez 30 20:16:01 server01 vdr[20513]: [20513] detected /dev/dvb/adapter0/frontend0 Dez 30 20:16:01 server01 vdr[20513]: [20513] detected /dev/dvb/adapter1/frontend0 Dez 30 20:16:01 server01 vdr[20513]: [20513] detected /dev/dvb/adapter2/frontend0 Dez 30 20:16:01 server01 vdr[20513]: [20513] detected /dev/dvb/adapter3/frontend0 Dez 30 20:16:01 server01 vdr[20513]: [20513] detected /dev/dvb/adapter4/frontend0 Dez 30 20:16:01 server01 vdr[20513]: [20513] detected /dev/dvb/adapter5/frontend0
vdr startet mit dem LD_PRELOAD für die sundteks. vtunerc ist mit 6 devices geladen und mit satip sind die 6 devices zugewiesen. Am Ende hätte ich gerne 8 tuner
Du brauchst first_adapter=N in /etc/sundtek.conf das weist unserem Stack den ersten freien Adapter zu. N sollte die Nummer des ersten Adapters sein welcher von unserem Stack benutzt werden darf.
Grundsätzlich versucht der Stack abzuwarten bis andere Treiber geladen sind aber das ist halt nicht wirklich vorhersehbar wann was geladen wird deshalb die first_adapter Option.
-
Nur der Vollständigkeit halber: Es geht rein theoretisch auch ohne zusätzliches Kernel-Modul. Hier hat sich mal jemand damit befasst:
https://github.com/not1337/libsatip
Fragt aber nicht wie der Stand dort ist und wie sich das Projekt im Vergleich zum hier diskutierten "vtuner" schlägt. Technisch gesehen ist "CUSE" eine Schicht unter "FUSE". Während FUSE nur für Filesystem-Treiber gedacht ist kann mit CUSE ein beliebiges "Character-Device" aus dem User-Mode heraus erzeugt werden.
Zu Cuse - wir haben es mal getestet und es war instabil außerdem war's nicht überall per default verfügbar, mag sein dass es mittlerweile gefixt wurde aber zu der Zeit als wir es getestet haben war es unbrauchbar. Im Allgemeinen wäre es besser ein DVB Library zwischen device Nodes und Applikationen zwischenzuschieben dann wird der Code auch nahezu automatisch Betriebssystem-unabhängig.
Wir haben in unseren Treiber Hooks welche es erlauben die Transportstream Daten innerhalb der Treiberdomain an libraries weiterzuleiten und dann wieder in den Treiber zurückzuschleifen.
Soweit ich mich erinnere wurde das vor langer Zeit für ISDB-T in Japan implementiert, der Tuner empfängt die verschlüsselten Daten und der Transportstream wird im Treiberprozess direkt dekodiert.
Wenn jemand nen Sundtek Tuner hat, und sich dafür interessiert kann ich das Gerüst für so n Library gern mal ausgraben. Zudem das auch wieder Kernel-Version unabhängig ist.
-
Schätze gegen Januar werden die dann doch noch kommen, leider haben uns 2 ehemalige Mitarbeiter schwere Probleme bereitet. Es ist schade da viele Designs die Jahre über stecken geblieben sind.
Die Dual DVB-C Tuner sind ja nicht die einzigen die da entwickelt wurden.
-
Die überschreiben wohl read() und ioctl() per LD_PRELOAD mit ihrem Treiber blob, so dass all diese Funktionen erst durch ihren Treiber müssen.
Kostet Performance, da alle Anfragen jeder Software davon betroffen sind, nicht nur VDR und co. und ist eigentlich ein Sicherheitsrisiko, du vertraust damit diesem Software Hersteller, dass sie nichts gefährliches dort in ihren Funktionen machen.
Das kostet keine messbare Performance (wenn man was misst bemerkt man auch wie sich der CPU Verbrauch vom Kernel in das System zieht da der Demuxer als Applikation läuft), außerdem beschränkt sich die arbeitende Logik nur auf die DVB/Video Adapter, was anderes interessiert auch nicht.
Einige Systeme isolieren das auf die DVB Applikation an sich, das System ist flexibel gestaltet und der Installer hat da auch einige Optionen. Auch ist ein Streamingserver enthalten man muss nicht das V4L/DVB Layer benutzen wenn man nicht möchte.
Wer fleissig kompilieren will den hindern wir auch nicht, auch beeinflussen wir keine anderen Analog TV / Webcam oder DVB Treiber.
Wer ein abgesichertes System haben will muss sowieso Hand anlegen und sich auskennen (sprich man sollte verstehen was man macht, der wird es dann auch schaffen sich ein bißchen in die Treiberoptionen einzulesen).
Man kann gerade bei unserem Tuner auch direkt über API Calls oder einem Streamingserver auf den Tuner zugreifen (das machen auch einige Kunden), wie geschrieben der Installer hat da so einige Optionen.
Multimedia Treiber im Kernel zu benutzen ist auch nicht so ohne, jahrelang gab's irgendwelche Systemcrashes oder andere Probleme mit diversen anderen Geräten und Updates zu durchlaufen ist einfach zeitaufwändig.
Kernel-Treiber sind eine alte Technologie, mit der Zeit kam in Linux die Option mit Userspace Treiber hinzu während die Linux Media Maintainer damals ihre Grabenkämpfe hatten haben wir unsere Geräte bereits vollständig mit etlichen Features im Userspace integriert. Viele von denen damaligen Kernel-Entwicklern in dem Bereich sind über die Jahre hinweg ohnehin nicht übrig geblieben, sie haben sich einfach anderen Dingen gewidmet.
-
genau so schaltet man die Fernbedienung von den Sundtek Geräten ab - damit am PC keine Signale verarbeitet werden.
-
Ja ist möglich (auch wenn's schon länger her ist).
-
Melde dich dann einfach wenn Du soweit bist ich kann auch den Tuner via Anydesk oder ähnlichem auf Deinem System überprüfen.
Der Treiber hat eigentlich schon lange kein Update mehr benötigt, aber wer weiß.
Wird wohl irgendwo einen Parameter geben der feingetuned werden will.
-
Störungen sollte es nicht geben, wir haben den Tuner zuverlässig mit über 100Mbit pro Channel getestet (also über 200Mbit gesamt mit dem Tuner).
Sprich dich mit dem Support weiter ab, Du hast ja bereits Kontakt via Email aufgenommen.
Zuerst muss identifiziert werden woher die Störungen kommen, vom Signal-Eingang (SAT Anlage) oder während der Bearbeitung des Datenstroms (Tuner bis PC)
-
Bezüglich Bildstörungen bei DVB-C (sollte es denn Bildstörungen geben), oder gar eine Raspberry PI da hilft oft ein längeres USB Kabel. Zum Teil helfen auch Ringkerne um diverse Kabel.
Wichtig ist wenn es auftritt, die Signalstärke und BER auszulesen damit man mal Anhaltspunkte hat woran es liegen kann und welche Frequenzen überhaupt betroffen sind.
Mir ist eigentlich kein einziger Kunde bekannt der seine Kabelprobleme nicht in den Griff bekommen hat, im Allgemeinen haben eigentlich sehr wenige Probleme.
Bei älteren Installationen hilft es auch die Kabeldose auszutauschen.
-
Schalte die Logfile des Treibers ein
/etc/sundtek.conf
loglevel=max
Das zeigt mal an ob die Daten die via USB übertragen wurden in Ordnung sind
/var/log/mediasrv.log wäre der Output
Was nicht schaden würde wäre eine Statistik wie der RPI4 zu dem Zeitpunkt getaktet war (wie viel MHz).
Die Frage wäre auch was dort alles via USB dranhängt?
Eventuell auch einfach nur mal /opt/bin/mediaclient --readsignal=0 -d /dev/dvb/adapter0/frontend0 --band universal (adapterX wobei X für den Tuner steht) im Hintergrund mitlaufen lassen.
-
ERROR: can't open filter handle on '/dev/dvb/adapter1/demux0'
das zieht sich wirklich durch die gesamte Syslog Logfile.
Schalte eventuell mal die Logfile des Treibers ein (denke jetzt aber nicht dass dort ein Problem angezeigt wird).
/etc/sundtek.conf
logfile=max
In der Logfile steht üblicherweise /dev/dvb/adapterX/demux0, eventuell hast Du die Minor ID von den Demuxer Nodes nicht richtig durchgereicht?
läuft das Ganze in einem LXC Container?
Von den anderen Nodes sehe ich eigentlich keine Probleme (frontend0 / dvr0).
Wenn Du mir irgendwie remote Zugriff geben kannst kann ich mir das kurz mal direkt anschauen.
Im Laufe der nächsten Woche wird auch noch unser neuer Streamingserver freigegeben, sprich eher eine aktualisierte Version der vorigen Version, sollte dann auch einfach einzubinden sein.
-
Meine sehr alten sundtek USB Sticks hatten noch eine schlechte USB Anbindung, und sind eigentlich nicht mehr zu gebrauchen (sind aber wirklich schon sehr alt).
Meine Sundtek SkyTV Ultimate Dual ist im Produktivbetrieb. Funktioniert oft sehr gut, aber manche Aufnahmen haben dann super viele TS Fehler (mehr als 10000). Muss ich mal genauer analysieren. Ev. ist einer der 2 Tuner defekt.
Verwendest Du die aktuellen Treiber?
/opt/bin/mediaclient --loglevel=max
dann /var/log/mediasrv.log überprüfen, dort wird die Frequenz angegeben wo das Problem sein könnte.
Glaube kaum dass da ein Tuner defekt ist, die sind ziemlich robust.
Der Streamingserver für die Geräte wird in kürze mit SAT>IP erweitert, dann könnt ihr auch damit rumspielen.