Ich habe Full genommen, weil man eben nicht weiß, ob man es vielleicht irgendwann braucht.
Posts by kfb77
-
-
Stand heute nutzt Astra nur QPSK und 8PSK.
Was morgen sein wird, weiß nur die Glaskugel.
-
Glücklicherweise sind Stromausfälle in Deutschland recht selten und wenn man ihn selber verursacht hat, kann man ja die Kiste nochmals neu starten, wenn der DHCP Server wieder da ist.
Aber ihr habt mich überzeugt, ich habe meine Octopus IP jetzt auch statisch konfiguriert.
-
Ich kann bestätigen, dass es immer angeht, wenn er zuvor an war. Welche Zustand er bekommt, wenn er zuvor aus war, ist für mich nicht relevant, da er nie aus ist.
Ist werde das auch nicht testen, weil provozierte Stromausfälle unnötig riskant sind.
-
Das ist eine Anleitung, wie es geht, wenn man das machen will, aber keine Empfehlung.
-
ist aber eine Empfehlung von DD
Im Handbuch finde ich das nicht. Quelle ?
-
Der DHCP Server weist im immer die gleiche IP Adresse zu. Ist flexibler bezüglich Umzug in anderes IP Subnet, als im Endgerät fest konfiguriert.
-
Also meine SX8SL geht nach einem Stromausfall wieder von alleine an. Nutzt mir nur nichts, da sie schneller bootet, wie mein DHCP Server und damit keine IP Adresse bekommt und somit auch nicht funktioniert.
-
Im satip Plugin über den Parameter:
# -d <num>, --devices=<number> set number of devices to be created
-
- Wie limitierst du/man dass wie in meinem Fall ein Client nicht dem anderen die 8 Transponder "klaut" ?
- Sehe ich das richtig, dass jeder Client seinen eigene channels.conf hat (bei mir bleiben die aber wohl ident)Dem VDR nimmt keiner ein Device weg, er belegt es beim Start und gibt es nie wieder her. Zumindest wenn man dies nicht über Patches umgeht.
Bei den anderen Clients (z.B. Kodi mit OctopusNet Plugin) gewinnt eben der, der zuerst da ist.
Jeder VDR hat seine eigene channel.conf. Die muss nicht zwangsweise identisch sein.
-
Unicast max. 8 Clients: Da du einen headless VDR betriebst hast du aus Sicht des Octopus eig. nur einen Client oder ?
Nein, so einfach ist meine Welt nicht:
1. OctopusNet SXSL: produktiver Headles VDR mit 4 Devices, Test Headless VDR mit 2 Devices, 2 Laptops mit Kodi und OctopusNet Plugin.
2. OctopusNet MC (halb defekt, es gehen nur noch 2 Tuner): 2 Panasonic TVs.
-
Die Einschränkung ist nachvollziehbar, einmal bezahlen und beliebig oft nutzen geht halt nicht.
-
Meine Octopus läuft auch im Unicast Modus und ich nutze kein CiCAM.
Das würde passen bei CiCAM Nutzung
Warum nur da ?
In beiden Varianten hat man Grenzen:
Multcast: maximale Anzahl möglicher Transpondern von 12 bei beliebig vielen Clients. Die Variante sehe ich eher in einem Hotel.
Unicast: Alle Transponder bei maximal 8 Clients (möglicherweise gehen sogar 12, sofern sie einen der getunten Transponder nutzen, habe ich nie getestet, würde ich auch nicht nutzen, da das Verhalten nicht vorhersagbar wäre). Die Variante halte ich bei VDR für sinnvoll.
-
Bin damals 2 Versionen zurück, damit baut er ohne murren.
Header patchen fand ich einfacher.
-
Die Version 4.2.13 von vdr-plugin-markad ist verfügbar.
Bei Probleme bitte immer die vollständige markad.log posten.
2025-05-07: Version 4.2.13
- some minor bug fixes and optimizations, see gitKeine großen Änderungen, nur so Kleinkram, die mir die letzten Wochen aufgefallen sind.
-
Hatte ich beim ersten Neustart nach dem Update auch. Sind aber jetzt weg. Muss man beobachten ...
-
Das gab es schon mal hier: EPGD build error unter g++-14
Lösung: Wende diesen diff ohne die Zeile "enum Item_result {STRING_RESULT,REAL_RESULT,INT_RESULT,ROW_RESULT,DECIMAL_RESULT};" an, dann baut es wieder. Habe ich gerade auch so gemacht.
-
Live zeigt auch die doppelte Länge an, "touch .update" bringt nichts, nach VDR restart stimmt die Länge.
-
Um den Suchpfad für die Programmausführung mache ich mir auch weniger Sorgen, weil das doppelte FFmpeg in /usr/local/bin wird auch seine zugehörigen Libs in /usr/local/lib finden wird. Mehr Sorgen mache ich mir bei den FFmpeg Libs:
root@VDR-2004-easyvdr5:~# cat /etc/ld.so.conf.d/*
# libc default configuration
/usr/local/lib
# Multiarch support
/usr/local/lib/x86_64-linux-gnu
/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnumarkad wird damit zufrieden sein, sofern es gegen das neue FFmpeg gebaut wurde.
softhddevice wird seine FFmpeg Libs auch aus /usr/local/lib ziehen und die passen dann nicht mit dem zusammen, mit denen es gebaut wurde. Also auch neu bauen. Und was noch ?
Läuft hier sehr gut, auch für softhdcuvid.
Neu gebaut ?
Wenn man ein Programm mehrfach in unterschiedlichen Versionen auf dem System hat, muss man sehr genau wissen, was man da macht, insbesondere wenn andere Programme Libs davon verwenden. Bei FFmpeg auf einem Multimedia System kann das ein Fass ohne Boden werden. Ich würde davon dringend abraten.
-
Ja, da haben noch ein paar Libs und Header gefehlt. Auch der Prefix muss auf /usr geändert werden, sonst wird das aus dem Packet installierte FFmpeg nicht überschrieben (auch nicht wirklich sauber). Besser vorher das Packet FFmpeg deinstallieren (Vorsicht: kann andere Pakete wegen Abhängigkeiten mit deinstallieren) und den Build nach /usr/local (default) installieren lassen. Hier ein Update (build unter easyVDR 5 getestet):
sudo bash
apt-get -y install build-essential git pkg-config yasm nasm libx264-dev libzvbi-dev
cd /usr/src
git clone https://github.com/FFmpeg/FFmpeg
cd FFmpeg
git checkout n6.1.2
./configure --prefix=/usr --enable-nonfree --enable-libx264 --enable-gpl --enable-libzvbi
make all
make installNoch eine kleine Warnung an der Stelle: Ich habe keine Ahnung, ob andere Plugins, Tools, ... bei easyVDR noch FFmpeg nutzen und nach einem Update vielleicht nicht mehr laufen, oder zumindest neu gegen FFmpeg gebaut werden müssen. markad wird funktionieren, muss aber auf jeden Fall gegen das neue FFmepeg gebaut werden. Alles nicht "easy", bitte nicht annehmen, ich hätte den Weg empfohlen.
Ein möglichweise besserer Weg wäre, markad statisch gegen FFmpeg 6.1.2 zu linken und alles andere unangetastet zu lassen. Ich habe das aber auch noch nie gemacht, hier musste jemand einen Weg aufzeigen, wie das geht.
