Beiträge von hivdr

    Grosses Merci! Sieht gut aus.

    (Konnte es jetzt remote zwar nur über eine Test-Aufnahme BR-Süd probieren, aber da landen jetzt wieder Daten auf der Platte, während das zuletzt immer bei 0-byte-ts blieb.. und ich hab mit der Antenne rumgefuchtelt, statt gleich mal zu recherchieren..)


    Jetzt bin ich nur gespannt, ob es auch bei der Kiste mit dem noch älteren VDR 1.7 auftritt (Wochenende)..


    Der Vollständigkeit halber: ja, natürlich musste ich auch hier die Änderung machen (nur die beiden Buffer in ci.c).


    Grundsätzlich ändert sich hier nur was am Haupt-executable "vdr" - wenn also jemand bei einer definierten Version von yavdr (oder anderen Distri) nur diese Änderung macht, würde es reichen das auszutauschen, ja. Aber das müsste eben erst mal jemand bereitstellen.


    Theoretisch könnte man mal die binaries vorher/nachher diffen (komme von hier aus nicht dran) und sehen, ob das vielleicht nur an zwei Stellen ein Byte betrifft (512 = 0x0200, 1024 = 0x0400, d.h. je nach byte-order zB xxxxx0002xxxx -> xxxxx0004xxxxx) . Und wenn dann davor/danach ein paar Byte nach denen man suchen kann gleich wären über OS-Versionen, Libs, Compiler-Versionen, VDR-Versionen hinweg - dann könnte der "Patch" sogar mit dem Hex-Editor gelingen..

    Also, Halleluja, die segfaults sind weg! Danke!

    (die Änderung in channels.h habe ich wieder rückgängig gemacht, retuning / re-switching darf wieder geschehen)


    Für alle die hier drüber stolpern kurz zusammengefasst:

    Änderungen in ci.c

    • an zwei(!) Stellen Buffer-Grösse hochsetzen
      uint8_t caDescriptors[512]; ---> uint8_t caDescriptors[1024];
    • in Funktion (weiss nicht wie essentiell das für das Problem hier konkret ist)
      void cCiCaPmt::AddCaDescriptors(int Length, const uint8_t *Data)
      oben einfügen: if (Length < 0) return;


    Jetzt bin ich nur gespannt, ob es auch bei der Kiste mit dem noch älteren VDR 1.7 auftritt (Wochenende)..


    (Der Richtext-Editor hier funktioniert ja mehr so mittel..)


    Für verschlüsselte Sender gab es schon vor längerer Zeit einen Fix, der müsste eigentlich im vdr 2.2.x drin sein.


    Lars.

    OK, aber ich kann den halt nicht (jedenfalls nicht mal eben / nicht so bald) einfach updaten / neu installieren. Daher würde ich gerne versuchen die entscheidende Änderung selbst in meinen 2.0.3 zu patchen. Aber welches ist diese Änderung. Evtl. das mit dem zu kleinen Buffer (ntv-Thread S.4, Änderung in ci.c)? Tatsächlich sind da gegenüber vor einigen Monaten (vielleicht aber auch erst seit Donnerstag) neue CA-IDs hinzugekommen in der channels-config.

    Also ich kann den Effekt bestätigen, bin aber kein yavdr user. Habe den VDR 2.0.3 auf meiner Kiste.


    Erstmals Freitag Abend, P7S1-Transponder (HD-), segfault. Zunächst im Log immer zu sehen "retuning" und erneuter Switch auf den gleichen Kanal, gefolgt vom segfault. Habe dann Code etwas angepasst (channels.h CHANNELMOD_RETUNE auf 0, so dass er sozusagen wegen keiner Änderung im Kanal einen retune macht), damit verschwand der retune/re-switch, das Problem aber nicht wirklich (wobei auch nicht klar war weswegen der retune passiert, Logausgabe zeigt in der Version wohl das nicht an). S1 kann ich live hinschalten, erst nach dem Wegschalten segfault/restart. P7 sofort segfault. Aufnahmen gehen bei beiden (und wohl auch weiteren Sendern des Bouquets), aber mit segfault/restart je bei Aufnahme-Start und Aufnahme-Ende. Es dürfen also jeweils keine anderen Aufnahmen laufen, jedenfalls wenn man bei denen keine 20s-Lücken haben möchte.


    Segfault sehr ähnlich zu dem im oben erwähnten Thread zu ntv (muss ich noch reinlesen):

    kernel: [9603.298457] vdr[2668]: segfault at 7fff2a76d000 ip 00007f2afccd6abb sp 00007fff2a769c18 error 6 in libc-2.13.so[7f2afcc4c000+18a000]


    Da meine Kiste nicht mal eben upgedatet werden kann (uralte OS-Basis), aber jederzeit der vdr im Source im Detail modifiziert und rekompiliert, wäre ich interessiert, wenn jemand weiss, woran das eigentlich liegt - und wo im Source man also vielleicht die Ursache beheben könnte..

    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.

    [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).


    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.

    [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.


    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).

    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.

    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.

    Wäre natürlich cool, wenn das Problem beim Hochfahren behoben werden könnte, so dass der VDR immer stabil den satip-Server findet.
    Wenn Du mir sagst, wo ich interessante Log-Ausgaben finde, kann ich die gerne auch mal prüfen / hier reinstellen.
    (Update wäre dann wohl wie hier beschrieben: https://wiki.libreelec.tv/inde…e=HOW_TO:Update_LibreELEC)


    Wie man bei tvh oder vdr einen "Komplett-Scan" unabhängig von vordefinierten Parametern für bestimmte Regionen macht, weiss ich nicht. Bei VDR fand ich immer fertige channels (und neue auf bestehenden Transpondern fügt er eh ganz automatisch hinzu). Dieser Scan in der Kodi-GUI jedenfalls verlangt doch eine Auswahl soweit ich mich erinnere. Bei tvh kann ich ja nochmal einen Versuch unternehmen, aber keine Ahnung ob ich da von selbst draufkomme wie man das macht.


    Mittlerweile habe ich aber auch passende/fertige channels bekommen:
    yaVDR und DVB-T2?


    Die habe ich an zwei Stellen unterhalb /storage hinterlegt (wo eben mittels find ein channels.conf zu finden war) - welche der beiden Stellen die "richtige" war und was die andere ist weiss ich nicht.
    Erst half auch das nichts (trotz disable/enable VDR-Service) - aber da war eben dann auch bei Blick in die VDR-config satip-plugin wieder der satip Server nicht zu sehen.
    Nach einem Reboot und disable/enable dann konnte ich tatsächlich über VDR-Service/VDR-VNSI-Client im Bereich Live-TV die Sender sehen.
    Soweit stabil / Audio synchron. Umschaltung dauert zwar immer noch viele Sekunden, aber das ist viel schneller als beim IPTV-Addon.
    Aufnahmen funktionieren im Prinzip, haben aber immer wieder Aussetzer. An der Micro-SD-Karte dürfte es nicht liegen, die war beim Image-Schreiben ziemlich schnell - aber vielleicht ist sie es ja im Kartenleser des Hub nicht so sehr. Oder aber da ist die HW des Hub dann eben doch gelegentlich überfordert, den Datenstrom unterbrechungsfrei abzulegen.


    Immerhin kann ich jetzt die satip-Tuner (bzw. einen, ein zweiter Transponder bei 1 Aufnahme ging auch nicht) mal grundsätzlich stabil für Live-TV nutzen (wenn der VDR den satip-Server findet).

    Die Channelpedia hat am Wochenende noch keine DVB-T2 Kanäle akzeptiert - ich habe hepi deswegen schon angeschrieben und ihm die DVB-T2 Kanalliste für München als Beispiel geschickt - ich denke er wird die Channelpedia bei Gelegenheit entsprechend anpassen.

    Auch aktuell finde ich dort nichts zu DVB-T2 - mit Ausnahme von Hessen/Wiesbaden:
    http://channelpedia.yavdr.com/gen/DVB-T/de/Wiesbaden/
    Das sogar mit Datum von Ende März, was also grade so nicht ganz zu Deiner Aussage passt.


    Aber warum ich poste: ich wäre auf der Suche nach einer channels.conf für DVB-T2 Muc - und finde eben nirgendwo welche.
    Magst Du sie einfach hier mal reinpasten? Das würde vielleicht noch viele andere in der Zukunft freuen, wenn sie das hier finden können..


    (ich möchte sie einem vdr unter libreelec auf einem Wetek Hub "unterschieben", da das Scannen mit einem sat-ip device Octo Net V2 mit 2xT2 einfach nicht klappt)


    Früher habe ich eigentlich alle Kanäle immer aus irgendeinem Post in diesem Forum rauskopieren können (S2), aber mit DVB-T2 scheinen auch nach 2 Monaten noch nicht wirklich viele Leute unterwegs zu sein.


    Danke!

    OK, Einstellung gefunden, Danke. Geholfen hat sie leider nicht: auch mit der Einstellung (nach Reboot) taucht beim Scan erst ein Device auf, wenn man den VDR vorher disabled/enabled hat.
    Als Wartezeit habe ich sogar 10s - da bei Dir 4 zu reichen scheinen, sollte das nicht zu knapp sein. Mein LAN/DHCP arbeitet normal.
    Das mit Yatse klingt interessant (ein Tablet hab ich rumliegen), wenns denn funktioniert (laut Bewertungen längst nicht bei jedem).


    Aber das alles sind ja leider eh nur Nebenschauplätze: der eigentliche Scan für DVB-T2 klappt eben nicht. Bis auf weiteres muss ich wohl aufgeben, bis sich da was tut. Oder ich habe mal ganz viel Zeit, finde raus wo die Scan-Parameter hinterlegt sind, kann die anhand der config des DD-TV manuell anpassen (welche Felder stehen wo / wie das eine aufs andere Format abbilden) usw. Oder mache das ganze mit m3u Playlist zu channels.conf. Oder schaffe es mal mit einem DVB-T2 Stick an einem Rechner mit ausreichend aktuellem Linux (Treiber) einen Scan zu machen.


    Also falls jemand wo mal VDR channels für DVB-T2 Muc/Wendelstein gesehen hat..


    Naja. Frühestens weiter nächste Woche.

    Danke für die Hilfe CvH. Die Einstellung "Warten auf Netzwerk" habe ich erst mal nicht gefunden (obwohl garantiert schon mal wo gesehen), aber der Hinweis scheint korrekt: nachdem ich den Service VDR-Backend disabled und enabled habe, war dann tatsächlich der Octo in der satip-plugin-config zu sehen. Obwohl es LAN ist, kein WLAN.


    Die Möglichkeit ins VDR-OSD einzusteigen hatte ich auch noch nicht entdeckt! Problem nur: mit der (schon erwähnten) Minimal-FB des Hub kommt man da nicht mehr raus! (keine Info-Taste) Nur Reboot hilft (Power wirkt mit Verzögerung, aber auch ohne Anzeige am Bildschirm). Auch zB Farbtasten gibt es nicht, ebensowenig wie Ziffern etc. Also VDR-Bedienung wäre wohl generell auch ziemlich eingeschränkt.
    Trotzdem konnte ich so wie oben gesagt dann in der plugin-config für satip erst keinen satip-Server sehen, bei vorherigem disable/enable des VDR dann schon.
    Und damit war dann auch beim "Scan" mehr zu sehen: als device "sat->ip 0", und er hat Frequenzen hochgezählt. Allerdings recht flott und ohne irgendwas zu finden.


    Ich befürchte dass auch hier (wie schon bei tvh) mit der vordefinierten Auswahlmöglichkeit DVB-T/Germany einfach noch die Parameter fürs alte SD-DVB-T1 hinterlegt sind und deshalb nichts gefunden wird. Frage wäre also, wie bekommt man neue configs fürs (inzwischen immerhin fast 2 Monate alte und vorher 1 Jahr im Testbetrieb befindliche) neue dt. DVB-T2 da rein (und wo bekommt man sie her)?
    Wenn man fertige channels hinterlegen würde (aber auch da finde ich wie gesagt nichts für DVB-T2), müsste er dann automatisch erkennen dass der Octo ein geeignetes Device dafür ist?


    Mühsam das mit dem DVB-T2. Würde ich das alles mit DVB-S2 machen, hätt wahrscheinlich fast alles auf Anhieb funktioniert..


    Zur Wiedergabe. Zum einen habe ich auch den Eindruck dass es besonders zum Start sehr ruckelt (zB Anfang Folge 3 von Hindafing, BR-Mediathek) und dann etwas besser wird. Natürlich auch nur bei Szenen wo sich etwas mehr tut (sprich Bewegung und höhere Datenrate - am Internetzugang liegts nicht, 100Mbit). Zum anderen glaube ich man gewöhnt sich so ein bisschen dran. Wenn man es aber mit dem FFHD-VDR vergleicht, ein Unterschied wie Tag und Nacht. Aber da bin ich halt verwöhnt / anspruchsvoll. Wäre auch erstaunlich, wenn man für 99 Euro einen VDR bekommt, der so gut ist, wie wenn man da sehr viel mehr investiert.. wie gesagt, wäre trotzdem dankbar, wenn der bis auf weiteres für DVB-T2 verwendbar wäre, da eine FFHD nun mal leider kein H.265 wiedergeben kann (und der einst selbst ganz manuell installierte VDR so alt ist, dass man nicht mal eben das satip-plugin nachrüsten kann - und ein Neu-Aufsetzen des bestehenden scheidet aus, absolute Stabilität/Verfügbarkeit des status quo hat absolute Priorität. Wenn dann also kompletter Neubau irgendwann).