Korrekte Einstellungen Digibit R1

Also mit meinem Unicable LNB hatte ich bei jedem Tuner nur die erste Position aktiviert.

Ich hab das genau wie du auf dem Screenshot eingestellt. Hab seit langem auch nur noch ein normales Quad LNB. Deine Einstellung ist also in Ordnung und funktioniert bei mir seit Jahren fehlerfrei mit X Clienten, Aufnahmen, pedictive Tuning usw usw..

Die "Positionen" entsprechen verschiedenen SATELLITEN-Positionen. Ich hatte bis vor kurzem zwei LNBs an meiner Schüssel. Einer war auf Astra 19.2E ausgerichtet, der andere auf 28.2E. Beide LNBs waren an einen Multischalter angeschlossen. Wenn Du nun einen Sender tunen möchtest, muss der Tuner wissen, welchen LNB er tunen soll. Das passiert mit Diseq Commands. Ist wie eine Weiche. In der Config entsprecht AA dem ersten LNB/Satellit (bei mir mit dem 19.2E Network verknüpft), AB dem zweiten (bei mir mit 28.2E verknüpft), etc.

Wenn Du nur einen LNB dranhängen hast, brauchst Du die AB, etc. Positionen also nicht. Ob, und wie viele Positionen angezeigt werden, lässt sich konfigurieren. Und zwar wenn Du auf den Tuner klickst unter "Satellite config": Bei "Universal LNB" erhältst Du nur eine Position, bei "2-port switch" zwei, und bei "4-port switch" vier. Letzteres ist der Default.

Schaden tun die "Extra-Position" aber auch nicht: Egal ob bei den "nicht-belegten" Satelliten-Positionen ein Netzwerk zugeordnet ist, oder nicht, der Tuning-Prozess läuft ins Leere (Du nimmst auf der Weiche halt die falsche Abzweigung). Alle Services, die im Sendersuchlauf gefunden werden, werden aber mit der "richtigen" Position verknüpft, und hinterher richtig abgerufen. Du nimmst auf der Weiche also einfach immer den gleichen, richtigen Zweig.

Fazit: Super hilfreich, wenn man mehr als einen LNB dran hat. Ansonsten: Wurst. Wenn's läuft, einfach laufen lassen...

Hier meine Konfiguration für den gleichen Anwendungsfall:
4x DVB-S2 von einem Quad-LNB bzw. einem Quattro-LNB mit Multischalter. Einzige SAT-Position ist Astra 19.2 E

nur für Tuner #1 sind "Over-The-Air-EPG" "Initiale Suche" und "Leerlaufsuche gesetzt!

Die Prioritäten der Tuner #3 und Tuner #4 sind dann entsprechend auf 20 bzw. 10 gesetzt.

Die Parameter für die Positionen #1 (AA) unter Tuner #3 und Tuner #4 sind die gleichen.

Mein Digibit R1 läuft mit SATIP-AXE-Firmware weil ich die Konfiguration einfach schlanker und moderner fand.
Ich habe die aktuellste Version von hier laufen:
Build 18 (Jul 11 2021)

Hier noch meine config.zip für SATIP-AXE

Bitte nach /etc/sysconfig kopieren.

Die von dir verlinkten Einstellungen habe ich ebenfalls angepasst und konnte keinerlei Nachteile damit feststellen. Ich meine sogar, dass die Umschaltzeiten dadurch besser geworden sind.

Ich habe den Docker-Container linuxserver/tvheadend unter Unraid am laufen.
Dabei habe ich eine zusätzliche Variable hinzugefügt damit TVH den Digibit zuverlässig findet. Solange die im gleichen Subnetz sind sollte das aber auch ohne problemlos funktionieren

--http_root /tv --satip_xml http://10.20.20.71:8080/desc.xml

Ich habe lange recherchiert und Informationen zusammengetragen. Das hier erscheint mir als das optimale Setup für diesen Anwendungsfall.

Zitat von Commerzpunk

Nach einiger Zeit ist kein SAT Empfang mehr möglich, ich muss dann den Digibit neu starten

Der Fehler dürfte daher kommen, dass in der Standardkonfiguration auf mehr als einem Tuner der Leerlaufscan und OTA-EPG aktiv ist.
Zwei gleichzeitig sollen wohl auch noch gehen hab ich gelesen, aber mir erschließt sich nicht warum man das auf mehr als einem Adapter aktiv haben sollte.

Schnellschuss aus der Erinnerung heraus:

1 Tuner macht EPG und initiale und Leerlaufsuche
3 Tuner Programme gucken

da gibts irgendeine Hardwaresache, Kiste wird instabil, wenn alle 4 Tuner suchen

jedenfalls diese Variante in den Einstellungen ist richtig stabil. Verwende ausserdem tcp

Zitat von bylderup

Verwende ausserdem tcp

Das hatte ich auch schon überlegt.
Gab es einen bestimmten Grund weshalb du das so eingestellt hast?

Noch als Ergänzung zu den Einstellungen aus meinen Screenshots vorhin:
Ich habe Leerlaufsuche, Initialen Scan und Scan-over-Air-EPG jetzt auf den Tuner #4 gelegt, da dieser die niedrigste Priorität hat und somit häufiger frei ist für diese Aufgaben.

Zitat von psychofaktory

Das hatte ich auch schon überlegt.
Gab es einen bestimmten Grund weshalb du das so eingestellt hast?

RTMP benutzt UDP, welches im Gegensatz zu TCP (welches zwingend auf die korrekte Übertragung der Daten per Rückantwort setzt) auch Datenpakete verwerfen kann. Das kann in schlecht belüfteten Netzwerken (WLAN z.B) zu Datenverlusten und damit Bildfehlern kommen.

Ja, das ist mir bekannt.
Dadurch hat UDP aber auch den Vorteil schneller zu sein.
Mein Netzwerk ist gigabitfähig und stabil.

Macht es da trotzdem Sinn auf TCP zu setzen?

Nein. Wenn der Durchsatz stimmt und die Switches dazwischen (sofern vorhanden) nicht zicken, kannst Du ruhig bei UDP bleiben.

TCP klappt m.W. auch nur mit der Sat-IP-AXE Firmware von @perexg. Und die muss dann auch noch entsprechend konfiguriert werden (per Flag für minisatip).

gern

ich muss aber noch mal kurz den KlugSchieter modus anwerfen. Wegen TCP / UDP

...also, wenn keine Ruckler und Probleme da sind, braucht man nix umstellen, ist ein guter Tip!

Ob schneller oder nicht, ist hier völlig Nebensache. Entscheidend ist, so wenig, wie möglich Frame dropping / CRC Fehler zu haben, damit nichts ruckelt.
(Deshalb ist Streamen über WLAN immer so eine Sache)

Im Zweifelsfalle ist eine stabile 100 MBit LAN verbindung vom Endgerät (!) zum Switch die bessere Wahl als eine Gigabit Leitung mit KAT7 Billigkabel aus dem Dschungel, die aber massiv CRC Fehler verursacht.

Verfummelte Einstellungen mit Qos mögen viele Geräte auch nicht so gern. Ich hab TCP an, weil im Smart Home LAN ne Menge los ist.
Und bei meinen netgear prosafe Switchen kann ich gut sehen, wo Leitungs/Verbindungsprobleme sind ( das können andere Geräte sicher auch, soll keine Werbung sein).

Nicht jeder Hersteller hält sich bei jedem Gerät an die Normen bei seinen Schnittstellen.

Wegen seiner 4 Tuner sollte der digibit ein gutes LAN Kabel mit Gigabit Verbindung zum Switch haben.
TCP kann durchaus hilfreich sein, heilt aber keine groben Hardware Sünden.

Beispielhaft, falls erlaubt und wen es interessiert, im vuplus forum gabs für die solo deshalb vor Jahren eine 11 Seiten Diskussion crc-fehler-auf-lan-schnittstelle

Manchmal sind es auch ganz banale Dinge, die zum Ruckeln führen : z.B. Gerät zu warm
Und das alte Taschenradio mit Mittelwelle ist immer noch gut, um daheim störende Netzteile zu finden..

KlugSchieter modus aus..