Octopus NET S8 + vdr + KODI (LibreELEC)

  • hivdr


    Ich habe hier LibreELEC auf einem RPi2 mit vdr-backend laufen, der findet immer, wirklich ausnahmslos immer meinen Octopus Net für seine 2 Devices. Allerdings war das bei OpenELEC vorher auch nicht anders ...


    Da das so auch bei meinen VDRs mit vdr-plugin-satip ist, sehe ich hier keinen Handlungsbedarf an der Software, zumal auch TVH bei Dir Probleme macht.


    Was aber sehr, sehr wichtig bei SAT>IP ist naturgemäß eine wirklich saubere Netzwerk-Umsetzung ... ?


    Regards
    fnu

    HowTo: APT pinning

    Dieser Beitrag wurde bereits 1 Mal editiert, zuletzt von fnu ()

  • Am Netzwerk ist nichts verdächtiges: klassisches LAN mit (solidem) Switch, Gateway/DHCP ist ein Linux-Server, seit Jahren unauffällig.
    Der dort eingehängte Octo wird ja auch problemlos gesehen von zB Windows-Clients wie auch dem tvh von libreelec (was dort nicht klappt ist ein Scan, habe ich aber bisher wohl auch immer nur mit nicht zum neuen DVB-T2 passenden Voreinstellungen probiert).


    Lediglich der vdr-Service des libreelec auf dem Wetek Hub zeigt ihn eben oft nicht an bzw. erfordert mindestens ein disable/enable des Service. Ein Problem bzgl. "auf Netzwerk warten" ist ja offenbar in diesem Zusammenhang altbekannt (darum gibt es den Konfig-Schalter) - und ob das beim vdr einfach nicht immer so wirkt wie beabsichtigt, das zu beurteilen können wir dann ja erst mal CvH überlassen.

  • Am Netzwerk ist nichts verdächtiges: klassisches LAN mit (solidem) Switch, Gateway/DHCP ist ein Linux-Server, seit Jahren unauffällig.

    Das hat nichts zu heißen, Du wärst nicht der Erste wo es hier Probleme gibt obwohl es Jahren sonst keine Probleme gab, und vmtl. auch nicht der Letzte ...


    Dankbarerweise bin ich seit den ersten Zeilen Code bei vdr-plugin-satip dabei und hatte nie ein Problem das ich auf Netzwerk warten musste. Und hier sind immer 3 Switches zwischen Clients und Octopus Net.


    Regards
    fnu

    HowTo: APT pinning

    Dieser Beitrag wurde bereits 1 Mal editiert, zuletzt von fnu ()

  • Die Octo hat definitiv Netzwerkprobleme und keine zu kleinen - ABER sie treten nicht bei jedem auf (ich rede nicht von den Protokoll Spezifischen). Ob das ein HW Fehler ist oder ob es an dem Heimischen Netzwerk liegt kann ich nicht orakeln.


    Der bis jetzt beste Fix ist alle Geräte über den Switch der Octo laufen zu lassen - zum probieren wäre das sicherlich mal eine Idee.


    Sobald ich Zeit hab guck ich mir die "auf Netzwerk warten" Logik von unserem vdr addon mal an.

  • Die Octo hat definitiv Netzwerkprobleme und keine zu kleinen

    Jeder der Probleme hat sollte besser mal sein Netzwerk, also Kabel, Dosen, Patchkabel und Switches prüfen, anstatt unbewiesene Behauptungen aufzustellen.


    SAT>IP ist aber nicht unempfindlich auf Netzwerk-Issues, das stimmt.


    Regards
    fnu

    HowTo: APT pinning

  • Also nach einem Artikel in der vorletzten c't (Nr. 13) über LibreElec mit DVB-T2 habe ich endlich nochmal einen Versuch auch mit TVH gestartet. Im Artikel gehts zwar nicht um den Wetek Hub und auch nicht um SAT-IP, aber wesentliche Punkte sind identisch. Ich habe also in der TVH-Weboberfläche unter DVB-Inputs erst mal ein neues "Netzwerk" hinzugefügt (Name frei vergeben) und dabei vordefinierte alte DVB-T Muxes meiner Region gewählt. Diese habe ich (unter "Muxes") dann erst mal aufgeräumt: alle weg bis auf die drei ÖR Transponder/Frequenzen (wie unter http://www.dehnmedia.de/?page=sender&subpage=tsender2 zu finden). Beim Editieren der Muxes muss man neben der Frequenz (falls nötig) v.a. die Übertragungsart von DVB-T auf DVB-T2 ändern. Die restlichen Detail-Parameter scheinen zu DVB-T identisch zu sein, können bleiben. Da bis dahin kein SAT-IP Device zur Verfügung steht, bleibt der Status noch auf "pending", d.h. es wird kein Scan probiert.
    Erst wenn man unter SAT-IP dann die Tuner/Frontends (bei mir 2 Stück, obwohl 4 angezeigt werden) nicht nur aktiviert, sondern auch dem vorhin selbst angelegten "Netzwerk" zuordnet, startet irgendwann der Scan. Und voila - er fand dann tatsächlich alle Sender, die man abschliessend unter "Services" noch "mappen" kann.


    Mit dem TVH HTSP Client klappt dann (analog zur VDR-Kombination aus Service+Client) auch Live TV. Auch aufnehmen kann man, in meinem Fall (wie zu erwarten) auch zwei Programme von unterschiedlichen Transpondern und live ein weiteres von einem davon. Die Umschaltzeiten sind nicht so doll, ziemlich zäh. Und gelegentlich ist auch die Darstellung der Sender etwas zäh (nicht so 100% flüssig - Sorry, ist so).
    Alles in allem kann man aber damit "arbeiten" - dass es kein Ersatz für meinen "richtigen" VDR wäre ist klar, allein schon wegen der viel umständlicheren Bedienung von Kodi.
    Doch bei LibreElec auf dem Hub (jedenfalls die damals aktuelle Version 8.0.1) ist derzeit TVH die bessere Variante gegenüber VDR, weil damit kein Initialisierungsproblem nach dem Booten auftritt.


    Von daher kann ich nach wie vor kein Netzwerk-Problem feststellen - weder in der eigenen Infrastruktur noch beim Octo.
    Natürlich ist SAT-IP ein etwas komplizierteres Protokoll als 1-Port-TCP: aber auch wenn es zahlreiche Ports in UDP+TCP sind - was konkret würde da denn typischerweise schiefgehen, und wie könnte man es feststellen? Letztlich müssten es doch sowas wie Paketverluste sein? Das LAN interface des Linux-Server (uptime halbes Jahr) zeigt bei 157 Mio TX Paketen: errors:0 dropped:0 overruns:0 carrier:0 (ebenso bei den 91 Mio RX). Spezialitäten wie Multicast (was wohl tatsächlich auch bei gewissen Switchen/Routern mal Probleme machen kann) kommt laut Protokoll-Infos erst bei mehreren SAT-IP-Clients gleichzeitig zum Einsatz.

  • Nun kann ich - endlich, nach einer gefühlten Ewigkeit - auch noch vermelden, dass ich wieder einen selbst-installierten Server/headless VDR auf einem neuen Server (innerhalb einer VM) erfolgreich mit dem Octo zum Laufen gebracht habe. Der VDR (aktueller 2.3.8 ) ist komplett manuell aufgesetzt und läuft ohne DVB-Device und output-device - also headless mit plugin skincurses (beim VDR mitgeliefert). Nur das satip-plugin musste noch dazukompiliert/installiert werden, dann beschwert sich der VDR beim Start nicht mehr über ein fehlendes (input-)device. Der SATIP Zugriff hat auf Anhieb problemlos geklappt und nutzt beide Tuner.


    Nun kann ich damit also DVB-T2 Aufnahmen fahren (hoffentlich demnächst auch via remotetimers vom Haupt-VDR aus programmiert). Der Haupt-VDR (mit FFHD) kann mit den Aufnahmen natürlich nichts anfangen - immerhin Ton ist zu hören.


    Leider kann ja streamdev sowohl externremux wie auch Aufnahmen streamen nur über HTTP leisten, d.h. der Gedanke Aufnamen (wie auch Live) on-the-fly von h265 zu h264 zu konvertieren und damit den Haupt-VDR zu beschicken, ist wohl von vornherein zum Scheitern verurteilt. Hat schon mal irgendwer in diese Richtung gedacht? Hätte jemand trotzdem ein passendes externremux? (vermutlich nicht, da es für Clients wie vlc i.a. einfach nicht nötig ist.. jedenfalls nicht output h264)
    Würde das ein Core i5 überhaupt schaffen - bzw. hat die integrierte Intel-Grafik einen decoder für hevc und gibts dafür einen Treiber, den die üblichen Konvertierer ala ffmpeg verwenden können?


    Den Wetek-Hub müsste man ja dann als Client auf den externen Server connecten können, nehme ich an - das muss ich dann auch demnächst mal probieren. Aber an die VDR-Server-seitig gemachten Aufnahmen wird er wohl nicht drankommen, da er ja vermutlich auch mit dem streamdev arbeitet?


    Beobachtung am Rande: der VDR schaltet, wenn man im Terminal "drin" ist (Steuerung über Tastatur), nach jedem Kanalwechsel sofort auf Kanal 1 zurück. Da mangels output-device eh nichts angezeigt werden kann ist das nicht wichtig, doch der alte headless-Server-VDR hatte das Verhalten nicht: man konnte auf einen beliebiebigen Kanal schalten und blieb dort auch (Ausgangspunkt etwa für EPG). EPG scheint schon ziemlich "andauernd" herumzuscannen und so die Tuner im Octo unter Last / Hitze / Energieverbrauch zu halten. Daher habe ich das Scanning erst mal abgeschaltet (0 in den EPG settings).

  • [Ah, alles neu macht der August! Für spätere Leser: dies war der Tag des Launch einer neuen Forums-SW..]


    Ich konnte nun mal den Wetek Hub als Client für den Server-VDR (satip-basiert) in Betrieb nehmen. Natürlich arbeitet der Client _nicht_ mit streamdev, sondern VNSI - mit dem entsprechenden Plugin auf Server-Seite kann der Kodi "pvr vdr vnsi client" tatsächlich neben Live TV auch vollumfänglich auf Aufnahmen zugreifen, ebenso Timer.


    Lässt man mal beiseite dass man also vom Haupt-VDR wegschalten muss (HDMI-Umschaltung, bei mir auch anderes Sound-System) und dass die Bedienung in Kodi deutlich umständlicher ist (zumal mit Mini-FB des Hub), wäre das erst mal wirklich genial!


    Leider bleibts dabei: es ruckelt streckenweise grausam, je nach Bild-Inhalt (also wohl bei mehr Details, höherer Bitrate, ob nun vor oder nach Dekodierung) mutiert es zwar nicht direkt zur Dia-Show, aber doch zum Puppentheater. So gewisse Hänger, nach denen dann "schnell wieder aufgeholt" werden muss - also hängt, dann extra schnelle Bewegung um wieder im Sync zu sein, und das immer wieder. Bei verschwommenen Nah-Aufnahmen kaum, bei knackscharfen Stadt-Szenen oder Natur-Panoramen umso mehr - eben je mehr Bild-Daten desto stärker.

    Entweder ich habe ein Montags-Gerät (wobei ich mich frage was da dann nicht stimmen könnte), oder die Wahrnehmung ist wirklich grob unterschiedlich (es soll ja auch Leute gegeben haben, die bei Gaming Mikro-Ruckeln nicht wahrnehmen, während es andere in den Wahnsinn treibt).


    So kann ich den Wetek Hub als VDR-Client leider gar nicht empfehlen. Maximal mag man so vielleicht mal Nachrichten schauen, aber keine Filme/Serien. Ein Ersatz für einen "richtigen" VDR? Nicht im Traum. Insbesondere bei DVB-T2/H265. Schade.


    Und bevor jetzt jemand die Schuld bei der Zulieferung sucht: kann doch wirklich nicht sein. Die Aufnahmen liegen fertig auf der Platte, satip hat seinen Job (gut) erledigt, Wiedergabe mit VLC auf PC ist einwandfrei. Das ganze kommt über LAN (nicht WLAN) mit weit mehr als ausreichender Speed (dank h.265 ist die Bitrate eh sehr klein). Es kann nur die Dekodierung / Wiedergabe sein.


    Tja und sonst? Habe mal versucht Aufnahmen, also die .ts Dateien, umzukodieren, und sie so der FFHD vorzusetzen.

    Folgender Befehl wandelt von h.265 auf h.264 - auf dem Core i5 7500 mit allen Kernen ziemlich genau in Echtzeit (und Grösse je nach Sender zwischen etwa gleich und doppelt so gross):

    ffmpeg -i 00001-orig.ts -bsf:v h264_mp4toannexb -map 0:v -map 0:a -c:a copy -vcodec libx264 00001.ts

    Index löschen, wird neu aufgebaut.

    Wiedergabe mit VLC einwandfrei, doch die TT-6400 mag das Ergebnis gar nicht recht: immer wieder Hänger und Bild zerfällt in Klötzchen.

    Sprich, nicht brauchbar.

    Falls jemand weiss, mit welchen Parametern man vielleicht für die FFHD besser verdauliche h264-Dateien bekommt..?


    Muss mich wohl doch mal langsam mit dem Gedanken anfreunden, einen softhddevice-basierten neuen VDR zu basteln. Bin gespannt wie da die Entwicklung mit HEVC inzwischen ist. Sprich mit welcher möglichst günstigen / stromsparenden HW (Graka o. integrierte Grafik) man ein zu 100% flüssiges Ergebnis bekommt.


  • Monolog continued.

    Sigh.. das mit dem Ruckeln hat sich weitgehend erledigt durch Umstellung der Video-Ausgabe von den voreingestellten 60Hz auf 50Hz.

    Für TV-Material mit 50Hz sicherlich die bessere Wahl.

    Aber auch aktuelle Ausgabegeräte schaffen das mit 60Hz vermutlich besser als mein Gerät von 2011 (ein Samsung D8090 - damals wahrlich nicht billig).

    Tja, wie so oft sind es die Details.. so ist der Wetek Hub jetzt durchaus brauchbar, um die DVB-T2 Aufzeichnungen anzusehen.


    In Sachen Konvertierung habe ich mal noch mpeg4 (vcodec libxvid) probiert - aber das frisst die TT6400 gar nicht (kein Bild) - und wäre nat. auch bei doppeltem Platzbedarf ziemlich schlechte Qualität.


    Unter Android tuts der MX Player ganz gut, die HTTP Streams des streamdev-server abzuspielen (also potente HW vorausgesetzt - ein Nexus 9 reichte nicht wirklich, ein Tab S3 dagegen recht gut) - allerdings kann man nicht bei Aufzeichnungen von allen Sendern in der Aufnahme springen - und damit ist es dann bei solchen defakto auch wieder unbrauchbar.


    Dann wollte ich die Sachen noch mit einem Chromecast Ultra abspielen - der kann ja auch HEVC (sogar v.a. für 4K). Doch die DVB-T2 VDR-Aufnahmen spielt er nicht ab, wenn man den HTTP-Stream zB mit LocalCast zu übermitteln versucht - Meldung dass Chromecast das Format nicht abspielen kann. Liegt vermutlich nicht am HEVC sondern am Container (TS)? Mit BubbleUPNP kann man ein "transcoding" aktivieren, und damit kommen die Sachen erstaunlich flüssig und in hoher Qualität raus (dafür dass dann wohl das Tablet die Rekodierung machen muss und das Ergebnis an den Chromecast funkt) - nur auch wieder ohne in der Aufnahme springen zu können, also i.w. in der Praxis unbrauchbar.

  • Für TV-Material mit 50Hz sicherlich die bessere Wahl.

    Aber auch aktuelle Ausgabegeräte schaffen das mit 60Hz vermutlich besser als mein Gerät von 2011

    Adjust Display Refresh Rate" bzw "Sync Playback to Display" hast du aber an ? Dann stellt es den TV auf die Hz um die du gerade nutzt (24p, 50 etc) - die Voreinstellung ist nur dafür das du das häufige umschalten der Frequenz minimieren kannst (wenn man nur 24p nutzt kann man es auf 23,98... stellen und somit brauch der TV nie umschalten).

  • [back from holidays..]

    Adjust Display Refresh Rate" bzw "Sync Playback to Display" hast du aber an ? ..

    Nein, kannte ich nicht und war per default nicht aktiviert!

    Und ja, das ("adjust display refresh rate") hat natürlich den gleichen Effekt, wie wenn ich es gleich fix auf die richtige Frequenz stelle - nur dass der TV dann eben zwischen Oberfläche und Wiedergabe seinen Modus umschaltet.


    Mit anderen Worten: sofern man irgendwie mit Ruckeln zu tun hat, sollte man immer erst mal prüfen, ob da nicht eine Diskrepanz zwischen Frequenz des Ausgabe-Materials und des Displays vorliegt. Dass sowas nämlich richtig üble Ruckelei ergeben kann ("terrible results"), war auch irgendwo bei einer Beschreibung dieser Optionen nachzulesen. Sprich, das hätte auch in meinem Fall sicher jeder so gesehen. Und es ist wohl auch nicht unbedingt Schuld des TV, wenn Kodi den wirklich mit 60Hz anspricht und dann irgendwie Frames aus 50Hz-Material rausgibt: da kann der TV vermutlich gar nichts machen (weil er gar nichts davon weiss was da abläuft)..

    Ich finde ja diese Option sollte per default aktiviert werden - und ggf. eine Fehlermeldung wenn das Display die nötige Frequenz fürs Material nicht beherrscht.


    Ach ja: in Sachen Umrechnung DVB-T2-Aufnahmen für die 6400.

    Umrechnung auf MPEG2 ist vielversprechend.

    ffmpeg -i orig.ts -map 0:v -map 0:a -c:a copy -vcodec mpeg2video -b:v 12000k 00001.ts

    Bei richtig ordentlicher Bitrate (12Mbit) - d.h. 4-5 facher Platzbedarf nach Konvertierung - ergibt das eine recht gute Qualität, die die 6400 tatsächlich abspielt (jedenfalls mit einem VDR 2.0 - mit der Kiste mit dem älteren VDR gabs Probleme). Die index nat. wieder löschen, wird automatisch neu angelegt (dauert etwas, man darf die Wiedergabe so lange nicht abbrechen, aber vermutl. kann man den Index auch so neu erstellen lassen: vdr --genindex=/video/die-aufnahme/[datum-zeit]/). Umrechnung ist gut 3x schneller als bei Konvertierung nach H.264, d.h. besteht wohl zum grössten Teil aus Dekodierung. Aus heutiger Sicht ist MP2 ja fast wie "entpackt".

    Damit sollte es also möglich sein, jede Aufnahme automatisch oder on-demand über das recordings-Menu umzurechnen und so auf dem FFHD-VDR abspielbar zu machen (nur das Spulen ist etwas weniger smooth - evtl. aber auch weil ich das bisher über smb-mount getestet habe).


  • So, das mit der Umrechnung für die FFHD hat sich tatsächlich bewährt.

    Flüssige Wiedergabe in guter Qualität auf der TT 6400 - lediglich alle paar Minuten kleine Audio-Aussetzer (evtl. nur bei ZDF/neo).


    Falls es ausser mir überhaupt noch FFHD-Nutzer gibt (mit Interesse an DVB-T2), hier mein Vorgehen.


    Auf dem Client-VDR (mit der FFHD) eine reccmds.conf (in /etc/vdr o.ä.) anlegen und ein lokales Skript aufrufen (das vom VDR als Parameter den Pfad zur Aufnahme erhält - ala /video/_server/sendung/[date-time]). Das Skript enthält den remote-Aufruf des Konvertier-Skripts auf dem VDR-Server mit den DVB-T2 Aufnahmen:

    Code
    1. ssh vdr-server "/path/to/convert-script $1" > /tmp/last-convert.log 2>&1 &

    Danach am besten noch ein kurzer sleep und dann ein touch /video/.update (damit die neu angelegte zur Konvertierung angestossene Aufnahme direkt sichtbar wird). Auf dem vdr-server muss natürlich unter .ssh/authorized_keys der aufrufende User des client bekannt sein..


    Das Konvertier-Skript auf dem DVB-T2 VDR-Server (am Ende könnte man zusätzlich mit remote-Aufruf zurück an den client / svdrpsend die Fertigstellung melden):

    Dauert wie gesagt ca 1/4 bis 1/3 der Laufzeit (auf einem i5-7500), benötigt 3-6mal den Platz der DVB-T2-Aufnahme.

    Aber kann ja temporär nur zum Ansehen konvertiert werden, archivieren würde man ggf. das Original..
    Vielleicht kanns mal wer brauchen.