Beiträge von mippi

Zitat von michael24179

Ich habe jetzt mal 8 Streams laufen lassen und auf eine dritte VU+ UHD aufnahmen aus dem NAS geschaut (NAS/TVH = ein Server).

Genau das meinte ich NICHT.

Bei mir war es kein Problem, 7 Aufnahmen zu machen und parallel mit GB Geschwindigkeit etwas von/auf das NAS zu kopieren (auch nicht wenn TVH im Docker auf dem NAS lief). Meine Problem zeigten sich dann, wenn 2 KODI Clienten an dem TVH Server schauten, und zwar so das der TVH praktisch die Daten Lokal vom NAS geholt hat und dann an die Kodi Clients gestreamt hat und nicht die Cleints die aufnahmen einfach direkt vom Aufnahmeordner abspielten.
Ich hatte allerdings auch nur eine Netzwerkkarte. Trotzdem, paralle Kopieroperation von anderen Rechnern im Netzwerk zum NAS haben nicht gestört. Deshalb habe ich auch Stunden gebraucht um zu kapieren, das es immer passiert wenn die Kids und ich gleichzeitig über die TVH Cleints in Kodi bestehende aufnahmen geschaut haben. Denn auch Live Streaming über Kodi haben die Aufnahmen nicht gestört.

Zitat von michael24179

EDIT: Ich habe wohl die fehlerquelle für das pixel Problem gefunden. Ich hatte unter dem Dach noch ein 4 Port Netzwerk HUB da ich noch ein Strom Messgerät dort betreibe. Ich habe den HUB jetzt entfernt und es läuft Pigelfrei seit gut 30 Minuten. Und dabei nutze ich derzeit alle 8 Tuner (Im Quad Modus). 4 Tuner im TVH und nochmal 4 auf 2 VU+ Receiver verteilt. Dabei habe ich überall HD Sender laufen wo Bandbreite ordentlich hoch ist. Nachher kommt der Megasat noch direkt an den Dlink Management Switch wo nochmal eine Verbesserung erwarte.

Ich empfehle dir, mal 3 Aufnahmen zu starten und Parallel dazu mindestens 2 Aufnahmen anzusehen (über zwei weitere KODI welche auf den TVH zugreift der gerade aufnimmt). Obwohl das nur ca. 5x 10 MBit sind, hat das bei mir schon zu deutlichen Datenfehlern in den Aufnahmen geführt. Ich hatte alles mit GB-LAN an einer FritzBox 6490 und alles andere deaktiviert und es ging trotzdem nicht.

Ich habe einen N3150 Onboard CPU, ein PicoPSU und die DD Cine 6.5 mit TVH, das läuft einwandfrei und benötigt nur 18W. Die DD Cine 6.5 wird jetzt gegen eine Max S8 getauscht, dann habe ich auch 8 Tuner.

Du hast ja eh schon einen Unicable Switch. Theoretisch könntest Du dir einfach einen Unicable 2 Switch dazu holen (oder den anderen austauschen) und eine günstige Unicable 2 TV Karte, dann kannst du bis zu 32 Tuner im TVH verwenden.
Oder wenn deine jetzige TV Karte schon Unicable 1 unterstützt, dann holst Du dir einen 2. Unicable Switch und hängst den an Deine Kaskade und daran deine TV Karte, dann hast Du auch 8 Tuner. Nur so als Idee.

Wenn ich wüsste, was der

Inverto 51510 IDLU-UST110-CUO1O-32P [Anzeige]

An Strom verbracht, hätte ich es vielleicht auch gemacht, aber ich glaube der braucht alleine schon 8 Watt. Vielleicht probiere ich das aber auch noch mal.

Das UDP Pakete sehr schnell verloren gehen, habe ich hier ja ausgiebig diskutiert und deswegen meinen SAT>IP Server auch wieder zurückgeschickt. Das ist für mich erst mal gestorben.

Und du bist Sicher, das Du die Ebenen LH,LV,HH,HV richtig verbunden hast? Bei mir musste ich z.B. Leitungen über Kreuz verbinden, weil die Reihenfolge am SAT>IP Server anderes war.

Also wenn das der ist:

https://www.amazon.de/Spaun-SUS-5581-SAT-UNiSEqC-Einkabel-Multischalter/dp/B008FPYR9M?tag=kodinerds04-21 [Anzeige]
dann geht es wohl darum, das dort Unicable (UNiSEqC) kaskadierbar ist.

Wenn Du, wie ich vermute, 1x8 eingestellt hast, dann kommen an 3 Ausgängen Signale wie an einem QUAN LNB (Oder Multischalter) heraus, für normale Sat-Reciever. Am Ausgang 2 kommt das Unicable Signal für bis zu 8 Unicable fähige Receiver an. Deswegen werden da 3 von Deinen 4 Tunern im Quad Modus laufen. Versuch mal alle 4 Tuner in TVH gleichzeitig in Betrieb zu nehmen, das wird nicht gehen.
Und deshalb wird im Quattro Modus auch nur die VL Ebene gehen, denn diese ist aktiven wenn weder 18V noch 22KHZ ausgewählt ist.

Im 3x3 Modus wird gar nichts gehen.

Und einen LH,LV,HH,HV Ausgang hat der gar nicht, deshalb auch kein Quattro.

Welcher Multischalter ist es denn? Im Quad Modus am Kaskadenausgang dürfte eigentlich gar nicht gehen.

Ich werden aus deinem Text nicht 100% schlau, vielleicht hast Du dich nur vertippt:

Zitat von michael24179

Dann aber wohl nur 4 Sender wie ich gelesen habe. Tvheadend hat jetzt 4 Tuner bekommen und ein hat meine VU+.

Am Quad hast Du erstmal nur 4 Tuner, das hat mit Sendern nichts zu tun, das können durchaus auch mehr sein.

Und wenn Du nur 4 Tuner hast, dann solltest Du bei TVH nur 3 Aktivieren und bei dem VU+ nur einen, sonst kommt es evtl. zu Konflikten.

Und was sagen denn die Statistiken in TVH (Datenfehler?).

Hi, 2x2 Karten hab ich ja schon, ich will ja mehr. Also heute mit DD telefoniert. Auch bei QUAD sind 8 Tuner möglich. Man muss das nur im Treiber festlegen, das man den Quad modus möchte. Geht das in dieser Version genauso?

http://cvh.libreelec.tv/LibreELEC/8.2_…-dvb-1.0.img.gz

Für Max S8 die Datei ddbridge.conf angelegen:
echo 'options ddbridge fmode=x' | sudo tee /etc/modprobe.d/ddbridge.conf
ersetze x mit der Nummer der verwendeten Betriebsart:

Betriebsarten für die Max S8:

• fmode=0: 4-Tuner-Modus(Interner Multischalter deaktiviert)
• fmode=1: Quad-LNB / normale Ausgänge des Multiswitches
• fmode=2: Quattro-LNB / Kaskaden Ausgänge des Multiswitches
• fmode=3: Unicable oder JESS LNB / Unicabel Ausgang des Multiswitch

Hm, ich glaube ich werde am Montag dort mal anrufen.

Warum schreibt DigitalDevices dann, das in Beiden Betriebsarten 8 Tuner nur 4 Kabel benötigen?

Sorry aber nochmal:

Im Betriebsmodus „Quad“, kann die Karte an Quad-LNBs oder 4er
Multischalter angeschlossen werden und unterstützt einen Satelliten.Bei
Nutzung eines Quattro-LNBs oder des Stammausgangs eines Multischalters
ist der Betriebsmodus „Quattro“ für einen Satelliten wählbar. (Beide
Betriebsarten benötigen für 8 Tuner nur 4 Kabel, dank integriertem
Multischalter)

Oder verstehe ich da etwas falsch?

Danke aber laut DD ,müsste diese auch am QUAD funktionieren:

Im Betriebsmodus „Quad“, kann die Karte an Quad-LNBs oder 4er Multischalter angeschlossen werden und unterstützt einen Satelliten.Bei Nutzung eines Quattro-LNBs oder des Stammausgangs eines Multischalters ist der Betriebsmodus „Quattro“ für einen Satelliten wählbar. (Beide Betriebsarten benötigen für 8 Tuner nur 4 Kabel, dank integriertem Multischalter)

Ist für mich insofern wichtig, da ich sonst irgendwie noch verhindern müsste das mein Multiswitch sonst in den StandBy geht. Zumindest durch den XORO 8100 am Stammausgang ist mein MS nicht aufgewacht.

EDIT: Wäre das dann diese hier:

http://cvh.libreelec.tv/LibreELEC/8.2_…-dvb-1.0.img.gz

Läuft das Libreelec eigentlich mit der MAX 8? In dem Link aus deiner Signatur habe ich kein konkretes "Läuft" gefunden.

Ich würde nämlich lieber die DD nehmen statt der TBS6909. Dei Leistungsaufnahme von bis zu 24W welche bei der TBS angegeben ist, schreckt mich etwas ab und vielleicht werden die Unicable-Optionen der DD ja noch mal für mich interessant.

Zitat von Skibi

1. Allerdings hat der Digibit nur 4 Tuner
2. Das Thema "PIDs" habe ich gar nicht verstanden: keine Ahnung was das sein soll und was man jetzt für einen Wert in TVH einstellen soll und ob das überhaupt eine Rolle spielt im Hinblick auf die vorher genannten Probleme...

Genau deshalb gebe ich auch auf und schicke das Teil zurück. Ich kann zum Glück noch Widerrufen.
4-Tuner = Zuwenig, der Digibit Verbarucht auch 9-18W. Mein Celeron N3150 (on Board CPU) verbraucht mit 4 Tunern (2 Digital Devices Karten) nur 25W. Ohne Tuner 17W. Dafür kann ich ihn aber auch gleich im "Sportzimmer" zum Kodi Schauen verwenden. Wahrscheinlich hole ich mir eine DigitalDevices 8 Tuner Karte:

https://digitaldevices.de/produkte/dvb-komponenten/max-s8/.

Die verbraucht nur 5w. Dann komme ich auf 22W. Evtl. nehme ich dann noch mal ein Stromsparendes aktuelles Mainboard mit nur 10W, die kosten auch nur 50-80€

Die Karten von DD sind zwar etwas teurer aber Langfristig schont es die Nerven. Mit der Kombination hatte ich nie Probleme, das läuft super.

Les dir am besten noch mal den Thread durch, der hat mir die Augen geöffnet was UDP und SAT-IP angeht:

Octopus Net im Zusammenspiel mit TVHeadend

Vielleicht probiere ich es in ein Paar Jahren noch mal, wenn es HArdware gibt, die SAT-IP über TCP beherrscht.

Zitat von CvH

"Willkommen" im Sat>IP Land wo das nur durch Sat>IP over TCP zu lösen geht.

Ist es möglich zwei TVH mit Sat>IP over TCP zu verbinden, so dass ich die Tuner einfach an einen anderen TVH über TCP weiter leite?

Zitat von don

Kopieren ist CPU-Intensiv und auch RAM-belastend.
Soll man nicht meinen, aber das ist der Flaschenhals.

Nun, den verdacht hatte ich auch. Deshalb habe ich auch etliche Tests gemacht. Ich gebenun nach etlichen Stunden auf und schick das Teil zurück.

Zuletzt habe ich sogar einen neuen TVH auf einem anderen Rechner installiert. Das Ergebnis war immer das gleiche.

Ich kann problemlos 7 Streams aufnehmen, ohne das es zu Datenfehlern kommt. Aber selbst wenn ich nur 2 Aufnehme, und dann gleichzeitig 2 bereits bestehende Aufnahmen über den TVH server schaue (er muss sich ja dann die Daten von dem NAS Server holen und an die Client weitergeben) kommen bei allen laufenden Aufnahmen Datenfehler. Es ist also noch nicht mal nötig, das ich Große Dateien kopiere es reichen schon 2 Streams mit je 12MBits um das SATIP/UDP zu stören. Ich habe echt alles probiert. Der Standalone TVH server ist ein N3150 /1.6 GHz mit GigaBit Lan. Mit den eingebauten DigitalDevices gibt es 0 Probleme.

Für mich ist das Experiment "SAT>IP" erst mal beendet.

Ich denke ich habe das Problem gelöst. Ich darf den TVHeadend nicht auf dem QNAP NAS Installieren, denn sobald dieser in Kopieroperationen verwickelt wird, kommen die UDP Pakete nicht mehr durch.
Das gleiche Passiert, wenn ich den TVH Server (ohne Docker) Standalone habe und von dem gleichen Server große Dateien kopiere. Trotz Gigabit LAN. Wenn ich aber von dem Standalone TVH Aufnahmen starte (auf den Freigabeordner vom NAS) und im gleichen Netzwerk mit einem anderen Rechner große Dateien auf das NAS kopiere stört sich das nicht.
Deshalb ist TVH im Docker auf dem NAS nicht möglich, da es Probleme gibt, wenn man doch mal etwas mehr kopiert.

Ich bin jetzt etwas weiter.

Wenn ich mit meinem TVHeadend im Docker Container eine Aufnahme laufen habe, und gleichzeitig von meinem anderen Librelec Daten auf eine SMB Freigabe des QNAP speichere, kommen massive Datenfehler. Das passiert nicht wenn ich das von einem Windows Rechner mache.

Die Freigabe habe ich in Librelec so gemountet:

What=//192.168.0.2/Recordings/Kinderfilme
Where=/storage/recordings/Kinderfilme
Options=username=tvheadend,password=tvhead123,rw,vers=3.0
Type=cifs

Ich hatte es zuerst mit vers=1.0 laufen, hab es aber auf 3.0 geändert. Ich denke damit ist das SMB Protokoll 3 gemeint. Aber es läuft immer noch nicht.

Vielleicht hat ja noch jemand eine Idee.

Zitat von d1dd1

Ja ich nutze 3 & 4, mit dem DVBViewer habe ich auch Bild. Ich werd morgen mal noch 2 Kabel vom Multiswitch ziehen und prüfen ob das Problem im Mode Quattro verschwindet.

Hi, scheinbar gibt es generell ein Problem mit der Firmware. Der MEG IP Server 3 hat die Gleiche Firmware und das geliche Problem:

Megasat SAT>IP Server 3 / Tvheadend 4.1.2437
(Am besten aber den Thread von Anfang an lesen)

Denk darann, das Du bei einem Mutlischalter QUAD im XORO einstellen musst, nicht QUATTRO. Es sei denn Du hast am Mutischalter einen Kaskadenausgang/Durschschleifung an dem HV,HH, LV und LH getrennt ankommen.

Hallo,

bei dem Xoro must Du (entgegen der Intution) das LNB im Twin-Mode auch an RF4 und RF3 anschließen (nicht das du versuchst die Eingänge RF1 und RF2 zu benutzen).
Ich selbst benutze die Quattro Konfiguration, da ich alle 4 Eingänge mit HH,HV,LH,LV einspeise.

Zitat von Skibi

Ich nutze Version 4.4.20170707 auf meiner Synology-NAS.

Nutzt Du das eigentlich in einem Docker Container?

Bei meinem QNAP im Docker funktioniert es nach wie vor noch nicht. Mit einem dedizierten Server mit Librelec und TVH 4.2 läuft es, aber mit dem QNAP und Docker geht es acuh mit der neusten TVH nicht. Ich habe schon versucht die UDP Buffer zu erhöhen (sysctl -w net.core.rmem_max=26214400), aber nach wir vor kommen folgende Fehler:

2017-10-29 18:59:14.133 [ TRACE]:satip: RTP discontinuity (34621 != 34625), queueing packet
2017-10-29 18:59:14.133 [ TRACE]:satip: RTP discontinuity (34621 != 34626), queueing packet
2017-10-29 18:59:14.134 [ TRACE]:satip: RTP discontinuity (34621 != 34627), queueing packet
2017-10-29 18:59:14.135 [ TRACE]:satip: RTP discontinuity (34621 != 34629), queueing packet
2017-10-29 18:59:14.135 [ TRACE]:satip: RTP discontinuity, reset sequence to 34622 from 34621
2017-10-29 18:59:14.135 [ TRACE]:satip: RTP discontinuity (34621 != 34630), queueing packet
2017-10-29 18:59:14.135 [ TRACE]:satip: RTP discontinuity, requeueing packet (34622)
2017-10-29 18:59:14.135 [ TRACE]:satip: RTP discontinuity, reset sequence to 34624 from 34623
2017-10-29 18:59:14.135 [ TRACE]:satip: RTP discontinuity (34623 != 34631), queueing packet
2017-10-29 18:59:14.135 [ TRACE]:satip: RTP discontinuity, requeueing packet (34624)
2017-10-29 18:59:14.135 [ TRACE]:satip: RTP discontinuity, requeueing packet (34625)
2017-10-29 18:59:14.135 [ TRACE]:satip: RTP discontinuity, requeueing packet (34626)
2017-10-29 18:59:14.135 [ TRACE]:satip: RTP discontinuity, requeueing packet (34627)
2017-10-29 18:59:14.136 [ TRACE]:satip: RTP discontinuity (34628 != 34632), queueing packet
2017-10-29 18:59:14.136 [ TRACE]:satip: RTP discontinuity (34628 != 34633), queueing packet
2017-10-29 18:59:14.137 [ TRACE]:satip: RTP discontinuity (34628 != 34634), queueing packet
2017-10-29 18:59:14.137 [ TRACE]:satip: RTP discontinuity, reset sequence to 34629 from 34628
2017-10-29 18:59:14.137 [ TRACE]:satip: RTP discontinuity (34628 != 34635), queueing packet
2017-10-29 18:59:14.137 [ TRACE]:satip: RTP discontinuity, requeueing packet (34629)
2017-10-29 18:59:14.137 [ TRACE]:satip: RTP discontinuity, requeueing packet (34630)
2017-10-29 18:59:14.137 [ TRACE]:satip: RTP discontinuity, requeueing packet (34631)
2017-10-29 18:59:14.137 [ TRACE]:satip: RTP discontinuity, requeueing packet (34632)
2017-10-29 18:59:14.137 [ TRACE]:satip: RTP discontinuity, requeueing packet (34633)
2017-10-29 18:59:14.137 [ TRACE]:satip: RTP discontinuity, requeueing packet (34634)
2017-10-29 18:59:14.137 [ TRACE]:satip: RTP discontinuity, requeueing packet (34635)

2017-10-29 18:59:14.196 [ TRACE]:satip: RTP discontinuity (34662 != 34663), queueing packet
2017-10-29 18:59:14.197 [ TRACE]:satip: RTP discontinuity (34662 != 34664), queueing packet
2017-10-29 18:59:14.197 [ TRACE]:satip: RTP discontinuity (34662 != 34665), queueing packet
2017-10-29 18:59:14.198 [ TRACE]:satip: RTP discontinuity (34662 != 34666), queueing packet
2017-10-29 18:59:14.198 [ TRACE]:satip: RTP discontinuity (34662 != 34667), queueing packet
2017-10-29 18:59:14.199 [ TRACE]:satip: RTP discontinuity (34662 != 34668), queueing packet
2017-10-29 18:59:14.199 [ TRACE]:satip: RTP discontinuity, reset sequence to 34663 from 34662
2017-10-29 18:59:14.199 [ TRACE]:satip: RTP discontinuity (34662 != 34669), queueing packet
2017-10-29 18:59:14.200 [ TRACE]:satip: RTP discontinuity, requeueing packet (34663)
2017-10-29 18:59:14.200 [ TRACE]:satip: RTP discontinuity, requeueing packet (34664)
2017-10-29 18:59:14.200 [ TRACE]:satip: RTP discontinuity, requeueing packet (34665)
2017-10-29 18:59:14.200 [ TRACE]:satip: RTP discontinuity, requeueing packet (34666)
2017-10-29 18:59:14.200 [ TRACE]:satip: RTP discontinuity, requeueing packet (34667)
2017-10-29 18:59:14.200 [ TRACE]:satip: RTP discontinuity, requeueing packet (34668)