Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.comp.os.unix.linux.misc > #112150 > unrolled thread

raspi vdr proxy

Back to article view | Back to de.comp.os.unix.linux.misc

Contents

  raspi vdr proxy Jan Novak <repcom@gmail.com> - 2020-09-29 08:25 +0200
    Re: raspi vdr proxy Marcel Mueller <news.5.maazl@spamgourmet.org> - 2020-09-29 09:51 +0200
      Re: raspi vdr proxy Jan Novak <repcom@gmail.com> - 2020-09-29 10:07 +0200
        Re: raspi vdr proxy Marcel Mueller <news.5.maazl@spamgourmet.org> - 2020-09-29 12:00 +0200
          Re: raspi vdr proxy Jan Novak <repcom@gmail.com> - 2020-09-29 14:03 +0200
            Re: raspi vdr proxy Marcel Mueller <news.5.maazl@spamgourmet.org> - 2020-09-29 17:01 +0200
              Re: raspi vdr proxy Jan Novak <repcom@gmail.com> - 2020-09-30 08:44 +0200
                Re: raspi vdr proxy Marcel Mueller <news.5.maazl@spamgourmet.org> - 2020-09-30 09:22 +0200
                  Re: raspi vdr proxy Jan Novak <repcom@gmail.com> - 2020-09-30 09:37 +0200
                    Re: raspi vdr proxy Marcel Mueller <news.5.maazl@spamgourmet.org> - 2020-09-30 11:53 +0200
            Re: raspi vdr proxy Manuel Reimer <manuel.nulldevice@nurfuerspam.de> - 2020-09-29 18:08 +0200
              Re: raspi vdr proxy Jan Novak <repcom@gmail.com> - 2020-09-30 08:37 +0200
                Re: raspi vdr proxy Manuel Reimer <manuel.nulldevice@nurfuerspam.de> - 2020-10-01 14:28 +0200
                  Re: raspi vdr proxy Andreas Fenner <Andis_Spamtonne@web.de> - 2020-10-01 18:10 +0200

#112150 — raspi vdr proxy

Moin,

ich habe zu Hause ein laufenden VDR Server mit 2 SAT Karten als 
Stremingserver laufen (headless).

Habe mir folgendes Szenario überlegt:
In einer Ferienwohnung würde ich gerne einen Raspi4 als (VDR-) Proxy 
einsetzen, welcher den VDR dort verfügbar macht (auch nur zum streamen). 
Der Raspi bekommt einen VPN zum Home Server, so dass das Homenetz - oder 
nur der VDR Server - im Ferienhaus verfügbar ist.

Somit müssen die (mobilen) Clients in der Ferienwohnung nichts vom VPN 
wissen, sind einfach nur dort im Wlan eingebunden und können die Streams 
des VDR's nutzen (Bandbreite vorrausgesetzt).

Wie könnte eine Lösung dafür aussehen?


Jan

[toc] | [next] | [standalone]

#112151

Am 29.09.20 um 08:25 schrieb Jan Novak:
> ich habe zu Hause ein laufenden VDR Server mit 2 SAT Karten als 
> Stremingserver laufen (headless).
> 
> Habe mir folgendes Szenario überlegt:
> In einer Ferienwohnung würde ich gerne einen Raspi4 als (VDR-) Proxy 
> einsetzen, welcher den VDR dort verfügbar macht (auch nur zum streamen). 
> Der Raspi bekommt einen VPN zum Home Server, so dass das Homenetz - oder 
> nur der VDR Server - im Ferienhaus verfügbar ist.
> 
> Somit müssen die (mobilen) Clients in der Ferienwohnung nichts vom VPN 
> wissen, sind einfach nur dort im Wlan eingebunden und können die Streams 
> des VDR's nutzen (Bandbreite vorrausgesetzt).
> 
> Wie könnte eine Lösung dafür aussehen?

Ich bin jetzt nicht /der/ VPN Experte, aber für so was würde ich vmtl. 
einfach einen SSH-Tunnel für den Port nehmen. Der Raspi tritt dann als 
"virtueller" VDR-Server im lokalen Netz auf. Aus Sicherheitsgründen 
könnte man ferner erwägen, den Tunnel rückwärts aufzubauen, also vom 
VDR-Server aus. Dann kann ein gehackter Raspi nicht so leicht in dein 
Netz eindringen. Allerdings braucht der Raspi dafür eine öffentliche 
Adresse. (IPV6 + dyndns o.ä. sollte reichen)

Ein Port-Forwarding braucht man auf jeden Fall, denn der VDR-Server soll 
ja mutmaßlich in den lokalen IP-Bereich der FeWo eingeblendet werden. 
Alles andere würde zumindest einen Eingriff in die Routing-Tabelle des 
dortigen Standard-Gateways bedeuten, was gar nicht bei allen 
Internetroutern geht.

Du musst halt gucken, welche Dienste du für Client/Server brauchst. VDR 
Live, streamdev-server oder VNSI haben alle unterschiedliche Ports.


Marcel

[toc] | [prev] | [next] | [standalone]

#112152

Am 29.09.20 um 09:51 schrieb Marcel Mueller:
> Der Raspi tritt dann als 
> "virtueller" VDR-Server im lokalen Netz auf.

wie genau würde das denn aussehen?Läuft dort dann auch eine vdr Instanz?


> Ein Port-Forwarding braucht man auf jeden Fall, denn der VDR-Server soll 
> ja mutmaßlich in den lokalen IP-Bereich der FeWo eingeblendet werden. 
> Alles andere würde zumindest einen Eingriff in die Routing-Tabelle des 
> dortigen Standard-Gateways bedeuten, was gar nicht bei allen 
> Internetroutern geht.

sehe ich genauso. Vor allem wies sich noch gar nicht, welchen Router ich 
dort bekomme (EU Ausland).


> Du musst halt gucken, welche Dienste du für Client/Server brauchst. VDR 
> Live, streamdev-server oder VNSI haben alle unterschiedliche Ports.

letztendlich nur den Streamdev Server, also nur ein Port.
Der VPN Tunnel stellt die Verbindung zum VDR@Home her (oder umgekehrt, 
wegen, wie du schriebst) und damit kennt der raspi den VDR und "alle" 
seine Dienste. Ein Portforwarding wäre doch gar nicht notwendig.
Aber wie gehts jetzt weiter?

Jan

[toc] | [prev] | [next] | [standalone]

#112153

Am 29.09.20 um 10:07 schrieb Jan Novak:
> Am 29.09.20 um 09:51 schrieb Marcel Mueller:
>> Der Raspi tritt dann als "virtueller" VDR-Server im lokalen Netz auf.
> 
> wie genau würde das denn aussehen?Läuft dort dann auch eine vdr Instanz?

Nein, das würde ich nicht machen. Das ergibt nur Sinn, wenn selbiger 
gleichzeitig das Abspielgerät wäre.

Aber aus Sicht der Clients ist natürlich jede IP, die die entsprechenden 
  Dienste für VDR anbietet ein VDR-Server, auch wenn es sich nur um 
weitergeleitete Ports handelt.

>> Du musst halt gucken, welche Dienste du für Client/Server brauchst. 
>> VDR Live, streamdev-server oder VNSI haben alle unterschiedliche Ports.
> 
> letztendlich nur den Streamdev Server, also nur ein Port.

Das heißt, alle Clients haben eigenständige VDR-Instanzen mit 
streamdev-client Plugin.

Realistisch betrachtet wirst du in dem Fall noch SVDRP freigeben wollen, 
damit die Clients sich die EPG-Daten synchronisieren können, ohne dass 
jeder Client dauernd eigenständig die Kanäle scannen muss, was Tuner 
blockiert.

> Der VPN Tunnel stellt die Verbindung zum VDR@Home her (oder umgekehrt, 
> wegen, wie du schriebst) und damit kennt der raspi den VDR und "alle" 
> seine Dienste. Ein Portforwarding wäre doch gar nicht notwendig.

Wenn man VPN macht und es nicht gerade ein Subnetz-VPN ist, dann kann 
ausschließlich das Gerät mit dem VPN-Tunnel auf die Remote-Dienste 
zugreifen.
Wenn alle Rechner in einem Subnetz VPN-Zugriff bekommen sollen, wäre das 
ein Subnetz zu Subnetz VPN. Und das wiederum kann natürlich nur ein 
Router anbieten, denn es müssen ja nun entfernte IP-Adressen über den 
VPN-Tunnel geroutet werden. Auf gut deutsch vergiss es, es sei denn, der 
Raspi soll Standard-Gateway für den gesamten Internet-Traffic werden - 
also ein Internet-Router.

Heißt, selbst mit Punkt zu Punkt VPN bräuchtest du immer noch Port 
Forwarding auf dem Raspi. Das wiederum kann SSH meines Wissen auch 
/ohne/ VPN (Remote Port Forwarding). Der SSH-Tunnel ist ebenfalls 
verschlüsselt und vergleichbar sicher.


Marcel

[toc] | [prev] | [next] | [standalone]

#112159

Am 29.09.20 um 12:00 schrieb Marcel Mueller:
>> letztendlich nur den Streamdev Server, also nur ein Port.
> 
> Das heißt, alle Clients haben eigenständige VDR-Instanzen mit 
> streamdev-client Plugin.

Ne, das sind alles Handys, Notebooks / ect. i.dR. mit VLC als player.


> Realistisch betrachtet wirst du in dem Fall noch SVDRP freigeben wollen, 
> damit die Clients sich die EPG-Daten synchronisieren können, ohne dass 
> jeder Client dauernd eigenständig die Kanäle scannen muss, was Tuner 
> blockiert.

Tut das ein VLC Client denn?

> Wenn man VPN macht und es nicht gerade ein Subnetz-VPN ist, dann kann 
> ausschließlich das Gerät mit dem VPN-Tunnel auf die Remote-Dienste 
> zugreifen.

hmmm... also wenn der Raspi quasi nur der "Tunnelzugang" wäre, dann 
könnten doch die Clients einfach den raspi als vdr@home:3000 öffnen, oder?


> Heißt, selbst mit Punkt zu Punkt VPN bräuchtest du immer noch Port 
> Forwarding auf dem Raspi. Das wiederum kann SSH meines Wissen auch 
> /ohne/ VPN (Remote Port Forwarding). Der SSH-Tunnel ist ebenfalls 
> verschlüsselt und vergleichbar sicher.

port forwarding mit ssh hat aber ein Problem mit Verbindungsabbrüchen. 
Ein openvpn Tunnel, oder ein Wireguard sind da deutlich flexibler.

Aber du hast mich auf eine Idee gebracht. Natürlich braucht auf dem 
Raspi kein VDR zu laufen. Ich muss nur das routing und Portforwarding 
entsprechend einstellen, dass zugriffe aus dem FW Netz an den Raspi 
durch den Tunnel nach Hause gleitet werden und zurück.


Jan

[toc] | [prev] | [next] | [standalone]

#112161

Am 29.09.20 um 14:03 schrieb Jan Novak:
> Am 29.09.20 um 12:00 schrieb Marcel Mueller:
>>> letztendlich nur den Streamdev Server, also nur ein Port.
>>
>> Das heißt, alle Clients haben eigenständige VDR-Instanzen mit 
>> streamdev-client Plugin.
> 
> Ne, das sind alles Handys, Notebooks / ect. i.dR. mit VLC als player.

Dann kannst du mit streamdev-server Protokoll (Port 2004) wenig 
anfangen. Das ist nur für die Kommunikation zwischen zwei VDR Instanzen 
gedacht.

Alternativ kann man natürlich nur den Streaming-Port weiterleiten 
(Standard 3000). Dann muss man aber Playlisten mit den auf dem Server 
verfügbaren Kanälen an die Clients verteilen.


>> Realistisch betrachtet wirst du in dem Fall noch SVDRP freigeben 
>> wollen, damit die Clients sich die EPG-Daten synchronisieren können, 
>> ohne dass jeder Client dauernd eigenständig die Kanäle scannen muss, 
>> was Tuner blockiert.
> 
> Tut das ein VLC Client denn?

Nein. Der kann nicht suchen, folglich braucht er auch keine EPG-Daten.


>> Wenn man VPN macht und es nicht gerade ein Subnetz-VPN ist, dann kann 
>> ausschließlich das Gerät mit dem VPN-Tunnel auf die Remote-Dienste 
>> zugreifen.
> 
> hmmm... also wenn der Raspi quasi nur der "Tunnelzugang" wäre, dann 
> könnten doch die Clients einfach den raspi als vdr@home:3000 öffnen, oder?

Nein. Dazu müsste auf dem Raspi ein Forwarding des Port 3000 auf den 
Remote-Port des VDR-Servers eingerichtet werden.


>> Heißt, selbst mit Punkt zu Punkt VPN bräuchtest du immer noch Port 
>> Forwarding auf dem Raspi. Das wiederum kann SSH meines Wissen auch 
>> /ohne/ VPN (Remote Port Forwarding). Der SSH-Tunnel ist ebenfalls 
>> verschlüsselt und vergleichbar sicher.
> 
> port forwarding mit ssh hat aber ein Problem mit Verbindungsabbrüchen. 
> Ein openvpn Tunnel, oder ein Wireguard sind da deutlich flexibler.

Das stimmt.
Ein Verbindungsabbruch wird aber in jedem Fall bis zum Client 
durchschlagen. Insofern ist ein vom Server aus im Fall eines Abbruchs 
per Skript wieder aufgebauter SSH-Tunnel auch nicht schlechter.
Wenn die FeWo die IP wechselt, dauert es so oder so eine Weile, bis die 
Verbindung unter der neuen Adresse wieder steht.


> Aber du hast mich auf eine Idee gebracht. Natürlich braucht auf dem 
> Raspi kein VDR zu laufen. Ich muss nur das routing und Portforwarding 
> entsprechend einstellen, dass zugriffe aus dem FW Netz an den Raspi 
> durch den Tunnel nach Hause gleitet werden und zurück.

Exakt.

Einen Punkt würde ich allerdings auch noch in die Waagschale werfen:
Damit das alles funktioniert, muss der VDR-Server 24/7 laufen. In dem 
Zusammenhang ist ein Blick auf das Thema Stromverbrauch empfehlenswert.
So eine SAT-Anlage zieht je nach Größe gut und gerne für 30€ Strom im 
Jahr, wenn immer ein Abnehmer (der VDR-Server) verbunden ist, und zwar 
/zusätzlich/ zum VDR-Server selbst. Nur wenn der letzte Teilnehmer die 
LNB-Spannung abknipst, gehen die Dinger aus oder in einen sehr sparsamen 
Stand-By.
Aus Sicht von VDR und Video4Linux sieht das so aus: Die mir bekannten 
DVB-Karten schalten die LNB-Stromversorgung genau dann ab, wenn das 
dvb-Device geschlossen wird. Das ist gleichbedeutend mit: der VDR Dienst 
läuft nicht. Ohne VDR-Dienst greifen aber die Clients ins Leere.

Man kann das Problem lösen, indem man den VDR Dienst nur bei Bedarf 
startet. Das dauert nur ca. eine Sekunde und kann durchaus während des 
TCP Verbindungsaufbaus erfolgen. Dazu richtet man auf dem Server mit 
systemd (oder inetd) einen Service auf einem anderen Port ein, der bei 
einer Verbindungsanfrage die Daten per netcat (nc) an den VDR-Dienst 
weiter leitet, und wenn das nicht klappt, weil der Listener nicht 
existiert, wird einfach VDR vorher gestartet und es nach eine halben 
Sekunde oder so nochmal versucht.
VDR wiederum wird so konfiguriert, dass er bei Inaktivität nach 10 
Minuten oder so aus geht. Und im Shutdownhook stoppt man den VDR Dienst 
und verhindert den sonst üblichen Shutdown des ganzen Rechners.
Zusätzlich muss man noch einen at-Timer für den automatischen Start 
setzen, falls in der Zukunft eine Aufnahme programmiert ist. Dadurch 
dass VDR nebst LNB jetzt nur noch bei Bedarf läuft, kann man einen 
erheblichen Teil der 30€ Strom im Jahr sparen.
Einziger Nachteil: der EPG-Scan läuft dadurch nicht mehr sicher 
regelmäßig. Das kann Suchtimer beeinträchtigen. Bei einem Doppeltuner 
sollte man das aber nicht überbewerten. Immer wenn gerade nur ein Tuner 
gebraucht wird, nutzt VDR den zweiten für den Scan. Das dürfte gar nicht 
so selten sein. Falls das nicht reicht, kann man auch ein Skript über 
svdrpsend alle Nacht mal die Transponder durchschalten lassen. Formell 
gesehen hat ja auch ein Headless-VDR ein Ausgabe-Device, dessen Programm 
man umschalten kann.


Marcel

[toc] | [prev] | [next] | [standalone]

#112171

Am 29.09.20 um 17:01 schrieb Marcel Mueller:
> Alternativ kann man natürlich nur den Streaming-Port weiterleiten 
> (Standard 3000). Dann muss man aber Playlisten mit den auf dem Server 
> verfügbaren Kanälen an die Clients verteilen.

So war auch meine Idee.

>> port forwarding mit ssh hat aber ein Problem mit Verbindungsabbrüchen. 
>> Ein openvpn Tunnel, oder ein Wireguard sind da deutlich flexibler.
> 
> Das stimmt.
> Ein Verbindungsabbruch wird aber in jedem Fall bis zum Client 
> durchschlagen. Insofern ist ein vom Server aus im Fall eines Abbruchs 
> per Skript wieder aufgebauter SSH-Tunnel auch nicht schlechter.
> Wenn die FeWo die IP wechselt, dauert es so oder so eine Weile, bis die 
> Verbindung unter der neuen Adresse wieder steht.

Auch wieder wahr. Da im Home Office aber sowieso sowohl openvpn als 
auchh wireguard zur verfügung stehen, werde ich das verwenden. Kann dann 
die Firewall alles regeln.


>> Aber du hast mich auf eine Idee gebracht. Natürlich braucht auf dem 
>> Raspi kein VDR zu laufen. Ich muss nur das routing und Portforwarding 
>> entsprechend einstellen, dass zugriffe aus dem FW Netz an den Raspi 
>> durch den Tunnel nach Hause gleitet werden und zurück.
> 
> Exakt.

Dann werde ich das mal versuchen.


> Einen Punkt würde ich allerdings auch noch in die Waagschale werfen:
> Damit das alles funktioniert, muss der VDR-Server 24/7 laufen. 

Das tut er hier zu Hause sowieso. Läuft in einer VM.
meine Frau, die Kinder und ich auch nutzen täglich.
Ich habe mal einen Timer gehbt, der den VDR Server Nachts um 01:00 bis 
07:00 herunterfährt, bis meine Tochter meinte, sie bräuchte das auch 
manchmal später oder früher... Somit läuft er jetzt 24/7

> Man kann das Problem lösen, indem man den VDR Dienst nur bei Bedarf 
> startet. Das dauert nur ca. eine Sekunde und kann durchaus während des 
> TCP Verbindungsaufbaus erfolgen. Dazu richtet man auf dem Server mit 
> systemd (oder inetd) einen Service auf einem anderen Port ein, der bei 
> einer Verbindungsanfrage die Daten per netcat (nc) an den VDR-Dienst 
> weiter leitet, und wenn das nicht klappt, weil der Listener nicht 
> existiert, wird einfach VDR vorher gestartet und es nach eine halben 
> Sekunde oder so nochmal versucht.

hmmm.. sehr interessanter Vorschlag.
Ich habe nur die Befürchtung, dass ein solches Konstrukt 
fehleranfälliger wäre. Und  - obwohl (eigentlich) nicht möglich - gibt 
es immer wieder mal irgendwo nen fehler und ich muss per Hand 
eingreifen. Meiner Erfahrung nach ist das KISS Prinzip am besten.



Jan

[toc] | [prev] | [next] | [standalone]

#112173

Am 30.09.20 um 08:44 schrieb Jan Novak:
>> Man kann das Problem lösen, indem man den VDR Dienst nur bei Bedarf 
>> startet. Das dauert nur ca. eine Sekunde und kann durchaus während des 
>> TCP Verbindungsaufbaus erfolgen. Dazu richtet man auf dem Server mit 
>> systemd (oder inetd) einen Service auf einem anderen Port ein, der bei 
>> einer Verbindungsanfrage die Daten per netcat (nc) an den VDR-Dienst 
>> weiter leitet, und wenn das nicht klappt, weil der Listener nicht 
>> existiert, wird einfach VDR vorher gestartet und es nach eine halben 
>> Sekunde oder so nochmal versucht.
> 
> hmmm.. sehr interessanter Vorschlag.
> Ich habe nur die Befürchtung, dass ein solches Konstrukt 
> fehleranfälliger wäre.

Läuft hier seit 10 Jahren. Früher waren es reine Shell-Skripte, 
mittlerweile größtenteils Systemd-Units.

Tatsächlich hat /das/ bisher noch keine Probleme verursacht. Allerdings 
benutze ich kein Auto-Wakeup auf Port 3000, da selbige Links hier über 
VDR-Live verteilt werden. Heißt bei mir startet der Zugriff auf VDR-Live 
und Streamdev den Server. (Der Raspi hat bei mir einen kompletten VDR 
und hängt am TV.)

Bei einem Bekannten läuft es ähnlich, nur hat er Kodi-Clients die den 
Server über den VNSI-Port wecken.

Einziger theoretischer Nachteil ist, dass natürlich der komplette 
Traffic immer über netcat läuft. Das hat aber bisher keine erkennbaren 
Auswirkungen gehabt. Möglicherweise kann Linux mittlerweile Zerocopy bei 
lokalen TCP-Sockets oder die Last ist einfach marginal.

VM wollte ich damals auch machen, das scheitert aber daran dass der alte 
(und sparsame) 760G Chipsatz des Servers keine IOMMU für PCI-Passthrough 
hat. Aber auch das hat bisher keine Probleme verursacht - im Gegensatz 
zur Virtualisierung. Da hatte ich in der Zeit 2-mal Kernel-Panic im 
VM-Treiber. Das und eine kurze Stromunterbrechung bei Gewitter waren 
bisher die einzigen ungeplanten Reboots.

> Und  - obwohl (eigentlich) nicht möglich - gibt 
> es immer wieder mal irgendwo nen fehler und ich muss per Hand 
> eingreifen. Meiner Erfahrung nach ist das KISS Prinzip am besten.

Wenn das meine Stromrechnung poliert, sehe ich das anders. Alleine Der 
Stromverbrauch meines Servers steigt um fast 10W, sobald VDR läuft.
Das ist schon Aua und auch ökologisch fragwürdig.

Über Zeitsteuerung habe ich es aber gar nicht erst versucht. Das haut 
sowieso nie hin.

Falls Interesse besteht, suche ich die Skripte mal heraus. Ob ich die 
alten /ohne/ Systemd noch habe, weiß ich jetzt nicht - auf irgendeinem 
Backup wahrscheinlich schon.

Mit den VMs mache ich es übrigens genauso. Die starten auch beim ersten 
Zugriff automatisch. Da geht es aber eher um Wartungsfreiheit. 
Normalerweise laufen die 24/7. Aber es sind eben virtuelle Desktops für 
Nicht-Administratoren.


Marcel

[toc] | [prev] | [next] | [standalone]

#112174

Am 30.09.20 um 09:22 schrieb Marcel Mueller:

> VM wollte ich damals auch machen, das scheitert aber daran dass der alte 
> (und sparsame) 760G Chipsatz des Servers keine IOMMU für PCI-Passthrough 
> hat. Aber auch das hat bisher keine Probleme verursacht - im Gegensatz 
> zur Virtualisierung. Da hatte ich in der Zeit 2-mal Kernel-Panic im 
> VM-Treiber. Das und eine kurze Stromunterbrechung bei Gewitter waren 
> bisher die einzigen ungeplanten Reboots.

Zugegebenermaßen hatte ich damit anfangs auch viele Probleme. Mit dem 
aktuellen Board im Server klappt das jetzt seit rund 2 Jahren 
fehlerfrei. Und das wechsle ich _nie_ mehr ;-)


>> Und  - obwohl (eigentlich) nicht möglich - gibt es immer wieder mal 
>> irgendwo nen fehler und ich muss per Hand eingreifen. Meiner Erfahrung 
>> nach ist das KISS Prinzip am besten.
> 
> Wenn das meine Stromrechnung poliert, sehe ich das anders. Alleine Der 
> Stromverbrauch meines Servers steigt um fast 10W, sobald VDR läuft.
> Das ist schon Aua und auch ökologisch fragwürdig.

Stimmt... wobei ich das noch nicht gemessen habe, was der CDR 
verursacht. Der Home Server läuft sowieso 24/7 weil er auch Backup und 
Fallback für einen Produktiv Server ist.


> Falls Interesse besteht, suche ich die Skripte mal heraus. Ob ich die 
> alten /ohne/ Systemd noch habe, weiß ich jetzt nicht - auf irgendeinem 
> Backup wahrscheinlich schon.

Systemd wäre ok. Würde mich sehr freuen.


> Mit den VMs mache ich es übrigens genauso. Die starten auch beim ersten 
> Zugriff automatisch. Da geht es aber eher um Wartungsfreiheit. 
> Normalerweise laufen die 24/7. Aber es sind eben virtuelle Desktops für 
> Nicht-Administratoren.

Ok, bei mir sind es in der Regel (bis auf Mailarchiv und den VDR) nur 
Container mit WEB und Haussteuerung usw., welche Live laufen. Die 
fressen wenig "Brot" ;-)


Jan

Jan

[toc] | [prev] | [next] | [standalone]

#112175

Am 30.09.20 um 09:37 schrieb Jan Novak:
[Server]
> Zugegebenermaßen hatte ich damit anfangs auch viele Probleme. Mit dem 
> aktuellen Board im Server klappt das jetzt seit rund 2 Jahren 
> fehlerfrei. Und das wechsle ich _nie_ mehr ;-)

Naja, nach 10 Jahren, kommen da vielleicht andere Kriterien mit ins 
Spiel. ;-)


>> Wenn das meine Stromrechnung poliert, sehe ich das anders. Alleine Der 
>> Stromverbrauch meines Servers steigt um fast 10W, sobald VDR läuft.
>> Das ist schon Aua und auch ökologisch fragwürdig.
> 
> Stimmt... wobei ich das noch nicht gemessen habe, was der CDR 
> verursacht. Der Home Server läuft sowieso 24/7 weil er auch Backup und 
> Fallback für einen Produktiv Server ist.

Der läuft hier auch 24/7 und ist Mädchen für alles. Dadurch ist es 
(außer dem WLAN-Router) aber eben auch das einzige (relevante) 24/7 
Device. Das senkt den Verbrauch auch wieder.


>> Falls Interesse besteht, suche ich die Skripte mal heraus. Ob ich die 
>> alten /ohne/ Systemd noch habe, weiß ich jetzt nicht - auf irgendeinem 
>> Backup wahrscheinlich schon.
> 
> Systemd wäre ok. Würde mich sehr freuen.

----- shutdown-hooks/S90.custom
#!/bin/bash
#
# Custom VDR Shutdown Hook
# -------------------------
#
# Here you can place any commands, you want to be executed when VDR wants
# to shutdown.
#
# * To abort the shutdown, exit with an errorlevel <> 0.
#
# * If you want a message to be displayed on the OSD when aborting a 
shutdown,
#   then write to stdout:
#
#   ABORT_MESSAGE=<message to display>
#
# * If you want to defer the shutdown, write to stdout:
#
#   TRY_AGAIN=<minutes to wait before next shutdown request>
#
# * To overwrite the command that will be executed to shutdown the machine
#   after all shutdown hooks have been processed, write to stdout:
#
#   SHUTDOWNCMD=<new shutdown command>
#
# i.e.:
#
# echo "ABORT_MESSAGE=\"I do not want to shutdown now!\"" ; exit 1
#

# vdr shutdown service

# unter allen Umständen exit 1, sonst schaltet VDR den Rechner ab, egal 
was noch alles läuft.

logfile=/var/log/vdr/shutdown
echo SHUTDOWNCMD='true'

date 2>/dev/null >>$logfile
echo $1, $2, $3, $4 >>$logfile

# Bail out if the next recording starts within the next 10 minutes.
if [ $1 -eq 0 ]; then true;
elif [ $2 -gt 600 ]; then true;
else
   echo Cancel shutdown because of outstanding recording within $2 
seconds. >>$logfile
   exit 1;
fi

# cancel pending timers
atrm `atq -q v | grep " v vdr$" | sed -r 's/^([0-9]+).*/\\1/g'` 2>&1 
 >>$logfile

if [ $1 -eq 0 ]; then
   echo No timer, terminating without wakeup >>$logfile

else
   wakeup=$(($1-900))
   echo Set wakeup to $wakeup >>$logfile

   mins=$(($wakeup/60))
   #echo $(($mins*60)) >>$logfile

   # set wake up timer
   # work around: UTC token of at does not work
   export TZ=UTC
   echo Setup at... >>$logfile
   echo at -v -q v -f 0000 01/01/1970 + $mins MINUTE 2>&1 >>$logfile
   echo /usr/bin/sudo /bin/systemctl start vdr | at -v -q v 0000 
01/01/1970 + $mins MINUTE 2>&1 >>$logfile
fi

# shut down vdr
echo Stopping vdr... >>$logfile
sudo /bin/systemctl stop vdr 2>&1 >>$logfile
exit 1
-----

----- /etc/systemd/system/vdr-live.socket
[Unit]
Description=VDR Live proxy

[Socket]
ListenStream=0.0.0.0:7908
Accept=yes
KeepAlive=yes
KeepAliveTimeSec=60
KeepAliveIntervalSec=30

[Install]
WantedBy=sockets.target
-----

----- /etc/systemd/system/vdr-live@.service
[Unit] Description=VDR Live proxy
#Requires=vdr.service

[Service]
Type=simple
ExecStart=/usr/local/sbin/daemonproxy.sh 127.0.0.1 8008 /bin/systemctl 
start vdr
#ExecStart=/usr/local/sbin/daemonproxy.sh 127.0.0.1 8008 true
StandardInput=socket
StandardError=journal
Restart=no

#[Install]
-----

----- /etc/systemd/system/vdr-streamdev.socket
[Unit]
Description=VDR streamdev proxy

[Socket]
ListenStream=0.0.0.0:1904
Accept=yes
KeepAlive=yes
KeepAliveTimeSec=60
KeepAliveIntervalSec=30

[Install]
WantedBy=sockets.target
-----

----- /etc/systemd/system/vdr-streamdev@.service
[Unit]
Description=VDR streamdev proxy

[Service]
Type=simple
ExecStart=/usr/local/sbin/daemonproxy.sh 127.0.0.1 2004 /bin/systemctl 
start vdr
StandardInput=socket
StandardError=journal
Restart=no

#[Install]
-----

----- /usr/local/sbin/daemonproxy.sh
#!/bin/bash
target="$1 $2"
shift 2
startupcmd=$*
logf=/tmp/daemonproxy.log

echo $$ verbinde $target </dev/null >>$logf
if ! nc $target 2>>$logf; then
   sleep 1 </dev/null >/dev/null;
   if ! nc $target 2>>$logf; then
     echo $$ starte $startupcmd </dev/null >>$logf
     $startupcmd </dev/null >>$logf 2>&1
     retries=0
     echo $$ verbinde erstmals $target </dev/null >>$logf
     until nc $target 2>>$logf; do
       if [ $retries -ge 4 ]; then
         echo $$ Verbindung fehlgeschlagen </dev/null >>$logf
         exit 1
         break;
       fi
       retries=$(( $retries+1 ))
       sleep 1 </dev/null >/dev/null;
       echo $$ erneuter Versuch \#$retries </dev/null >>$logf
     done;
   fi
fi
echo $$ Verbindung beendet $target </dev/null >>$logf
-----

----- /etc/sudoers.d/vdr
vdr ALL=(ALL) NOPASSWD: /bin/systemctl start vdr, /bin/systemctl stop 
vdr, /bin/systemctl is_alive vdr
-----

Das sollte es gewesen sein. (Mit Zeilenumbrüchen bei Leerzeichen am Ende 
aufpassen! Attachments gehen hier nicht.)

Optional kann man wie gesagt per cronjob noch den EPG-Scan manuell 
forcieren, z.B. nachts um 5:

----- vdrscan.pl
#!/usr/bin/perl -w
use strict;

system 'sudo systemctl is-active vdr' or print("Scan refused, vdr 
already running.\n"), exit;
system 'sudo systemctl start vdr' and die "Failed to start vdr";
sleep 5;

my $chanfile = '/var/lib/vdr/channels.conf';
my $svdrpsend = '/usr/local/bin/svdrpsend';
my $delay = 15;
my $FTAonly = 1;

# $transponder{"$Source-$TID"}
my %transponder;
# ["$Source-$NID-$TID-$SID",$Name]
my @channels;

open F, "<$chanfile" or die "Failed to open $chanfile\n";
while ($_ = <F>)
{ chomp;
   my 
($Name,$Freq,$Param,$Source,$Symrate,$VPID,$APID,$TPID,$CAID,$SID,$NID,$TID,$RID) 
= split /:/;
   defined $TID or next; # skip section headers
   $FTAonly && $CAID and next; # skip scrambled?
   exists $transponder{"$Source-$TID"} and next; # each transponder only 
once
   $transponder{"$Source-$TID"} = undef;
   push @channels, ["$Source-$NID-$TID-$SID", $Name];
}
close F;

foreach (@channels)
{ print "Channel $$_[1]\t$$_[0]\n";
   system "$svdrpsend CHAN $$_[0]" and die "$svdrpsend failed $!\n";
   sleep $delay;
}
-----


[VMs]
> Ok, bei mir sind es in der Regel (bis auf Mailarchiv und den VDR) nur 
> Container mit WEB und Haussteuerung usw., welche Live laufen. Die 
> fressen wenig "Brot" ;-)

Eine laufende Desktop-VM kostet hier ca. 1W zusäztzlich. Und da macht 
keiner irgendwelche Programme wie Firefox zu. Das ist moderat.


Marcel

[toc] | [prev] | [next] | [standalone]

#112162

On 29.09.20 14:03, Jan Novak wrote:
> Ne, das sind alles Handys, Notebooks / ect. i.dR. mit VLC als player.

Geht es um Live-TV oder auch um Aufzeichnungen?

Irgendwie werde ich das Gefühl nicht los das man das Problem heute eher 
"moderner" lösen sollte.

Die öffentlich rechtlichen Sender streamen z.B. selber ins Internet. Man 
muss den Stream nur mit passenden Clients aufrufen.

Gruß

Manuel

[toc] | [prev] | [next] | [standalone]

#112170

Am 29.09.20 um 18:08 schrieb Manuel Reimer:
> On 29.09.20 14:03, Jan Novak wrote:
>> Ne, das sind alles Handys, Notebooks / ect. i.dR. mit VLC als player.
> 
> Geht es um Live-TV oder auch um Aufzeichnungen?
> 
> Irgendwie werde ich das Gefühl nicht los das man das Problem heute eher 
> "moderner" lösen sollte.

Ich dachte, dass wäre eine moderne Lösung ;-)

> 
> Die öffentlich rechtlichen Sender streamen z.B. selber ins Internet. Man 
> muss den Stream nur mit passenden Clients aufrufen.

Nicht im Ausland.

Jan

[toc] | [prev] | [next] | [standalone]

#112198

On 30.09.20 08:37, Jan Novak wrote:
> Ich dachte, dass wäre eine moderne Lösung ;-)

Live-TV ist schon seit einiger Zeit nicht mehr "modern" :P

>> Die öffentlich rechtlichen Sender streamen z.B. selber ins Internet. 
>> Man muss den Stream nur mit passenden Clients aufrufen.
> 
> Nicht im Ausland.

https://www.pc-magazin.de/ratgeber/x-3196308.html

Gruß

Manuel

[toc] | [prev] | [next] | [standalone]

#112205

Am 01.10.2020 um 14:28 schrieb Manuel Reimer:
> On 30.09.20 08:37, Jan Novak wrote:
>> Ich dachte, dass wäre eine moderne Lösung ;-)
> 
> Live-TV ist schon seit einiger Zeit nicht mehr "modern" :P
> 
>>> Die öffentlich rechtlichen Sender streamen z.B. selber ins Internet. 
>>> Man muss den Stream nur mit passenden Clients aufrufen.
>>
>> Nicht im Ausland.
> 
> https://www.pc-magazin.de/ratgeber/x-3196308.html
> 
> Gruß
> 
> Manuel


Versteh ich das richtig - OP fragt wie er ein VPN aufbaut um DE-TV im 
Auslang zu kucken, und PC-Magazin sagt das gleiche, nur kommerziell und 
teuer? Wo ist der Mehrwert?

Andi

[toc] | [prev] | [standalone]

Back to top | Article view | de.comp.os.unix.linux.misc

csiph-web