Posts by Sundtek

    Die Probleme sehen mir ein bißchen größer aus, und vor allem im Bereich des PAT Filters.


    (die ersten beiden IOCTLs wurden entfernt da sie nicht initialisiert ok sind (und mittendrinnen wurden auch einige entfernt um das 10.000 Zeichen limit nicht zu übersteigen):


    https://pastebin.com/inurDVwX



    ist da irgendetwas bekannt?

    Wüsste nicht was da bei dem Chat nicht klappen sollte.


    Wenn ich Zugriff habe kann ich anschauen was da gemacht wird (im VDR Code bzw. in unserem Treiber).


    Wir supporten (natürlich) auch nur die aktuelle Treiberversion, da diese allen zur Verfügung steht.

    Zwischen 2013 - 2021 sind die Unterschiede zu groß (vielleicht nicht im Treiber, aber im Framework).


    Nachtrag

    wie unterhalb erwähnt der Link, Kanal #sundtek

    Die CPU Auslastung ist immer etwas relativ, 80% von einem runtergetakteten System wäre jetzt nicht viel.


    Ansosnten einfach die Signalstatistiken mitlaufen lassen (die sind pro Transponder/Frequenz und nicht für den gesamten Satelliten):

    /opt/bin/mediaclient --readsignal=0 -d /dev/dvb/adapter0/frontend0 --band universal

    HelmutB Danke. Die retune Geschichte scheint gelöst, das 4098/4096 Problem ist nach wie vor da. Noch eine Idee? Ich schau selber auch mal in den Code um das zu verstehen, zumindest es zu versuchen.

    Wegen der Empfangsqualität weiß ich nicht, ob die wirklich schlecht ist.

    Der BER Wert z.B. geht nur beim Frequenzwechsel kurzzeitig hoch, sonst sehen alle Werte unverfächtig aus. Ist das normal?

    Wo wäre anzusetzen auf dem Weg von LNB - Kabel - Multischalter - Kabel - Sundtek - USB - Kabel - Server? Wobei ich nicht glaube, da viel verbessern zu können/müssen.

    Gruß Andreas

    Sind das passiv-Switches? bzw. der Tuner versorgt das Switch und den LNB mit Strom?

    Die SkyTV 4rer könnten bei so einer Nutzung eventuell Hitzeprobleme bekommen.

    Erst ab SkyTV 5 wurden andere LNB Spannungsversorgungen verwendet die mehr Strom liefern können.


    Andererseits könnte der LNB eventuell auch die Frequenzen shiften (je nachdem wie alt er ist), ich würde das Switch erst mal weglassen und den LNB direkt ansteuern.

    Ich habe mal begonnen die Pakete für experimental-main über amd64, armvh und arm64 hinweg bauen zu lassen bzw. die Architekturen einzugrenzen, wenn etwas nicht bau- bzw. Nutzbar ist: https://launchpad.net/~seahawk…/ubuntu/experimental-main


    Das ist lange noch nicht fertig (u.a. muss ich das Paket für den sundtek-Treiber überarbeiten, damit abhängig von der Architektur die passenden Dateien genutzt werden), aber eventuell hilft das dir schon mal weniger Pakete bauen zu müssen (für die ARM-Architekturen dauert das bei Launchpad im Vergleich zu amd64 immer deutlich länger).

    Du kannst ja auch unseren Installer direkt verwenden? Wenn Du irgendwelche Zusatzfeatures benötigst können wir das durchaus dort auch reinbauen.

    Die DD Treiber werden hauptsächlich von Ralph Metzler ( rjkm ) entwickelt.

    Wegen Ärger mit Mauro Chehab werden die aber schon lange nicht mehr eingereicht.

    nst hat es auf sich genommen, die DD Treiber auf der kernel-media Liste einzureichen.

    Vor 2 Jahren hatte er dann aber auch von Mauro genug.

    Sein git gibt es noch.

    Deshalb haben wir vor 12 Jahren bereits Treiber in's Userspace verfrachtet und das komplette Framework dort auch neu entwickelt um keine Abhängigkeiten mehr zu haben.

    Es brachte viele Vorteile mit sich, vor allem was die Kompatibilität anging. Ein Treiber Binary für Linux 2.6.16 (2006!)- 5.x, und neue Versionen müssen wir auch nicht beachten.

    Das Build System benötigt bei uns gute 5-10 Minuten um Treiber für X86, ARM, MIPS, PPC, SH4 (und deren verschiedenen Variationen) zu erstellen und zu deployen.


    Kunden starten einfach das (einmal heruntergeladene) Netinstall-Skript und das zieht sich immer den aktuellen Treiber, auf allen Architekturen.

    Und das gilt auch nach wie vor für 12 Jahre alte Tuner.

    Diverse Distributionen haben das Netinstall Skript auch integriert, oder greifen direkt auf die fertigen Treiber zu.

    Auch beisst sich die Geschichte nicht mit anderen Webcam/DVB Treibern die es im Kernel gibt, da wir die ja überhaupt nicht anrühren.


    Der Dual S2 USB Tuner ist n Tuner für die Hosentasche :-)

    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.

    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"



    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.

    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.