Posts by Sundtek

    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.

    Also, egal wen ich vorher starte... Sundtek schnappt sich die beiden ersten frontends...


    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.

    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.

    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.