n0b0dy Posted July 10, 2024 Posted July 10, 2024 (edited) Hallo zusammen, auf unserem Boot verwende ich TVH auf einem Pi 5 als SAT-IP-Server, um meinen DVB-T-Stick (Sundtek) für Clients mit DVBViewer bereitzustellen. Eine direkte Verwendung von TVH über Kodi oder VLC funktioniert nicht zufriedenstellend, weil ich jedes mal die Sender neu scannen und mappen müsste, sobald ich den Ort wechsel. Das ginge zwar, ist aber sehr zeitaufwendig. Mit dem DVBViewer klappt es deutlich besser. Der Pi ist via LAN mit einem Reiserouter (GL.iNet) verbunden, und die Clients stellen die Verbindung über W-LAN her. Alles funktioniert auch wie gewünscht, solange der Router über eine bestehende Internetverbindung (Tethering, Surf Stick, Hotspot etc.) verfügt, aber sobald die Internetverbindung getrennt wird, finden die Clients den SAT-IP-Server nicht mehr. Habt ihr eine Idee, wie man das Problem lösen könnte? Eine dauerhafte Internetverbindung kann bei der deutschen Netzabdeckung nicht gewährleistet werden und ist auch nicht gewünscht/notwendig. Edited July 10, 2024 by n0b0dy Quote
Trill Ian Posted July 10, 2024 Posted July 10, 2024 vor 48 Minuten schrieb n0b0dy: aber sobald die Internetverbindung getrennt wird, finden die Clients den SAT-IP-Server nicht mehr. Habt ihr eine Idee, wie man das Problem lösen könnte? Ist logisch, könnte man drauf kommen. Ohne Internet fehlen Dir einige Dienste wie DNS oder NTP (Zeitserver). Die müsstest Du auf dem PI5 mit einrichten, inkl eines DHCP Servers, der den Klienten die lokalen Server des PIs anbietet. Eine Möglichkeit wäre z.B. "PiHole", das ist zwar vordergründig ein Adblocker, aber dahinter steckt ein DNS und DHCP Server. Mit entsprechender Konfiguration sollte die Geräte im LAN glücklich werden. (Und natürlich beim wirklichen Router alle diese Dienste deaktivieren, so dass sie sich nicht in die Quere kommen). Die Konfiguration ist nicht ganz trivial, aber man kann sich da schon einarbeiten (gehört aber alles gar nicht hierhin) Quote
n0b0dy Posted July 10, 2024 Author Posted July 10, 2024 Der lokale DNS vom Router funktioniert doch auch ohne Internet oder nicht? Pi-hole läuft bereits auf dem Pi und wird den Clients als DNS-Server mitgeteilt. Das lässt sich in den DHCP-Einstellungen des Routers (mit OpenWrt als FW) hinterlegen. Oder was könnte der DHCP vom Pi-hole, was der DHCP vom Router nicht kann? Wo müsste man den NTP-Server hinterlegen? Braucht RTSP noch etwas, damit es ohne Internet funktioniert? Quote
Trill Ian Posted July 10, 2024 Posted July 10, 2024 vor 18 Minuten schrieb n0b0dy: Der lokale DNS vom Router funktioniert doch auch ohne Internet oder nicht? Nö. Der übliche Router hat nur einen DNS Proxy, er liefert keine eigenen Daten. Genauso arbeitet PiHole. Der leitet auch erstmal nur irgendwohin weiter und sagt ansonsten: "KENNICH NICH!". vor 20 Minuten schrieb n0b0dy: was könnte der DHCP vom Pi-hole, was der DHCP vom Router nicht kann? Man kann da von Hand eigene Einträge (Zonen und Hosts) hinterlegen, die auch verfügbar sind, wenn keine Weiterleitung möglich ist. Aber frag mich nur nicht, was da rein muß für Dein Streaming Zeuchs. vor 22 Minuten schrieb n0b0dy: Braucht RTSP noch etwas, damit es ohne Internet funktioniert? RTSP ist nicht so das Problem. Das liegt eine Ebene höher, bei "SAT->IP". Dieses "Protokoll" ist eine geistige Totgeburt und im Prinzip eine Raubkopie von "Plug&Play". Das wurde aber nicht umsonst eingestampft, denn es funktioniert, wenn überhaupt, nur in sehr bescheidenen Umgebungen. Es kann z.B. kein Routing, bei Adresswechsel bricht alles zusammen, bzw. bekommt keine Verbindung mehr. Da Du ja in Deiner ursprüngliche Frage so 90% der wichtigen Informationen nicht angegeben hast, ist es nun müssig, sich eine Antwort auszudenken. Schwer, wenn man das zugrundeliegende Setup nicht kennt... Quote
n0b0dy Posted July 10, 2024 Author Posted July 10, 2024 Welche Informationen fehlen denn konkret? Quote
Griga Posted July 10, 2024 Posted July 10, 2024 vor 3 Stunden schrieb n0b0dy: aber sobald die Internetverbindung getrennt wird, finden die Clients den SAT-IP-Server nicht mehr. Das müsstest du genauer beschreiben. Wie äußert sich das? Es gibt einen auf UPnP basierenden Erkennungsmechanismus, mit dem der Client im Netz vorhandene Server findet. Der Client kann eine Multicast-Request in die Runde schicken, auf die alle Server antworten. Das passiert, wenn du im DVBViewer auf Optionen -> Hardware -> Sat>IP Server suchen klickst. Oder wenn du den Server einschaltest, versendet er eine Multicast-Botschaft, die seine Anwesenheit allen potentiellen Clients kundtut. Wenn ein Client jedoch bereits die IP und den Port eines Servers hat, braucht er kein UPnP mehr, um ihn zu finden, sofern dieser nicht seine IP-Adresse gewechselt hat. Dann versucht der Client direkt, als Teil des RTSP-Protokolls eine TCP-Verbindung zum Server aufzubauen (TCP ist auch die Basis für HTTP, d.h. ohne TCP funktioniert keine HTTP-Verbindung z.B. zu einem Webinterface). Und was davon klappt bei dir auf welche Weise nicht? Versuche mal eine präzise und vollständige Problembeschreibung. Quote
n0b0dy Posted July 10, 2024 Author Posted July 10, 2024 2 minutes ago, Griga said: Das passiert, wenn du im DVBViewer auf Optionen -> Hardware -> Sat>IP Server suchen klickst. ... Und was davon klappt bei dir auf welche Weise nicht? Versuche mal eine präzise und vollständige Problembeschreibung. Das äußert sich, indem das Streaming funktioniert, solange eine Internetverbindung besteht. So lange sie besteht, kann ich unter Hardware jederzeit auf "Sat>IP Server suchen" klicken und der TVH-Server bleibt gelistet. Sobald ich die Internetverbidung trenne und eine erneute Suche starte, wird der Server-Eintrag automatisch gelöscht. Quote
Griga Posted July 10, 2024 Posted July 10, 2024 vor 5 Minuten schrieb n0b0dy: Sobald ich die Internetverbidung trenne und eine erneute Suche starte, wird der Server-Eintrag automatisch gelöscht. Wieso startest du eine erneute Erkennung? Wie gesagt ist das unnötig, wenn der Client den Server bereits kennt bzw. der DVBViewer seine IP-Adresse und den Port gespeichert hat. Quote
n0b0dy Posted July 10, 2024 Author Posted July 10, 2024 (edited) Weil das Streaming trotz eingetragenem Server ohne Internet nicht mehr funktioniert. Zumindest nach einem Neustart des Pis nicht. Edited July 10, 2024 by n0b0dy Quote
Griga Posted July 10, 2024 Posted July 10, 2024 Gerade eben schrieb n0b0dy: Weil das Streaming trotz eingetragenem Server ohne Internet nicht mehr funktioniert. Was meinst du genau mit "Streaming funktioniert nicht mehr"? TV bleibt stehen, sobald die Internetverbindung wegfällt? Oder der Bildschirm wird schwarz? Quote
n0b0dy Posted July 10, 2024 Author Posted July 10, 2024 (edited) Wenn ich einen Sender auswähle, wird "kein Tuner verfügbar" oder so ähnlich angezeigt. Das Bild bleibt also schwarz. Ich habe wie gesagt direkt getestet, ob es nach einem Neustart noch funktioniert. Das ist jedoch nur mit Internet der Fall. Mit Internetverbidung wird sofort der letzte Sender abgespielt und ohne Verbindung bleibt das Bild schwarz und bei einem Senderwechsel kommt "kein Tuner vefügbar". Es muss nach einem Neustart funktionieren, weil Router und Pi vom Strom getrennt werden, wenn das Boot nicht benutzt wird. Ansonsten Versorgung über 12 Volt. Edited July 10, 2024 by n0b0dy Quote
Trill Ian Posted July 10, 2024 Posted July 10, 2024 Also der grundsätzliche Fehler liegt schon mal in der Verteilung der Dienste... * Der Router darf KEIN DHCP anbieten! * bei PiHole aktiviert man stattdesse den DHCP Server * der Pi muss eine STATISCHE IP Adresse haben!!! (Wo ist der Unterschied? ganz einfach, wenn PiHole eine Adresse zuweist, wird diese automatisch mit in den lokalen DNS Server eingetragen, ist somit direkt verfügbar, ob Router da ist, oder nicht.) * auf dem Pi noch ntpd installieren und die "lokale Hardware clock" als erlaubt markieren (wenn Internet da ist, dann Zeit vom Netz, ansonsten Zeit von der lokalen Uhr) * DHCP Daten: Pool: egal, irgendwas ausdenken DNS: statische IP Adresse des PIs (nur EINEN DNS Server!, alle anderen leer lassen!) NTP: statische IP Adresse des PIs DNSDomäne: sich irgendeine ausdenken und auch in PiHole eintragen (z.B. dummydns.local) DNSSearch: die ausgedachte Domäne (dummydns.local) Default Gateway: Adresse des PIs Das ist erst der Startpunkt. Setz das so auf und starte den PI (und danach alle anderen) neu. Lass den Router AUS/Weg/Kabel ab. Die Rechner sollten hochkommen und untereinander kommunizieren können, und mit etwas Glück geht dann auch der DVBViewer. Danach beim Pi (NUR da!!!) das Default Gateway auf den Router einstellen und den dann starten. Vom PI aus sollte man alles PINGen können im Internet. Im Idealfalle geht es dann auch von den Klienten aus. Wenn nicht, mal die Kernel Einstellungen bzgl. Packet Forwarding beim PI prüfen, oder vielleicht noch ein paar Proxydienste (z.B. SQUID) auf den PI packen. Kleine Warnung: einfach "Strom aus" mag kein PI. Irgendwann ist das Dateisystem hinüber, hab also reichlich backups von der Speicherkarte parat (oder vom USB Stick, oder von der USB Platte, oder von der NVMe SSD) Quote
n0b0dy Posted July 10, 2024 Author Posted July 10, 2024 Es könnte auch hieran liegen, oder? Ansonsten versuche ich den Ansatz von Trill Ian. Übrigens danke bis hierhin schon mal! Der Pi wird in der Regel heruntergefahren, ehe ich den Strom abschalte. Quote
Griga Posted July 10, 2024 Posted July 10, 2024 vor 4 Stunden schrieb n0b0dy: Wenn ich einen Sender auswähle, wird "kein Tuner verfügbar" oder so ähnlich angezeigt. Das Bild bleibt also schwarz. Heißt, der DVBViewer kann keine TCP-Verbindung mit dem Server aufbauen. Der DVBViewer notiert normalerweise die IPv4-Adresse des Servers (siehe Optionen -> Hardware -> Einstellungen für das RTSP Netzwerk-Gerät), keinen Domain-Namen. Es braucht also keine Namensauflösung. Kurz gesagt scheint es diese Adresse nicht mehr zu geben, oder sie lässt sich keinem Gerät zuordnen. Ein Zusammenhang mit DHCP ist naheliegend. Quote
Trill Ian Posted July 11, 2024 Posted July 11, 2024 (edited) vor 13 Stunden schrieb n0b0dy: Es könnte auch hieran liegen, oder? Das ist doch dasselbe. Ohne DNS (bzw wenn auf Google gestellt mit 8.8.8.8) gehen auch keine lokalen Auflösungen. Mit Google gehen sie auch nicht, weil Google Deine Kisten ja nun nicht kennt. Deshalb der PiHole mit einer lokalen Domäne (und manuell und von DHCP gefüllt), der beantwortet die lokalen Namen, alles weitere geht (wenn möglich) an Google & Co. Ausserdem gibts dadurch einen Cache, so dass nicht jede Abfrage immer extern erfolgt (die Klienten haben auch noch einen eigenen Cache, aber trotzdem). Und Griga irrt gewaltig. Der DMS braucht keine Namen, stimmt. Aber trotzdem werden sie vom OS abgefragt. Und wenn die Antwort "kennich nich" oder "Abfrage nicht möglich" ist, dann werden auch die Adressen verworfen. Und solange das Default Gateway auf den Router zeigt (und der nicht an ist), klappt eh nix mit Plug&Play (gravierender Designfehler, nicht korrigierbar. Deshalb wurde es bei IPV6 auch abgeschafft). Also Gateway Richtung PI zeigen lassen und der schickt dann weiter an den Router. So wird nur eine Kiste geärgert und der Rest kann weiter sein Unwesen treiben. (Ohne erreichbaren Router gibts ein Timeout, deshalb funktioniert die Multicast Erkennung für Plug&Play nicht mehr. Die Pakete werden zuerst immer zum Router geschickt, der sie dann ins LAN umleitet. Erst DANACH erfolgt eine direkte Kommunikation DMS<>Klient, aber dazu kommt es dann nie) Edited July 11, 2024 by Trill Ian Quote
n0b0dy Posted July 11, 2024 Author Posted July 11, 2024 (edited) Der Router ist schon dauerhaft an, hat allerdings keine Verbindung zum Internet, solange das USB-Modem nicht steckt bzw. solange kein Netz erreichbar ist. Hier noch ein Auszug aus dem Log von TVH bei einem ähnlichen Testsetup (Pi 4 und DVB-S2-Tuner): Ohne Internetverbindung: 2024-07-11 01:26:22.061 [ INFO]:main: Log started 2024-07-11 01:26:22.063 [ INFO]:config: Using configuration from '/var/lib/tvheadend' 2024-07-11 01:26:22.065 [ INFO]:http: Starting HTTP server 0.0.0.0:9981 2024-07-11 01:26:22.066 [ INFO]:htsp: Starting HTSP server 0.0.0.0:9982 2024-07-11 01:26:22.066 [ ERROR]:satips: use --satip_bindaddr parameter to select the local IP for SAT>IP 2024-07-11 01:26:22.066 [ ERROR]:satips: using Google lookup (might block the task until timeout) 2024-07-11 01:26:22.067 [ ERROR]:satips: Unable to determine the HTTP/RTSP address 2024-07-11 01:26:22.077 [ INFO]:config: loaded Mit Internetverbindung: 2024-07-11 09:23:33.988 [ INFO]:main: Log started 2024-07-11 09:23:33.991 [ INFO]:config: Using configuration from '/var/lib/tvheadend' 2024-07-11 09:23:33.993 [ INFO]:http: Starting HTTP server 0.0.0.0:9981 2024-07-11 09:23:33.994 [ INFO]:htsp: Starting HTSP server 0.0.0.0:9982 2024-07-11 09:23:33.994 [ ERROR]:satips: use --satip_bindaddr parameter to select the local IP for SAT>IP 2024-07-11 09:23:33.994 [ ERROR]:satips: using Google lookup (might block the task until timeout) 2024-07-11 09:23:34.012 [ INFO]:satips: Starting SAT>IP RTSP server 192.168.8.149:9983 2024-07-11 09:23:34.012 [ INFO]:satips: SAT>IP Server initialized 2024-07-11 09:23:34.012 [ INFO]:satips: HTTP 192.168.8.149:9981, RTSP 192.168.8.149:9983 2024-07-11 09:23:34.012 [ INFO]:satips: descramble 1, muxcnf 0 2024-07-11 09:23:34.012 [ INFO]:satips: tuner[fe=1]: DVB-S2 #1 Webinterface und SSH funktionieren dauerhaft mit der obigen IP (192.168.8.149). Edited July 11, 2024 by n0b0dy Quote
Griga Posted July 11, 2024 Posted July 11, 2024 vor 3 Stunden schrieb Trill Ian: Und solange das Default Gateway auf den Router zeigt (und der nicht an ist), klappt eh nix mit Plug&Play Sat>IP braucht nicht zwingend UPnP, und zum TV-Gucken gar nicht. UPnP erspart dir, im Client die IP-Adresse und den Port des Servers (fast immer 554) sowie die Empfangsart per Hand einzutragen. Das ist alles. DVBViewer & DMS greifen im laufenden Betrieb nur auf UPnP zurück, wenn der Server unter der bekannten IP nicht antwortet. Dann schicken sie eine Multicast-Suchanfrage ins Netz und gucken, ob der Server jetzt eine andere Adresse und/oder einen anderen Port hat. Quote
Trill Ian Posted July 11, 2024 Posted July 11, 2024 vor 1 Stunde schrieb n0b0dy: 2024-07-11 01:26:22.066 [ ERROR]:satips: use --satip_bindaddr parameter to select the local IP for SAT>IP 2024-07-11 01:26:22.066 [ ERROR]:satips: using Google lookup (might block the task until timeout) 2024-07-11 01:26:22.067 [ ERROR]:satips: Unable to determine the HTTP/RTSP address Noch deutlicher kann man es doch nicht sagen, oder??? geb da irgendwo als parameter "--satip_bindaddr 192.168.8.149" an und schon sollte er google vergessen und direkt die Adresse nehmen. Der benutzt Google nur um Deine externe und interne IP Adresse zu ermitteln. Quote
n0b0dy Posted July 11, 2024 Author Posted July 11, 2024 (edited) Fast, aber nicht ganz. Mit "--satip_bindaddr 192.168.8.149" hat es nicht funktioniert. Mit "--bindaddr 192.168.8.149" aber schon. Zusätzlich musste ich noch eine Startverzögerung hinzufügen, damit der SAT-IP-Server nach einem Neustart direkt funktioniert. Ansonsten musste man den Service neu starten. /lib/systemd/system/tvheadend.service [Service] EnvironmentFile=/etc/default/tvheadend ExecStartPre=/usr/bin/sleep 20 ExecStart=/usr/bin/tvheadend -f -p /run/tvheadend.pid $OPTIONS --bindaddr 192.168.8.149 PIDFile=/run/tvheadend.pid Type=forking Restart=on-failure RestartSec=54s Jetzt ohne Internetverbindung: 2024-07-11 12:28:21.962 [ INFO]:main: Log started 2024-07-11 12:28:21.964 [ INFO]:config: Using configuration from '/var/lib/tvheadend' 2024-07-11 12:28:21.965 [ INFO]:http: Starting HTTP server 192.168.8.149:9981 2024-07-11 12:28:21.965 [ INFO]:htsp: Starting HTSP server 192.168.8.149:9982 2024-07-11 12:28:21.965 [ INFO]:satips: Starting SAT>IP RTSP server 192.168.8.149:9983 2024-07-11 12:28:21.965 [ INFO]:satips: SAT>IP Server initialized 2024-07-11 12:28:21.965 [ INFO]:satips: HTTP 192.168.8.149:9981, RTSP 192.168.8.149:9983 2024-07-11 12:28:21.965 [ INFO]:satips: descramble 1, muxcnf 0 2024-07-11 12:28:21.965 [ INFO]:satips: tuner[fe=1]: DVB-S2 #1 2024-07-11 12:28:21.977 [ INFO]:config: loaded Ist also erledigt. Danke an alle! Edited July 11, 2024 by n0b0dy Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.