Beiträge von hivdr

Zitat von 9000H

der Digibit R1(satip-axe firmware) bzw minisatip kann LNB share

-S --slave ADAPTER1,ADAPTER2-ADAPTER4[,..]:MASTER - specify slave adapters

nützt nur leider nichts mit dem Digibit Twin.

OK, bin da nicht im Thema: minisatip ist ja aber in erster Linie ein Server.

Die Frage ist, ob man diese Funktionalität von minisatip theoretisch auch mit minisatip als eine Art satip-Proxy nutzen könnte:

"Minisatip can act as a satip client as well in order to connect to satip servers from different networks"

Für mich persönlich führt das aber zu weit, wir werden wohl bis auf weiteres den zweiten DigibitTwin-Tuner brachliegen lassen müssen.

Also wenn man das direkt im satip-Server einstellen könnte wäre das natürlich optimal. Aber das ist wohl Wunschdenken, jedenfalls bei günstigen Geräten wie dem Digibit Twin: ausser der IP o. DHCP und einem Admin-PW kann man da nicht garzu viel konfigurieren.

Grundsätzlich wäre es ja auch absolut denkbar (ein "Ideal-Szenario") dass die virtuellen satip-devices so tiefgreifend im System eingebunden werden (auf Treiber-Ebene sozusagen), dass es aus VDR-Sicht keinen Unterschied zu realer lokaler HW gibt, dann würde eben sowas wie das Bonding ganz automatisch auch mit satip klappen.

Ganz abstrakt gedacht natürlich, keine Ahnung ob da doch technische Details dagegensprechen, Dinge in der Schnittstelle die man mit satip nicht ausreichend umfänglich "simulieren" kann.

Doch jedenfalls könnte ja das Plugin seinerseits das tun, was auch der VDR sonst mit dem Bonding Patch macht: erkennen, dass bei Nutzung von Tuner1 für Tuner2 nur die Sender der gleichen Ebene verfügbar sind (da sonst Konflikt). Und das ggf. zurückmelden ("Kanal nicht verfügbar"). Wenn man via satip den Tuner2 nicht auf einen konkurrierenden Channel ansetzt, wird das der satip-Server ja wohl von selbst auch nicht tun - der Konflikt wäre vermieden. Setzt natürlich voraus dass der satip-Server exklusiv vom VDR genutzt wird!

OK, also doch genau andersherum und wie befürchtet - vom satip-Plugin erzeugte Devices berücksichtigen die Bonding Einstellungen aus der VDR-config (bei VDR mit Patch) in keiner Weise.

Schade, aber jedenfalls geklärt, Danke!

Dass das Bonding auch bei satip grundsätzlich ein in der Praxis vorkommender bzw. wünschenswerter Anwendungsfall sein kann habe ich hiermit - womöglich als erster - hier erwähnt

Das müsste also vermutlich wenn dann im satip-Plugin nachgerüstet werden.

Zitat von kls

Was hat satip mit Device-Bonding (alias "LNB-Sharing") zu tun?

Tja, ganz offensichtlich weiss ich es nicht

Da es bei mir anderswo funktioniert, das Bonding, und hier nicht, hielt ich es eben erst mal für naheliegend, dass es mit der Tatsache zu tun hat, dass ich hier kein "normales" device mehr habe, sondern das satip-plugin nutze, das ja letztlich HW "simuliert" oder "fernsteuert" oder wie auch immer man das nennen will.

Der Frage entnehme ich, dass das plugin eigentlich auf so tiefer Schicht das (virtuelle) device realisiert, dass es aus VDR-Sicht keinen Unterschied machen sollte, jedenfalls nicht für das Bonding. Macht Sinn.

Nur leider klappt es eben nicht (wie beschrieben). In den VDR Einstellungen zu LNB sah ich die Einstellungen zum Bonding und setzte sie entsprechend (zwei Tuner, gleicher LNB-Index), aber ohne den erwarteten Effekt (dass der zweite Tuner für Sender falscher Ebenen gesperrt wird - "Kanal nicht verfügbar").

Demnach gehst Du eher davon aus, dass das Problem beim LNB-Sharing-Patch im EasyVDR 2.0 liegt? (ist ja nicht mehr ganz taufrisch, aber grössere Neuinstallation ist demnächst leider zeitlich nicht drin)

Beim VDR meiner Eltern (EasyVDR 2.0 / inst. Anfang 2016) ging neulich das DVB-Device (TT S2-3600) kaputt, und da das Modell inzwischen kaum noch zu bekommen ist habe ich es durch ein Digibit Twin ersetzt.

Erst gab es massive Probleme, doch nachdem ich dem satip-Plugin die Option "-d 1" mitgegeben habe läuft bisher alles sehr stabil (bis auf etwas schlechtere Umschaltzeiten) - denn wir haben dort nur eine Leitung, der Digibit hat wie der Name "Twin" schon sagt zwei Tuner mit zwei separaten Anschlüssen. VDR nutzt also aktuell nur noch einen Tuner.

Mit default (-d 2) versucht der VDR ja immer wieder mal das device/frontend - also den Tuner - zu wechseln. Ohne Kabel am zweiten Anschluss geht dann natürlich gar nichts, mit einem Splitter klappt es grundsätzlich, da die meisten der hierzulande genutzten Programme auf einer gemeinsamen Ebene liegen (H/V,high/low). Doch es ist wohl der EPG-Scan, der bei Live-TV mit dem zweiten Tuner im Hintergrund auf die Reise geht und früher oder später doch auf eine andere Ebene umschaltet (zB 3sat). Dann steht das Live-Bild. Schon davor hat man dauernd Artefakte im Bild.

Nun wäre es grundsätzlich schön, beide Tuner nutzen zu können, da in der Praxis wie gesagt die meisten Transponder vereinbar wären. Dafür gibt es ja den LNB Sharing Patch, den ich auch erfolgreich in einem meiner selbst installierten VDR nutze. Auch Easyvdr hat den offenbar drin, doch es hilft nichts hier in den Einstellungen für die beiden Tuner den gleichen LNB anzugeben. VDR versucht trotzdem zB bei Aufnahme ARD auf 3sat zu schalten - obwohl er ja dank Sharing-config wissen müsste dass das in dem Fall nicht geht. Ist das LNB-Sharing im EasyVDR 2.0 defekt? Oder - wahrscheinlicher? - berücksichtigt das satip-Plugin diese Vorgabe nicht?

Allerdings sind auch die Artefakte sehr unschön, solange der Hintergrund-Tuner eigentlich noch auf der gleichen Ebene läuft. Sind beim Digibit da Probleme bekannt, dass sich die beiden Tuner gegenseitig stören beim Umschalten, jedenfalls bei gemeinsamer (via Splitter) Leitung? Mit zwei unabhängigen Leitungen kann ich leider nicht testen, da eben nicht vorhanden.

Probleme bei der Netzwerk-Verbindung sind praktisch ausgeschlossen, es handelt sich um eine (kurze) Direktverbindung und zwei gleichzeitige Streams müssten ja mehr als locker drin sein.

Einmal mehr Danke für den Service, Aufnahme scheint zu klappen!

Tja, ich schon wieder.. offenbar klappt mit SAT-IP auch die Auto-Erkennung neuer Kanäle auf bestehenden Transpondern nicht.

Ich wäre interessiert am Eintrag für NDR auf dem ARD-Bouquet (Muc DVB-T2), mind. seit gestern aufgeschaltet.

Schade dass es kein aktuelles Verzeichnis für sowas mehr gibt, bei den meisten scheint der Scan wohl gut zu funktionieren.

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

Seit 24.4. ist das BR-Bouquet umgezogen auf Kanal 30:

https://www.br.de/unternehmen/…enchen-dvb-t2-hd-102.html

Hätte jemand die channels dafür? Auch bei channelpedia stehen noch die alten.

(Sorry, das mit dem Scannen habe ich nie hinbekommen, und v.a. habe ich T2 nur über sat-ip, und davon steht auf der Wiki-Seite zu w_scan gar nichts..)

Zitat von hivdr

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

Zitat von manowar

Kann den jemand mal bitte den Pfad zur ci.c posten. Ich finde das nicht.

Die Rede ist hier vom Sourcecode von VDR - nach Änderungen muss man ihn neu bauen.

Die ci.c liegt (jedenfalls bei 2.0.x) direkt im Hauptverzeichnis des source. Generell kannst Du sonst danach suchen mit 'find / -name ci.c' oder mit locate (falls installiert).

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

Merci, dann komme ich hoffentlich heute Nacht mal dazu das zu probieren.

Zitat von mini73

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:

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

#!/bin/bash

## convert VDR recording DVB-T2 / h.265 to MPEG2 for FFHD 6400
#

if [[ "$1a" == "a" ]]
then
 echo "missing parameter"
 exit
fi

RECORDING=$1

# strip trailing slash
if [[ "$RECORDING" == *\/ ]]
then
 RECORDING=${RECORDING:0:${#RECORDING}-1}
fi

RECORDING=${RECORDING:1:${#RECORDING}-1} # strip leading slash
RECORDING=${RECORDING#*/}  # strip video/
RECORDING=${RECORDING#_*/} # strip subdir _xx of server on client
NAME=${RECORDING%/*}
TIMESTAMP=${RECORDING#*/}

# original / target
RECORDING="/video/$NAME/$TIMESTAMP"
TARGET1="/video/$NAME-mp2"
TARGET="/video/$NAME-mp2/$TIMESTAMP"

echo "recording: $RECORDING"
echo "target:    $TARGET"

# copy
mkdir $TARGET1
cp -a $RECORDING $TARGET1
cd $TARGET

# convert
for ts in `ls 000*.ts`
do
  mv $ts orig.ts
  echo "converting $ts .."
  ffmpeg -i orig.ts -map 0:v -map 0:a -c:a copy -vcodec mpeg2video -b:v 12000k $ts >> convert.log 2>&1
  rm orig.ts
done

# recreate index with vdr commandline
echo "recreating index.."
rm index
vdr --genindex=$TARGET

echo "done." `date`
#end.

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

Zitat von CvH

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