Sundtek Support Forum

Wenn tvheadend verwendet wird bitte unseren Streamingserver deinstallieren.

rm /opt/bin/rtspd
killall -9 rtspd

Falls gewollt kann ich mir die Einstellungen in TVHeadend via Anydesk remote ansehen.

Ich denke TVHeadend hat aktuell auch einen Bug in den LNB Einstellungen, hin und wieder löschen wir bei den Kunden die Adapterkonfiguration manuell (das ist ein Verzeichnis in der TVHeadend Konfigurationsstruktur). Gerade bei Unicable-Konfigurationen ist mir das letztens aufgefallen.

Schätze das sind kleinere Konfigurationsprobleme die Du da derzeit hast.

Die Tuner können auch einzeln getestet werden:

/opt/bin/mediaclient --testastra -d /dev/dvb/adapter0/frontend0

adapter0 durch den jeweiligen Adapter im System ersetzen.

/opt/bin/mediaclient -e

/opt/bin/mediaclient --readsignal=0 -d /dev/dvb/adapter0/frontend0 sollte annähernd die selbe Signalqualität anzeigen.

Wir hatten letztens einen Kunden mit einem defekten Kabel, da die Tuner in seinem System zusammen konfiguriert wurden schlug die Aufnahme über den Tuner mit dem defekten Kabel fehl. Das lässt sich durch die oberen Befehle aber gut überprüfen.

Dieses Binary lies sich bei uns unter Catalina installieren:
https://sundtek.de/media/sundtek_driver_2020-11-24_02_42_26.pkg

Funktioniert die Installation auf Deinem System?

Aufgrund von negativen Reports bei Upgrades haben wir das Entwicklungssystem noch nicht aktualisiert (Black Screens...)

Der Streamingserver muss dort noch aktualisiert werden.

Hi,

ich habe leider keinen Einblick in die Bestellung die du getätigt hast, jedoch habe ich die Antwort erhalten dass Dir eine Email zugesandt wurde und es noch keine Antwort darauf gab? Die Bestellung ging wohl über namatek.com.tw.

----

Man hat mir die Mail von damals mittlerweile weitergeleitet, sie wird bei Dir wohl im Spam untergegangen sein. Ich habe sie mit Anmerkungen weitergeleitet.

Welcher Tuner ist das genau? (damit wir den Treiber zuordnen können). Dem System ist der DMA Speicher ausgegangen, was auch wieder mehrere Ursachen haben kann.

Eine mögliche Lösung bzw. Workaround wäre eventuell den von uns angeforderten Speicher zu verkleinern.
Mit der Zeit fragmentiert das System, der Speicher ist zwar vorhanden aber nicht mehr in einem Stück/durchgehend in der angeforderten Blockgröße.

Es kommt drauf an welchen Tuner Du da verwendest, da wir 3 verschiedene Haupttreiber im Paket haben gibt es bei allen drei geringfügig unterschiedliche Parameter.

/opt/bin/mediaclient -e

Bezüglich den Amlogic Boards mit SkyTV 6 gibt es zur Zeit keine weiteren Informationen

SkyTV 3 gab es bis ca. 2015
SkyTV 6 gab es bis ca. August 2018
SkyTV 8 gibt es seit ca. Oktober 2018

Die Tuner verwenden jeweils unterschiedliche Chipsätze, welche sich auch unterschiedlich verhalten.

SkyTV 8 und SkyTV Dual verwenden andere Chipsätze was das Problem eventuell lösen könnte.
SkyTV Dual hat zusätzlich einen sehr großen Puffer im FPGA um USB Jitter besser ausgleichen zu können

Das Problem bei dem betroffenen Amlogic Board wird durch einen Puffer-Überlauf im USB Chipsatz (SkyTV 4 - SkyTV 6) verursacht da der Host die DVB Daten nicht schnell genug abholt, oder genauer gesagt mit zu großem Jitter.
Wir haben dieses Problem auch bei FreeBSD bemerkt (dort scheint jedoch USB Stack mangelhaft zu sein, da das gleiche verwendete System mit Linux und Windows keine Probleme verursachte).

Was wir bei einigen Amlogic Boards bemerkt haben:
- Es funktioniert nur der OTG USB Port zuverlässig, andere USB Ports haben Daten verschluckt (auch bei USB Festplatten)

StarDuddle, von Deinem Problem fehlen aber Detailinformationen, wir wissen weder welches System du verwendest noch was Dein genaueres Problem ist.

I think that you have some setup problem with MythTV.

Did you consider using tvheadend with DVB-S/S2? I think that one is more recent and better.

The permissions are set so everyone has access to the DVB Tuner (which on a multimedia system is more or less the practical option).

Der Grund hierfür sind sehr viele Bugs in MUSL-Libc, wir haben ja nen Workaround Treiber installiert dort haben wir aber direkt auf die Kernel-Funktionen zugegriffen und nicht über MUSL-Libc.

- gettimeofday funktioniert nicht ordnungsgemäß
- clock_gettime funktioniert ebenfalls nicht ordnungsgemäß


Daher auch die Minus werte.
"Driver loaded within -910167276291050599 milliseconds"

Die Fehler scheinen im aktuellen MUSL-Libc Library gefixt zu sein, zum Teil wurden die Fehler aber auch erst Mitte 2020 gefixt und sind wohl noch nicht in dem Docker System enthalten.

Referenzen:
https://github.com/richfelker/musl-cross-make/issues/96
- time64 issue in simple program on 32-bit arm, linux 5.6

Die Probleme können so gefixt werden:
- aktuelle MUSL-C installieren (würde ich eventuell etwas schwierig einstufen)
- ein Docker System mit GNU Libc verwenden

Früher oder später wird sicherlich auch linuxserver.io die Images aktualisieren.