Beiträge von fnu

der-brumm-baer schrieb:

da der Server im Keller steht und auch ein Sat Kabel bis dort unten geht, und somit ein Gerät weniger vor sich hin läuft.

Hmm, dann bau doch die MaxS8 in den Octopus Net, das Gerät läuft sparsam vor sich hin ...

Nach den ganzen Jahren bin ich immer noch noch sehr zufrieden mit meinem Octopus Net @ MaxS8. SAT>IP ist einfach fantastisch flexibel, muss bei keinem Gerät Rücksicht auf eine PCIe Karte nehmen ... ok, die verteile trotzdem auf den Dosen per SCR ...

der-brumm-baer schrieb:

06. Kann ich die Dämpfung irgendwie bestimmen?

Für Lichtwellen-Leiter sind mir derartige Geräte bekannt, aber für Koax-Leitung kann ich mich nicht dran erinnern. Man kann es vmtl. berechnen, wenn alle Details bekannt sind, aber ich würde das auf mich zukommen lassen.

Sicher hat man einige Meter Kabel im Haus verlegt, die auch Ihre Dämpfung haben, abhängig von Frequenz und Länge. Aber bei Dir ist das eine Stern-Verkabelung und sind offensichtlich kein 100m oder so und mehr ...

Meiner Meinung nach haben alle zwischen geschalteten Dinge, Dosen, Verteiler, Verlängerungsstücke, mehr Einfluss auf die Dämpfung als ein längeres Kabel.

der-brumm-baer schrieb:

07. Was ist die Maximale Dämpfung?

Ob man das wirklich spezifizieren kann, keine Ahnung, jeder Abnehmer/Empfänger hat da vmtl. seine eigenen Grenzen. In moderneren Installationen werden sogar Dämpfungselemente eingebaut, um die Empfänger zu schützen.

der-brumm-baer schrieb:

08. Lässt sie sich beeinflussen?

An Deinen fest verlegten Kabeln nicht, nur bei der Auswahl der Verteilungs-Hardware, Dosen, Verteiler, Zwischenstücke, hier auf niedrige Werte achten. Aber Deine Verkabelung hat seither funktioniert, Deine Dosen auch und der 6er Verteiler hat mit 14dB(?) einen guten Wert.

Alternativ den Quattro-LNB behalten und einen Unicable® Multiswitch einbauen. Hat m.E. auch Wartungs-technisch Vorteile, der SCR LNB konzentriert doch alles arg auf einen Punkt.

Regards

fnu

der-brumm-baer schrieb:

01. Kann ich die alte Verkabelung beibehalten vom LNB zum Verteiler beibehalten?

Mein Meinung solltest Du keine Probleme haben. EN50494 (aka Unicable®) bzw. EN50607 (aka JESS) sind ja darauf ausgelegt die Möglichkeiten bestehender Infrastruktur zu erweitern.

der-brumm-baer schrieb:

02. Können alte Sat Dosen bestehen bleiben?

Auch hier meiner Meinung nach ja, s.o., sind ja vorher End-Dosen und bleiben nachher auch End-Dosen.

der-brumm-baer schrieb:

03. Klappt das so mit dem Octopusnet, zumindest eine Konfiguration von Unicable ist im WebIF vorgesehen?

Ja, Octopus Net läuft perfekt mit EN50494 und EN50607.

der-brumm-baer schrieb:

04. Müssen die Widerstände sein?

Widerstände an den ungenutzten Ausgängen des 1-in-6 Verteilers wären durchaus empfehlenswert. Gibt aber sicher sehr viele Nutzer die das eben nicht machen und auch wenig/keine Probleme haben ...

der-brumm-baer schrieb:

05. Irgendwelche sonstige bedenken oder Anmerkungen?

Naja, warum willst Du den Octopus Net zu Gunsten einer MaxS8 im Server abschaffen?

Regards

fnu

rkp schrieb:

darf ich Dich fragen, ob Du mal versuchsweise yavdr ansible darauf installiert hast? Falls nicht, womit betreibst Du das Gerät? Wie hoch ist die Prozessorlast bzw. der Energieverbrauch bei UHD-Betrieb?

Nein, kein yavdr ansible, wie seit Jahren Standard Ubuntu LTS, z.Zt. 18.04.2 und Pakete aus meinen PPA, wo sich auch immer wieder schamlos Kopien von seahawk1986 finden

Zum Stromverbrauch bei UHD kann ich sicher in einem anderen Thread mal was schreiben, hab die Kiste aber grad erstmal nur mit FHD Einstellungen in Betrieb genommen ... mit der UHD Frickelei fange ich demnächst mal an ...

beinhart schrieb:

so klappt das tatsaechlich.

Das ist doch gut, freut mich

beinhart schrieb:

wie kommst du fnu denn darauf, dass DP1 erst mit start von x11 greift und davor noch

hdmi als ausgabedevice genommen wird?

Naja, hatte ja auch erstmal kein Video-Bild bzw. dann dann auch wieder kein Boot-Bild und musste zwangsläufig drüber nachdenken was das Problem sein könnte ...

Dann fiel recht schnell der Groschen, dass der LSPcon DP-to-HDMI 2.0 Konverter wohl erst mit den Grafiktreibern von Xorg aktiviert wird, der dann zur Ausgabe über DP1 führt. Daher in grub "HDMI1", in xorg.conf "DP1" ...

Regards

fnu

beinhart schrieb:

NUC8I3BEK

Diese Bean Canyon (Coffee Lake) Generation habe ich auch hier, werde ich aber persönlich nicht als VDR nehmen. Intel hat hier vorallem den i3 mal so richtig von der Leine gelassen, was mir wirklich taugt, hat alle Features, auch iGPU, seiner i5/i7 Geschwister und ist leistungsmässig auf dem Niveau des i7 (auch 2CT4) der Vorgänger Baby Canyon bzw. sogar Skull Canyon. Das merkt man aber auch an der Leistungsaufnahme, finde ich nicht sparsam genug für einen VDR, werde aber hier min. 2 Desktops damit ersetzen, einmal mit i3 (2CT4) und einmal i5, welcher wie der i7 in dieser Generation "4CT8" ist.

Für meine UHD Tests habe ich mich für Baby Canyon (Kaby Lake) entschieden, NUC7i3BNH. Dieser i3 hat zwar nicht die Drehzahl des Bean Canyon i3, aber dennoch weit weg von langsam, mehr als ausreichend CPU Power und ist merklich sparsamer unterwegs als Bean Canyon. Die Intel (U)HD Graphics 620 hat auch ausreichend Leistung für Video Ausgabe der verschiedenen Formate.

Mit Baby Canyon habe ich auch das mit edid.bin umgesetzt, allerdings rein VDR, habe bisher keine Probleme festgestellt.

[EDIT] => Baby Canyon ist beim Boot noch HDMI1, in/bei Xorg dann aber DP1 ... ! Wird bei Bean Canyon ähnlich sein, wegen des LSPcon HDMI 2.0 Converters, den Baby, Dawson und Bean Canyon gemeinsam haben.

Regards

fnu

Ja, genau in der Datei

Ich würde das nicht überbewerten, diese Sheeva Plug Geräte waren mit die ersten kommerziellen Geräte auf ARM Basis gewesen, so vor ca. 10 Jahren ...

Vmtl. hat heute jedes €200 Smartphone mehr Rechenleistung und schnellere Schnittstellen, ein RPi3 erscheint daneben geradezu wie ein Numbercruncher ...

wirbel schrieb:

Klingt nach unpassender Hardware Auswahl.

FullAck!

Regards

fnu

jsffm schrieb:

Da ich Formel 1 Fan bin, konnte ich nur dort im vergangenen Jahr die Trainings und teilweise das Qualifying sehen.

Oh, ok, war mir nicht bekannt, das der Sender dafür genutzt wurde ...

Regards

fnu

Dr. Seltsam schrieb:

Nachdem Du nun schon Erfahrung gesammelt hast ... vielleicht kannst Du auch für Deutsche Welle TV (239.35.20.44:10000) einen Eintrag basteln?

DW-TV gibt es bisher nicht bei MagentaTV (zum freien Empfang), nur über die alten EntertainTV Adressen, eben so lange die Telekom das noch streamt. D.h. es gilt der alte Eintrag aus: [IPTV] T-Home EntertainTV - channels.conf - aktuelle Einträge

Regards

fnu

Dr. Seltsam schrieb:

Erhält man bei einer Tarifumstellung das alte Entertain weiterhin?

Ja und nein, generell schon, aber wird dieses Jahr offensichtlich endgültig abgeschaltet, ich habe nur die neuen Adressen in der channels.conf ...

zuhause schrieb:

schade ist es, dass auch "n-tv" fehlt

Wäre einfacher gewesen mich z.B. per PN eben drauf hinzuweisen, anstatt "dahinzuschwurbeln" ... ... hab diesen "lebenswichtigen" und "werbungsarmen" Sender hinzugefügt ...

Regards

fnu

Wh1sper schrieb:

YaVDR kommt damit auch klar?

Ja, warum nicht? Es wird vdr-plugin-iptv benötigt ...

Du musst Dir halt Gedanken zum EPG machen, die Streams beinhalten nur Now/Next Event, d.h. EPG über längeren Zeitraum muss von extern eingepflegt werden.

Regards

fnu

Wh1sper schrieb:

1. Kann ich alle bisherigen FreeTV Sender auch via IPTV Plugin (welches) sehen?

=> [IPTV] T-Home MagentaTV - channels.conf - aktuelle Einträge

zuhause schrieb:

gibt es auch schon eine Adresse von Radio Bremen TV HD für IPTV?

Nicht für MagentaTV ...

Regards

fnu

Wie Alexander schon schrieb, ist das Problem hier das Zusammenspiel Kernel (KMS) & Xorg. Das war früher bei Nvidia (VDPAU) einfacher, der binäre Nvidia Treiber hat keine Rücksicht auf den Kernel genommen. Da hat man einfach nur in der xorg.conf eine edid.bin hinterlegt, was dazu führte das Xorg ein "eingeschaltetes Display" fand, egal ob ob es physisch dran war oder nicht.

kls schrieb:

Diese EDID-Daten sind aber doch Monitor-spezifisch.

Ja und nein. Es ist ja nicht so das jeder Hersteller digitaler Displays seine eigenen Modelines einpflegt. Warum auch die Ausgabeformate sind ja weltweit bekannt/standardisiert, siehe z.B. die o.a. Modeline ist eine "genormte" für 50Hz, EIA/CEA-861B.

Sicher unterscheiden sich auch die Displaydaten wie Size, VertRefresh, HorizSync in der edid.bin in Details, aber nicht um Welten. Die 1920x1080@50p Modeline wird jedes FHD+ TV Gerät der Welt darstellen, sowie die meisten PC Monitore mit entsprechender Auflösung.

Ich nutze seit Jahren meine Panasonic edid.bin für alle möglichen Displays, auch mein hp Desktop Monitor. Und das Beste, ich nutze diese immer noch, obwohl ich den Panasonic Plasma schon gar nimmer habe, an meinem LG OLED UHD TV.

Erst seit wenigen Tagen habe ich einen UHD fähigen NUC, der aktuell auch nur FHD ausgibt, hab nur eben die alte Installation (inkl. Pana edid.bin) übernommen und nur das nötigste angepasst (DP1, CIR). Mit dem werde ich die (UHD) edid.bin des LG nutzen/umsetzen, demnächst irgendwann, ... aber auch darin wird sich die bekannte 1920x1080@50p Modeline befinden, weil der LG das ja auch darstellen kann ...

Bei der edid.bin Umsetzung geht es drum dem VDR Gerät glauben zu machen, da ist ein Display dran, egal ob das physisch so ist oder nicht. Das physische Gerät muss im Prinzip auch nicht dem der edid.bin entsprechen, sondern der gewählte Ausgabemodus muss darstellbar sein. Nach einem Displaywechsel wird man sich sicher dann um eine Aktualisierung der edid.bin bemühen ... aber man hat erstmal ein Bild.

Gruß

Frank

Oje, das Thema Konfiguration Xserver war/ist schon immer ein, sagen wir, leicht kontroverses. Jeder denkt er hat die beste Lösung, jede VDR/HTPC Distro hat hier seine Eigenheiten und nicht ganz selten benötigt die eigene HW eine Sonderlocke ...

Grundsätzlich ist nur der Anfang nicht einfach, hat man aber seine Konfiguration, trägt man diese über Jahre von Gerät zu Gerät weiter ... habe bis heute Dinge vom Anfang der Nvidia VDPAU Ära (2009) in meiner Datei ...

kls schrieb:

soll man dazu den Xserver auf genau 1920x1080x50p einstellen.

Ja, in Europa wird ja mit 50Hz Bildwiederholfrequenz gesendet und es ist leider nicht die Stärke der Intel GPUs eine 60-50Hz bzw. vice versa Konversation umzusetzen. Das konnten die Nvidia GPUs besser auch wenn's nie 100% fehlerfrei war.

kls schrieb:

Kann ich (wenn ja, wie?) den Xserver so konfigurieren, dass er auf jeden Fall 1920x1080x50p am HDMI-Ausgang erzeugt?

Ja, das geht, musst aber selbst eben probieren/herausfinden ob der verwendete Monitor 1920x1080@50p darstellen kann. Bei TV Geräten ist das aber keine Frage ...

Zum einen kann man eine Modeline definieren, z.B.:

Oder, wie wir es seit Jahren bei den Nvidia Karten gemacht haben per edid.bin Datei. Das geht auch mit Intel, hatte ich in diesem Thread mal aufgearbeitet:

=> Zusammenfassung Intel VAAPI & edid.bin

Im Beispiel benutze ich HDMI-A-1 für den Kernel und HDMI1 für Xorg, funktioniert auch so perfekt bei meinen Haswell NUC. Bei einem neueren NUC, auch mit HDMI Ausgang, musste ich aber für den Xorg DP1 definieren, während der Kernel bei HDMI-A-1 blieb ...

kls schrieb:

Hat jemand eine "optimale" xorg.conf?

Auf das optimal bin ich ja oben schon eingegangen ... aber das ist aktuell meine /etc/X11/xorg.conf.d/20-intel.conf für meine Intel Haswell NUCs:

Bei Intel sollte man alle (theoretischen) Anschlüsse "behandeln" und ignorieren. Hab auch ungenutzte Optionen mal drin gelassen ...

[EDIT] Für Deinen PC Monitor würde ich mal mit der Modeline starten, später am TV dann das mit der edid.bin umsetzen ...

Gruß

Frank

Speziell mit Deiner V5.5 oder ist das für alle Revisionen mit MLD bekannt?

Regards

fnu

koepcke schrieb:

Leider funktioniert das Zusammenspiel mit DD Karten nicht so gut.

Hatte ja selbst auch ein ASRock Q1900M mit DD Cine Karten (4x) als VDR betrieben und kann keinerlei Probleme damit bestätigen. In einem vergleichbaren ASRock D1800M lief auch die MaxS8 fehlerfrei ...

Der Blick ins syslog wäre hier durchaus interessant ...

Regards

fnu

M-Reimer schrieb:

Fressen die "Xeon" deutlich mehr Strom? Brauche ich einen anderen Kühler?

Weder noch, die Xeon sind im Prinzip die gleichen CPUs wie die regulären i5, i7 mit ein paar Server-Features extra und je nach dem mit größerem 3rd Level Cache. Aber die TDP Angaben gleichen sich und damit auch die reale Leistungsaufnahme. In Deinem Fall würden diese leistungsfähigen CPUs ja quasi nur auf Standgas laufen und da sind die Leistungsaufnahmen seit SandyBridge bei Intel CPUs gering. Der Unterschied im Idle/niedriger Last zwischen Celeron/Pentium und i7/Xeon ist niedrig, aber dennoch da ...

Ausnahmen werden hier vmtl. nur die Core i5/i7 S & T bzw. Xeon L Versionen sein. Aber diese wirst Du nur noch mit Gold aufgewogen gebraucht bekommen. Xeon L gibt es nur einen, E3 1220L (SNB) bzw. 1220L-v2 (IVB), 2C4T, also im Prinzip ein sparsamer i3 ohne GPU als Server CPU ...

Die Xeon gibt es nicht als boxed Versionen, daher eigentlich auch keine Intel Kühler dafür. Aber generell sind die boxed Kühler von i5/i7 mit dem Kupferkern ausreichend.

M-Reimer schrieb:

"Muss" ist eigentlich nur AES-NI und das bietet mir auch ein i5

Da ich immer wieder auch nach solchen CPUs suche, weiß ich, dass ist ein Frage des Preises. i5/i7 (1155) SNB & IVB bekommt man nicht hinterhergeschmissen und mehr als einmal habe ich mich für einen passenden Xeon entschieden und in einem Desktop betrieben.

Wenn Du die Nvidia weiterbetrieben möchtest, kannst Du auch die E3-12x0(-v2) kaufen, die haben keine GPU. Es ist auch kein Problem eine SandyBridge CPU auf dem IvyBridge Board zu betreiben, gibt aber keinen SNB Xeon mit 3000er Grafik (12 EU).

Für die Video Ausgabe über Intel Graphics sind die IvyBridge CPUs Xeon E3-1225-v2, E3-1245-v2 und E3-1275-v2 interessant, die sind mit einer 4000er GPU mit 16 EU ausgestattet. Den E3-1245-v2 hatte ich selbst mal in meinem Desktop in Betrieb ...

Aber angesichts dessen, was Du vmtl. für einen SNB/IVB Core i5/i7, Xeon bezahlen wirst, könntest Du auch drüber nachdenken auf ein Gemini Lake Mainboard zu wechseln, z.B. das ASRock J4105M. Die verbaute CPU Celeron J4105 ist ein 4-Kerner mit einer Intel UHD Graphics 600 mit 12 EU und AES-NI ... Du brauchst zwar neuen DDR4 RAM, aber evtl. erlöst Du ja ein paar Euro für Dein altes Board. Du kannst Deine Nvidia erstmal weiterbetrieben oder eben die Intel UHD Grafik testen und nutzen ...

Regards

fnu

schnoefftel schrieb:

Könnte der Hashwell denn auch schon UHD?

Nein, Haswell kann kein h.265/HEVC, geht meines Wissens nach erst ab SkyLake ... bzw. so richtig erst ab Kaby Lake (https://en.wikipedia.org/wiki/Intel_Graphics_Technology)

Sogar bei der Auflösung könnte es schon schwierig zu werden, da Intel für die GPUs 3200x2000 via HDMI1.4 & DP angibt, UHD/4K aber 3840 × 2160 benötigt ... mangels sinnvollem TV UHD Content, ist das eher kein größeres Problem momentan ...

Ich gebe nachwievor das HD Bild (Desktop) aus und lasse den UHD TV skalieren ...

Regards

fnu

M-Reimer schrieb:

Taugen die Intels aus der zweiten oder dritten Generation für brauchbares Deinterlacing und HD-Video?

Grundsätzlich läuft es schon mit SandyBridge & IvyBridge und zumindest "Motion Adaptive Deinterlacing" (MADI) wurde IIRC auch dafür mal noch freigegeben, hatte ja jahrelang mit einem Celeron J1800 (BayTrail) getestet. Aber die SNB/IVB GPU der low(er) end CPU Modelle sind mit wenigen Streamprozessoren ausgestattet und daher immer an oder über der Leistungsgrenze. Die GPU des Celeron J1800 (BayTrail) ist IvyBridge basiert mit nur 4 Streamprozessoren, der IvyBridge Celeron 1610 hat auch nur derer 6.

Einige high(er) end SNB/IVB CPUs besitzen zwar schon auch 12 bzw. 16 Streamprozessoren und teilweise auch AES-NI. Sind aber alles keine ausgewiesenen Spar-Modelle und gebraucht oft nur noch recht teuer zu bekommen. Hier evtl. nach einem Xeon mit GPU für Sockel 1155 Ausschau halten (Xeon E3-12x5(-v2 für IvyBridge)), die haben IIRC in jedem Fall AES-NI. Bekommt man oft günstiger als i5/i7 und sind deren Server/Workstation Versionen ...

Ab Haswell hat Intel dann mit den Streamprozessoren nimmer gekleckert, da hat die einfachteste Version, Intel HD Graphics bei Celeron/Pentium, schon derer zehn. Wenn eine Zahl dahinter spezifiziert ist (z.B. Intel HD Graphics 4x00 ab i3) min. 20 bzw. dann auch 40 (Intel HD Graphics 5x00). Damit läuft die Video-Ausgabe einfach "entspannter" ...

Siehe auch: https://de.wikipedia.org/wiki/Intel_HD_Graphics

Ich selbst betreibe seit einiger Zeit zu meiner Zufriedenheit Haswell auf Intel NUCs (Wilson Canyon) mit VDR, die Core I3 Version. Diese i3 CPU kommt mit einer Intel HD 4400 GPU (20 Streamprozessoren) und AES-NI ... meine besten VDR (ever) und das sehr sparsam. Es gibt auch eine i5 Version, die hat dann eine Intel HD Graphics 5000 mit 40 Streamprozessoren, ist aber viel seltener zu bekommen.

Kodi mit LibreELEC mal testen, für reinen VDR würde ich eher zu Haswell raten.

Regards

fnu

IBaer schrieb:

Knopf unter Menu "Multicast Setup" gefunden und gedrückt, gleiches Ergebnis.

Darum geht es, Multicast willst Du nicht und funktioniert auch nicht mit vdr-plugin-satip, nur Unicast.

Weiß gar nicht ob es überhaupt SAT>IP Clients gibt, die mit Multicast umgehen können ...

IBaer schrieb:

Weiß jemand ob QoS unter Linux ein neuer Denkansatz wäre?

Hast Du das auf dem Octopus aktiviert? Bzw. mal die Frage, was hast Du unter "System Settings" alles aktiviert?