Mini-PC für libreelec mit CEC unterstützung

    Zitat von SkyBird1980

    Hat damit ja im Grunde nichts zu tun. Nimmt man Windows als Basis hat man auch die nativen Apps auf dem Gerät.Aber grundsätzlich? Kodi soll ja alles sein.

    Welcher Streamer ausser Netflix bietet denn ueberhaupt 4k mit HDR unter Windows an ? App oder Edge, egal.
    Soweit ich weiss doch keiner. Disneplus z.b. nicht.

    Hast Du mal Windows 11 mit Android subsystem unter Windows probiert, obs damit geht bei solchen Streamern ?

    Friss Android oder stirb 720p oder so.

    Nervt.

    Gibt ja keinen X86 SoC mit CEC (bisher). Und ich kenne auch keinen Hersteller, der sowas aufs MoBo mit draufgeloetet hat. Von daher bleiben bloss die Adapter von Pulse-Eight. Bei Intel NUCs gibt es halt intern sockel fuer die Pulse Eight einen internen Adapter gebaut hat. Ansonsten halt den externen Adapter von Pulse Eight der ins HDMI eingeschleift werden mus und USB Port braucht. Der laeuft an jedem x86 rechner. Vielleicht kriegt man ja auch den internen adapter in einem anderen Mini-PC , meisten klauen die ja eh die internen port-designs voneinander.

    Am ENde gibste halt mit dem CEC dongle intern oder extern und billigsten NUC ca. 200 aus. Da stellt sich also die frage warum x86 und warum CEC. Einfach bloss damit Du nicht Optionen uebersiehst an die Du vielleicht nicht gedacht hast, weil Du dich halt schon frueh auf eine Loesung festgelegt hast.

    Soll denn das TVHeadend lokal auf der Kiste laufen ? Das z.b. ist wahrscheinlich schon ein alleinstellungsmerkmal fuer einen kleinen x86.

    Ansonsten ist sind halt die unterschiede kodi auf einem android, wie z.b. chromecast TV fuer 70 Euro gegen x86 PC/CEC fuer 700 euro schon diffiziler. x86 duerfte fluppiger sein bei allem was GUI und photos anbelangt. Und komisch codierte Videos. Und BD-RIPs wegen hoher bitrate. Wenn Du aber hauptsaechlich normales MP4/h264/h265 mit sagen wir mal < 20 Mbps rate hast, dann ist wahrscheinlich jede Android box nicht schlechter als teurere Kisten.

    Ja TV-Headend sollte auf diesem "Haupt"-System laufen...als Backend und Frontend. Ich möchte einfach nicht schon wieder eine Kiste mehr haben....und wie gesagt reicht dafür auch (fast) mein derzeitiger Raspi 4b mt 4GB...aber eben nur FAST. Da bei diesem aber dafür CEC wie selbstverständlich funktioniert, wollte ich darauf dann doch nicht mehr verzichten.
    Aber wenn das mit CEC gefrickel wird (x86) dann, wird es wohl geopfert.

    Wenn vielleicht doch mal jemand eine Aussage zu den Androiden (wie dieses: Voncen N6 Pro TV Box) machen könnte?
    Klar habe ich bei coreelec geguckt, aber leider nichts wirklich aussagekräftiges zur Installierbarkeit gefunden. Noch weniger zur Leistung, also ob da TV-Headend Back- und Frontend zusammen mit einem Skin ohne Ruckeln und Aussetzer läuft...??

    Zitat von Bekibek

    Ich möchte mir - bei mehr als zehn Clients, die bei mir im Haus und Atelier verteilt laufen (Raspis und Androiden) - nicht noch mehr als nötig hinstellen. Deshalb sollte auf dem gesuchtn System mindestens Kodi + TVHeadend (Server) ohne Überforderung laufen....


    Frickelei ist es, bei einer derart hohen Anzahl an Clients keinen dezidierten Server für TVHeadend laufen zu laufen.
    Und den PulseEight-CEC-Adapter baust Du in weniger als einer Viertelstunde in einen NUC ein, total simpel.

    Man sollte auf jeden Fall gucken, das das System, auf dem Aufnamen gemacht werden auch unter Spitzenlast die Aufnamen nicht kaputt macht. Was eben bei Aufnamen vom Satellit oder Kabel leicht passieren kann, weils halt eine realzeit anforderung ist. Wenn da halt die CPU mal kurzfristig was anderes tut, greade weil lokal ein Benutzer irgendwas unerwartetes macht, dann ist da halt leicht eine Bildunterbrechung in der Aufname.

    Ich hab aus genau dem Grund von HD auf SSD auf dem Server gewechselt, weil ich damit sicherer mehr Aufnamen gleichzeitig hinkriege. Ansonsten gab es aussetzer bei wenigen gleichzeitigen Aufnamen.

    Und selbst SSD selbst reicht allein nicht immer. Habe ja scripten, die dann umcodieren und dann das fertige Resultat wegkopieren. Das Wegkopieren geht dann mit soviel Durchsatz, das auch das gleichzeitige Schreiben einer aufnamen auf dieselbe SSD dann mal zu spaet kommt und wieder bildstoerung in der Aufname. Also muss ich so eine Kopieraktion dann verlangsamen (weil linux zu ploede ist, das selbst richtig zu machen).

    Usw. usf. Natuerlich kann man probieren da auch noch kodi client gleichzeitig auf der Kiste laufen zu lassen, macht es aber schwieriger.

    Natuerlich kann das nullo problemo sein, wenn man sagen wir mal nur immer eine Aufname gleichzeitig machen laesst, oder nur SD statt HD. Aber irgendwo lauert eine boese Performancegrenze.

    Naja, das umkodieren hat dir da den Hals gebrochen. Einfache Aufnahme stellt so gut wie keine Anforderung an das System. Es wird ja im normalfall als TS im Pass Modus geschrieben und selbst 5 Streams sind mit im schlimmsten Fall mit 15 mps/Stream kein Problem beim schreiben solange man keine USB 2 Flash Laufwerke nutzt.

    --------------
    Guides nicht mehr verfügbar wegen Youtube unvermögen guten von schlechten Kodi Videos zu unterscheiden.

    TVHeadend (und wohl auch der Digibit?) benutzen zum Transport der Streams UDP. Das kann in Zusammenhang mit Switchen, ungünstiger Netztopologie, schlechtem Hardwaredesign (RPi) und hohem Transportaufkommen gerne mal zu Bildaussetzern führen.

    Hab' noch mal nachgeschaut, TVH macht TCP.

    AZi (DEV): Nexus auf LibreElec | Asrock J4205 | 4 GB RAM | 128 GB Sandisk| Rii mini
    DEV: PC Ubuntu 20.04 | Matrix
    AZi: Tanix TX3 | Android/CoreElec Dualboot (EMMC), Nexus
    WoZi: Nexus auf LibreElec | Asrock J4205 | 4GB RAM | 128 GB Sandisk SSD | Atric IR | URC7960
    NAS: unRaid, 3x6TB, 2x12TB | TV-Server: Futro S550 mit Hauppauge QuadHD DVB-C
    PayPal: paypal.me/pvdbj1

    Einmal editiert, zuletzt von PvD (28. Oktober 2022 um 16:30)

    Nur wenn du per Multicast verteilst, @PvD - im normalen Stream wird TCP benutzt.

    --------------
    Guides nicht mehr verfügbar wegen Youtube unvermögen guten von schlechten Kodi Videos zu unterscheiden.

    Zitat von PvD

    TVHeadend (und wohl auch der Digibit?) benutzen zum Transport der Streams UDP. Das kann in Zusammenhang mit Switchen, ungünstiger Netztopologie, schlechtem Hardwaredesign (RPi) und hohem Transportaufkommen gerne mal zu Bildaussetzern führen.

    Das will ich nicht grundsätzlich bestreiten (auf deine Korrektur komme ich zurück ...) In der Tat gilt selbstverständlich UDP als unzuverlässiger ("kann Pakete verlieren, ungeordnet übertragen, gibt keine Rückmeldung) als TCP. Und ist es für viele Situationen auch.

    Allerdings, wenn man geringe Latenz will, hohe Bandbreite benötigt, das Netzwerk eh schon mit vielerlei Dingen ausgelastet ist (und QOS lasse ich jetzt man außen vor) hat sowohl theoretisch als auch praktisch UDP sehr große Vorteile. Die "Belastung" (ohne das jetzt genau zu definieren) des Netzes ist niedriger. Läuft (gerade bei Streams) noch gut, wenn TCP zu Abbrüchen neigt (und zu Diskussionen hier, man solle sich zuverlässigeres Netzwerk besorgen, höhere Bandbreite, Kabel ziehen, ...).

    Ein Beispiel, bewusst mit WLAN. Magenta TV Live TV. Die nutzen UDP (mit rtp-Protokoll), 7 Mbit/s bei mir auch im WLAN absolut verlässlich. Mein Testprogramm hat in 24 h nicht ein verlorenes Paket gefunden, und auch nicht eines in falscher Reihenfolge (was erlaubt wäre - durch Auswertung der rtp-Header kann man das rausfinden). Gleiche Bedingungen mit WLAN, Stream von meinem Enigma2 Receiver, ähnliche Bandbreite. Der Stream (genau wie tvh) pure Transport-Streams (ts) mit TCP. Fängt leicht zu stottern an um später abzubrechen / sich total aufzuhängen (natürlich nur unter nicht zuu tollen Bedingungen).

    Ich denke neben den reinen Transport-Eigenschaften sind da auch die Robustheit/Qualität der Programmierung mit maßgebend. Wer sich auf UDP verlässt rechnet automatisch mit Unzulänglichkeiten. Bei TCP kommt der Client (und der Server) ist das oft weniger robust programmiert (da man sich eh auf TCP verlassen kann) und jede Kleinigkeit führt zu nicht korrigierten Problemen bis zur Nichtfunktionalität.

    Nicht ohne Grund nutzen auch oft Video-/Audio-Konferenz Lösungen oder auch Protokolle um im Rechenzentrum gerenderte Grafik auf einem Endgerät in Echtzeit darzustellen (z.B. Citrix ICA) UDP.

    EDIT: Kleiner Zusatz. Was neben UDP vs. TCP da auch noch ne Rolle spielt. Tvheadend, genau wie Enigma2, streamen reinen Transport-Stream, ohne ein Protokoll oder ein Framework außen rum. HLS streamt auch über TCP, hat aber Aufsetzpunkte (TS wird fragmentiert in typischerweise wenige Sekunden lange Chunks). Diese puren TS-Streams sind zweifellos für Broadcast über den Ether (wo sie her kommen, aber auch nicht ohne zusätzliche Checks) bestens geeignet. Fürs Streaming (selbst im Heimnetz) aber halt bei der kleinsten Störung schmiert das leicht ab.

    Zitat von PvD

    Hab' noch mal nachgeschaut, TVH macht TCP.

    Daher passt das zu meiner Ausführung, gerade für typische Medien-Anwendungen, wie Live-Streaming (nicht nur) im Heimnetz ist UDP aus grundsätzlichen Erwägungen unter vielen Aspekten TCP überlegen.

    EDIT. Zusätzlich spielt neben TCP vs. UDP noch eine Rolle. Sowohl tvheadend als auch enigma2 Receiver streamen puren Transport Stream, ohne Framework/Protokoll außen rum. HLS beispielsweise fragmentiert den TS in Chunks, und hat damit automatisch Aufsetzpunkte. Die tvh/e2 Methode ist da einfach fragiler. Das pure TS ist sicher für Broadcast (über Sat, Kabel, Antenne) sehr gut. Aber da war auch noch Fehlerkorrektur dabei. Im Heimnetzwerk ist das nicht optimal.

    Kodi 21.0, 17.6, 20.5, 16, 20.5 on Windows 11 Pro, Android 6, Android 12, FireTV Box 2nd Gen, FireTV 4k Max 2nd Gen
    Media on NAS, OpenMediaVault 6 (Debian Linux).

    3 Mal editiert, zuletzt von buers (28. Oktober 2022 um 21:07)

    In meinem Setup funktioniert UDP Streaming mal so gut wie überhaupt nicht, mehrere Switche usw bis zum tvh Client, zuspieler ist ein Digibit für ein tvh Server innerhalb eines Containers.
    Da half nix anderes als die satip axe Firmware für den r1 zu verwenden, dann lässt sich auch tcp für die Kommunikation zwischen tvheadend und digibit einstellen, rock stable, aber ja, mehr overhead, fällt aber nicht ins gewicht bei ~15mbit in einem Gigabit Netzwerk.

    Das mag schon sein. Aber in so einem Fall: wieso das Protokoll verantwortlich machen, und nicht die Hardware und SW? Ich habe da auch professionell viel getestet. Natürlich funktioniert unter optimalen Bedingungen immer alles. Und (gerade in Firmen-Umgebungen) ist auch die Durchlässigkeit von UDP ein Problem, auch (und wegen) Sicherheit (weil es grundsätzlich andere Angriffsmechanismen gibt - aber bei Streamen im Heimnetz und auch bei LiveTV aus dem Internet??).

    Mein Argument: TCP hört sich grundsätzlich besser an. Wenn die Bedingungen schlechter werden, Anforderungen höher (an Bandbreite und Latenz) hat UDP grundsätzliche Vorteile. Das wollte ich ins Bewusstsein rufen.

    Ich versuche nun aufzuhören, das Thema zu hijacken ...

    Kodi 21.0, 17.6, 20.5, 16, 20.5 on Windows 11 Pro, Android 6, Android 12, FireTV Box 2nd Gen, FireTV 4k Max 2nd Gen
    Media on NAS, OpenMediaVault 6 (Debian Linux).

    Und ich hab das selbe Setup - auch mit mehreren Switchen mit der Standard Firmware. Hast vieleicht einfach nur Pech.

    Zitat von DeBaschdi

    Dein Netstat kommt doch von tvheadend zu windows, nicht vom digibit zu tvhadend ?
    Schau mal wireshark auf unraid an.

    Der obere Windows, der untere unraid, auch unraid kann netstat :)

    --------------
    Guides nicht mehr verfügbar wegen Youtube unvermögen guten von schlechten Kodi Videos zu unterscheiden.

    SatIP ist bei mir noch Baustelle. Kathrein 418 nur als Experiment. Die hat aber AFAIK kein TCP.
    Glaube auch nicht, das das SatIP Modul in VDR TCP hat (aber keine Ahnung). Ist das ueberhaubt in the SATIP Spec drin oder bloss bastlerloesung in Digibit bastlerfirmware und Apps wie TvH ? Ja ok, koennte die Spec anschauen... Faul.

    Bei mir iss ja wirklich HDD zugriff, DVB-S2 Karte ueber PCI in VDR, VDR via SATA auf SSD (sagen wir 4 * HD streams). Wenn da dann jemand mal viel gleichzeitig auf/von der SSD kopiert, dann ssieht man ruckeln in den Aufnahmen. Kann alter Linux Kern sein, knn falsche double-buffering strategy im VDR sein, kann aber auch (was ich befuerchte) sein, das die Kernel file-system treiber im Linux da gerne mal in so groessen Bloecken zu arbeiten, das da ein Prozess (z.b. ein schreiber fuer die VDR aufname) dann mal 3 sekunden lang nicht weiterkommt. Und soviel buffert der VDR wohl nicht).

    Debuggen an langen Winterabenden oder so...

    UDP richtig zuverlaessig hinzubekommen ist was fuer profinetze/loesungen IMHO. Die kommerziellen TV streamingloesungen fuer Netzbetreiber wie den rosa elefanten sollten eigentlich alle sowas wie rfc4588 oder nachfolger, also RTP/UDP retransmissions anbieten. Auch beim Multicast (vom edge-cache des Netzbetreibers). Das hat consumer-ware natuerlich nicht drin. Da ist dann UDP immer mit aussetzern versehen, wenn man da nicht das qos in seinem home netz im griff hat.

    Unifi switches z.b. haben kein offizielles QoS sondern wohl bloss "smart-queue" Maggie. Maggie ist natuerlich undokumentiert, kann also nicht debugged werden weil man ja nicht weiss wie es tun soll. Aber ich koennte bei mir direkt ethernet p2p vom Kathrein zum Server-PC legen, wenns sein muss.

    Wenn man da im Pfad zwischen SatIP und server/empfaenger nicht nur ethernet mit (z.b. bei mir maximal 3) switches, sondern auch noch WiFi oder Powerline hat, dann sag ich mal gute nacht dafuer UDP ohne Paketverlust mit consumergeraffel hinzubekommen. Im kommerziellen Umfeld haben so UDP videosender ja auch noch Redundanz im Stream (FEC). Macht SATIP soweit ich weiss auch nicht.

    Natuerlich ist TCP bloede und die schlechtere Loesung als UDP fuer realtime streaming, aber halt der einfachste Workaround fuer all diese consumer Moppelkotze in Netz und Anwendungsgeraeten (Fernseher, SATIP, WiFi, Powerline ...).

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden