streamdev-client Probleme

cduerr · 18. Dezember 2021

Hallo,

nach langer Zeit wollte ich vor ungefähr 4 Monaten "mal alles neu machen", weil mich so einiges gestört hatte. yaVDR 0.5 war es glaube ich. Hat bis vor zwei Wochen gedauert, weiterzumachen...

Egal, jetzt habe ich mit Ansible den DVB-Rechner als Server (headless) und einen Streaming-Client (mit nvidia-GraKa und streamdev-client) auf Basis von Ubuntu 20.04 aufgesetzt.

Hat auch soweit geklappt, allerdings bekomme ich die Verbindung streamdev-client -> streamdev-server nicht hin. Jedenfalls nicht funktionierend. (Hinweis: stimmt nicht ganz, alle 20 Bootvorgänge etwa kommt der Client mit funktionierender Darstellung hoch (!!!); ein Umschalten scheitert dann aber wieder)

Ich habe natürlich die channels.conf erstellt (Aufnahmen auf dem Server funktionieren) und auf beiden Rechnern identisch hinterlegt. Ich habe auf dem Server die svdrphosts.conf und streamdevhosts.conf mittels der Einträge in host_vars/localhost angepasst. Mittels des Webservers von streamdev-server kann ich Aufnahmen ansehen, falls das ein Indikator sein sollte und VTP benutzt.

Das erhalte ich im Log des Clients, wenn ich auf einen Kanal umschalten:

Code

ec 18 16:53:33 vdr3 vdr: [7543] switching to channel 1 C-1-1019-10301 (Das Erste HD)
Dec 18 16:53:33 vdr3 vdr: audio/alsa: using device 'default'
Dec 18 16:53:33 vdr3 vdr: audio/alsa: set params error: Invalid argument
Dec 18 16:53:33 vdr3 vdr: audio: can't set channels 0 sample-rate 0Hz
Dec 18 16:53:33 vdr3 vdr: [7543] streamdev-client: Connected to server 192.168.1.4:2004 using protocol version 1.0
Dec 18 16:53:33 vdr3 vdr: [7543] streamdev-client: Command 'DELP 5111' rejected by 192.168.1.4:2004: 560 Pid 5111 not transferring
Dec 18 16:53:33 vdr3 vdr: [7543] streamdev-client: Command 'DELP 5112' rejected by 192.168.1.4:2004: 560 Pid 5112 not transferring
Dec 18 16:53:33 vdr3 vdr: [7543] streamdev-client: Command 'DELP 5113' rejected by 192.168.1.4:2004: 560 Pid 5113 not transferring
Dec 18 16:53:33 vdr3 vdr: [7543] streamdev-client: Command 'DELP 5116' rejected by 192.168.1.4:2004: 560 Pid 5116 not transferring
Dec 18 16:53:33 vdr3 vdr: [7543] streamdev-client: Command 'DELP 5117' rejected by 192.168.1.4:2004: 560 Pid 5117 not transferring
Dec 18 16:53:33 vdr3 vdr: [7543] streamdev-client: Command 'DELP 5115' rejected by 192.168.1.4:2004: 560 Pid 5115 not transferring
Dec 18 16:53:33 vdr3 vdr: [7543] streamdev-client: Command 'DELP 5118' rejected by 192.168.1.4:2004: 560 Pid 5118 not transferring
Dec 18 16:53:33 vdr3 vdr: [7543] streamdev-client: Command 'DELP 5119' rejected by 192.168.1.4:2004: 560 Pid 5119 not transferring
Dec 18 16:53:33 vdr3 vdr: [7628] device 2 receiver thread started (pid=7543, tid=7628, prio=high)
Dec 18 16:53:33 vdr3 vdr: [7628] ERROR: streamdev-client: Couldn't establish data connection to 192.168.1.4:2004: Resource temporarily unavailable
Dec 18 16:53:33 vdr3 vdr: [7628] cStreamdevDevice::OpenDvr(): DVR connection FAILED
Dec 18 16:53:33 vdr3 vdr: [7628] device 2 receiver thread ended (pid=7543, tid=7628)

Alles anzeigen

Code

Dec 18 16:53:33 vdrserver vdr: [2629] Streamdev: Accepted new client (VTP) 192.168.1.13:59011
Dec 18 16:53:33 vdrserver vdr: [2629] Streamdev: Setting data connection to 192.168.1.13:46063
Dec 18 16:53:33 vdrserver vdr: [3175] streamdev-writer thread started (pid=2173, tid=3175, prio=high)
Dec 18 16:53:33 vdrserver vdr: [3177] device 1 receiver thread started (pid=2173, tid=3177, prio=high)
Dec 18 16:53:33 vdrserver vdr: [3176] streamdev-livestreaming thread started (pid=2173, tid=3176, prio=high)
Dec 18 16:53:33 vdrserver vdr: [3178] device 1 TS buffer thread started (pid=2173, tid=3178, prio=high)
Dec 18 16:53:33 vdrserver vdr: [3175] ERROR: streamdev-server: couldn't send 302304 bytes: Connection reset by peer
Dec 18 16:53:33 vdrserver vdr: [3175] streamdev-writer thread ended (pid=2173, tid=3175)
Dec 18 16:53:33 vdrserver vdr: [2629] streamdev-server: closing VTP connection to 192.168.1.13:59011
Dec 18 16:53:33 vdrserver vdr: [3178] device 1 TS buffer thread ended (pid=2173, tid=3178)
Dec 18 16:53:33 vdrserver vdr: [3177] buffer stats: 185932 (1%) used
Dec 18 16:53:33 vdrserver vdr: [3177] device 1 receiver thread ended (pid=2173, tid=3177)
Dec 18 16:53:33 vdrserver vdr: [3176] streamdev-livestreaming thread ended (pid=2173, tid=3176)
Dec 18 16:53:33 vdrserver vdr: [2629] buffer stats: 302680 (8%) used

Alles anzeigen

Das System ist soweit aktuell und mit den Standard-PPA des Ansible-Playbooks ausgestattet:

Code

branch: experimental
ppa_owner: 'ppa:yavdr'
repositories:
  - '{{ ppa_owner }}/{{branch}}-main'
  - '{{ ppa_owner }}/{{branch}}-vdr'
  - '{{ ppa_owner }}/{{branch}}-kodi'

Code

ii  vdr                                       2.4.7-1yavdr0~focal                              amd64        Video Disk Recorder for DVB cards
ii  vdr-addon-acpiwakeup                      0.0.10-11yavdr3~focal                            all          Addon that enables vdr to wakeup itself using ACPI
ii  vdr-addon-avahi-linker                    20160313134933unstable-15yavdr3~focal            all          avahi-linker an VDR-Addon
ii  vdr-addon-lifeguard-ng                    0.0.5-0yavdr2~focal                              all          replacement for vdr-addon-lifeguard
ii  vdr-dev                                   2.4.7-1yavdr0~focal                              amd64        Video Disk Recorder for DVB cards
ii  vdr-markad-ng                             3.0.18-0yavdr0~focal                             amd64        Tool to mark advertisements in VDR recordings
ii  vdr-plugin-dbus2vdr                       20211130143000experimental-0yavdr0~focal         amd64        A VDR plugin, control VDR via DBus
ii  vdr-plugin-desktop                        0.0.3-0yavdr33~focal                             amd64        A VDR plugin, start desktop apps from OSD
ii  vdr-plugin-devstatus                      0.4.1-36yavdr20~focal                            amd64        show status of all video devices used by VDR
ii  vdr-plugin-epgsearch                      2.4.1+git20211210-3-ad5448e-0yavdr0~focal        amd64        VDR plugin that provides extensive EPG searching capabilities
ii  vdr-plugin-lcdproc                        0.0.10-jw9+git20130328-3yavdr34~focal            amd64        Plugin to vdr that connects to lcdproc
ii  vdr-plugin-live-ng                        3.1.3-0yavdr0~focal                              amd64        Web administration plugin for VDR
ii  vdr-plugin-markad-ng                      3.0.18-0yavdr0~focal                             amd64        Plugin for VDR to mark advertisements in recordings
ii  vdr-plugin-menuorg                        0.5.2-1yavdr1~focal                              amd64        VDR plug-in to reorganize the OSD main menu
ii  vdr-plugin-osd2web                        0.2.54+git20200821-1-25309c0-0yavdr3~focal       amd64        status display and osd control on a web page
ii  vdr-plugin-pulsecontrol                   0.2.1-0yavdr18~focal                             amd64        A VDR plugin, control Pulseaudio via vdr's OSD
rc  vdr-plugin-satip                          2.4.1-0yavdr0~focal                              amd64        SAT>IP plugin for VDR
ii  vdr-plugin-softhddevice                   1.2.5-0yavdr0~focal                              amd64        Plugin for VDR. A software and GPU emulated HD device
ii  vdr-plugin-streamdev-client               0.6.1.git20170930-340-e2a9b97-2yavdr17~focal     amd64        VDR Plugin to stream Live-TV to other VDR's - client part
ii  vdr-plugin-xineliboutput                  2.2.0+git20210820-62-f4df324-0yavdr0~focal       amd64        VDR plugin for Xine based sofdevice frontends
ii  vdrctl                                    1.0.0-0yavdr1~focal                              all          A tool to manage the conf.d-files of vdr
ii  vdrpbd                                    2.1.0-0yavdr1~focal                              amd64        vdrpbd sends a shutdown command to VDR if the power button is pressed
ii  yavdr-frontend-tools                      0.0.66-0yavdr3~focal                             amd64        Collection of tools used by python3-yavdrfrontend
ii  yavdr-i18n                                20171218170112unstable-0yavdr4~focal             amd64        i18n support for yaVDR
ii  yavdr-media                               0.0.3-0yavdr2~focal                              all          images and other media for yaVDR
ii  yavdr-remote                              20190704130806unstable-0yavdr3~focal             all          yaVDR remote configuration files
ii  yavdr-xorg                                0+git20160202-15yavdr3~focal                     all          set up x and a systemd user session for the vdr user

auf dem Server noch:

ii  vdr-plugin-streamdev-server          0.6.1.git20170930-340-e2a9b97-2yavdr17~focal     amd64        VDR Plugin to stream Live-TV to other VDR's - server part

Alles anzeigen

Kann mir jemand sagen, was vielleicht ganz einfach ist? Vielen Dank!

vdr (2.4.7/2.4.7) - The Video Disk Recorder

conflictcheckonly (0.0.1) - Direct access to epgsearch's conflict check menu

dbus2vdr (31) - control vdr via D-Bus

devstatus (0.4.1) - Status of dvb devices

epgsearch (2.4.1) - search the EPG for repeats and more

epgsearchonly (0.0.1) - Direct access to epgsearch's search menu

live (3.1.3) - Live Interactive VDR Environment

markad (3.0.18) - Mark advertisements

quickepgsearch (0.0.1) - Quick search for broadcasts

streamdev-server (0.6.1-git) - VDR Streaming Server

vnsiserver (1.8.0) - VDR-Network-Streaming-Interface (VNSI) Server

davie2000 · 18. Dezember 2021

Klingt fast so, als würde der Client den Server nicht zulassen, oder?
Hast du in allen möglichen notwendigen "allow-host"-conf-Files wirklich ALLE deine Server/Clients IPs bzw. das ganze Subnet erlaubt?

Und warum sagt dein Client zum Server erstmal, dass er die Übertragung bestimmter PIDs beenden soll (DELP 5xxx)?

Oder ist das normal und das sind die PIDs des vorher geschauten Kanals?

cduerr · 18. Dezember 2021

Zitat von davie2000

Und warum sagt dein Client zum Server erstmal, dass er die Übertragung bestimmter PIDs beenden soll (DELP 5xxx)?

Oder ist das normal und das sind die PIDs des vorher geschauten Kanals?

tja, gute Frage, nächste Frage!

511x klingt nicht gut. Egal auf welchen Kanal ich gehen wollte, die Meldungen blieben dieselben.

Ich bin aber mittlerweile einen Schritt weiter - und zwar habe ich ein paar Settings, die ich am Anfang geändert hatte um auszuprobieren als es nicht ging auf hier unter Probleme http://www.vdr-wiki.de/wiki/index.php/Streamdev-plugin genannt eingestellt:

Zitat

Kanal nicht verfügbar/Umschaltproblem

Man kann immer nur den Kanal anschauen, welcher auch gerade auf dem VDR-Server eingestellt ist.

Lösung:

Im OSD: OSD --> Einstellungen --> Plugins --> streamdev-server: Pausierverhalten "immer pausieren"

per setup.conf des VDR: streamdev-server.AllowSuspend = 1 streamdev-server.SuspendMode = 1

Umschaltprobleme wegen Primary Limit

Einstellung "Primär-Limit" im Menü "Einstellungen -> Aufnahme" muss auf 0 stehen.

Ist ein höherer Wert eingetragen und eine der DVB-Karten im Server wurde zum "Primary Device" ernannt, dann steht diese Karte Streamdev nicht zur Verfügung.

für letzteres in setup.conf PrimaryDVB=0.

Außerdem habe ich noch gefunden, dass unter Misc. eine Einstellung für SVDRP peering existiert - die habe ich auf Server und Client mal angemacht.

Die Fehlermeldungen von oben bekomme ich nicht mehr, "nur noch" ein "Channel not available".

Zitat von davie2000

Klingt fast so, als würde der Client den Server nicht zulassen, oder?
Hast du in allen möglichen notwendigen "allow-host"-conf-Files wirklich ALLE deine Server/Clients IPs bzw. das ganze Subnet erlaubt?

ich meine: ja.

Code

# IP (range) filter for vdr and plugins (this must be an array):
vdr_allowed_hosts:
   - 192.168.1.0/24 

# hosts and subnets for svdrphosts.conf (overrides vdr_allowed_hosts):
# vdr_svdrphosts:
   - 192.168.1.0/24

# hosts and subnets for allowed_hosts.conf of xineliboutput (overrides vdr_allowed_hosts):
# xineliboutput_allowed_hosts:
#   - 192.168.1.0/24

# hosts and subnets for allowed_hosts.conf of vnsiserver (overrides vdr_allowed_hosts):
# vnsiserver_allowed_hosts:
#   - 192.168.1.0/24

# hosts and subnets for streamdevhosts.conf (overrides vdr_allowed_hosts):
# streamdev_server_allowed_hosts:
   - 192.168.1.0/24


und in svdrphosts.conf/sowie in /etc/vdr/plugins/streamdevhosts.conf:
127.0.0.1              # always accept localhost
192.168.1.0/24

Alles anzeigen

Aber wie gesagt, scheinbar ist *dieses* Problem jetzt schon behoben. Leider weiß ich nicht, was es war.

seahawk1986 · 18. Dezember 2021

Zitat von cduerr

Außerdem habe ich noch gefunden, dass unter Misc. eine Einstellung für SVDRP peering existiert - die habe ich auf Server und Client mal angemacht.

Das ist unabhängig vom Streamdev-Plugin, damit reden die VDRs übers Netzwerk miteinander (und man kann dann z.B. Timer vom Client aus auf dem Server setzen, so wie es das remotetimers-Plugin früher konnte).

seahawk1986 · 18. Dezember 2021

Wie viele Tuner hat dein Server? Das Umschalten wird normalerweise nur dann vom Server blockiert, wenn dieser einen Tuner hat und Live-TV wiedergibt - sonst würde ein Kanalwechsel am Client, der einen anderen Transponder benötigt, dazu führen, dass am Server ebenfalls der Kanal gewechselt wird.

Falls dein Server mehrere Tuner hat, aber der VDR nur einen sieht, musst du ggf. den VDR auf die Tuner warten lassen (das Playbook bietet dafür eine Option: https://github.com/yavdr/yavdr…/focal/group_vars/all#L34 ff.) oder das dynamite-Plugin installieren, damit die Tuner nachträglich eingebunden werden, sobald sie verfügbar werden.

cduerr · 18. Dezember 2021

Zitat von cduerr

Leider weiß ich nicht, was es war.

die PIDs und "DELP"-Messages kamen von der Einstellungen "Simultaneously used devices" (>0) in Einstellungen/Streamdev-client.

cduerr · 18. Dezember 2021

Zitat von seahawk1986

Wie viele Tuner hat dein Server? Das Umschalten wird normalerweise nur dann vom Server blockiert, wenn dieser einen Tuner hat und Live-TV wiedergibt - sonst würde ein Kanalwechsel am Client, der einen anderen Transponder benötigt, dazu führen, dass am Server ebenfalls der Kanal gewechselt wird.

Sind 3. Werden unter DVB status aber angezeigt. Ich habe die Option im Playbook wait_for_dvb_devices entsprechend hinzugefügt und neu installiert; eine Auswirkung dürfte das dann nicht haben?

Warum könnte es jetzt noch scheitern?

Code

Dec 18 18:25:52 vdr3 vdr: [8616] switching to channel 2 C-1-1019-10302 (arte HD)
Dec 18 18:25:52 vdr3 vdr: [8616] info: Channel not available!

Im Server erhalte ich gar keinen Log-Eintrag.

cduerr · 18. Dezember 2021

hm - da dachte ich, ich hätte schon ein Teilproblem behoben. Aber die "simultaneously used devices" in den Einstellungen ist in der setup.conf übersetzt mit "streamdev-client.StartClient. D.h. wenn ich das auf 0 gesetzt habe, ist der Client gar nicht gestartet worden. Etwas verwirrend, irgendwie.

Jetzt ist es wieder auf 1 und die Fehlermeldungen vom Anfang ebenso wieder da.

cduerr · 18. Dezember 2021

Zitat von cduerr

tja, gute Frage, nächste Frage!

511x klingt nicht gut. Egal auf welchen Kanal ich gehen wollte, die Meldungen blieben dieselben.

die PIDs kommen vom ersten Eintrag der channels.conf, die ich selbst erzeugt habe:

Das Erste HD;ARD:314000:C0M256:C:6900:5101=27:5102=deu@3,5103=mis@3;5106=deu@106:5104;5105=deu:0:10301:1:1019:0

seahawk1986 · 18. Dezember 2021

Auf meinen Rechnern funktioniert Streamdev - da sieht das so am Server aus:

Code: /var/lib/vdr/setup.conf

streamdev-server.AllowSuspend = 0
streamdev-server.HideMenuEntry = 0
streamdev-server.HTTPBindIP = 0.0.0.0
streamdev-server.HTTPPriority = 0
streamdev-server.HTTPServerPort = 3000
streamdev-server.HTTPStreamType = 0
streamdev-server.IGMPBindIP = 0.0.0.0
streamdev-server.IGMPClientPort = 1234
streamdev-server.IGMPPriority = 0
streamdev-server.IGMPStreamType = 0
streamdev-server.LiveBufferMs = 0
streamdev-server.LoopPrevention = 0
streamdev-server.MaxClients = 5
streamdev-server.ServerPort = 2004
streamdev-server.StartHTTPServer = 1
streamdev-server.StartIGMPServer = 0
streamdev-server.StartServer = 1
streamdev-server.StartSuspended = 2
streamdev-server.VTPBindIP = 0.0.0.0
streamdev-server.VTPPriority = 0

Alles anzeigen

Code: /var/lib/vdr/svdrphosts.conf

#
# *** ANSIBLE MANAGED FILE ***
# template: /home/alexander/yavdr-ansible/roles/vdr/templates/svdrphosts.conf.j2
#
#
# svdrphosts    This file describes a number of host addresses that
#               are allowed to connect to the SVDRP port of the Video
#               Disk Recorder (VDR) running on this system.
# Syntax:
#
# IP-Address[/Netmask]
#
# Examples:
# 192.168.100.0/24     # any host on the local net
# 204.152.189.113      # a specific host
# 0.0.0.0/0            # any host on any net (USE THIS WITH CARE!)

127.0.0.1              # always accept localhost
192.168.1.0/24

Alles anzeigen

Code: /var/lib/vdr/plugins/streamdev-server/streamdevhosts.conf

#
# *** ANSIBLE MANAGED FILE ***
# template: /home/alexander/yavdr-ansible/roles/vdr/templates/generic_allowed_hosts.conf.j2
#
# This file describes a number of host addresses that
# are allowed to connect to the streamdev-server
# running with the Video Disk Recorder (VDR) on this system.
#
# Syntax:
#
# IP-Address[/Netmask]
#
# Examples:
#
# 192.168.100.0/24     # any host on the local net
# 204.152.189.113      # a specific host
# 239.255.0.0/16       # uncomment for IGMP multicast streaming
# 0.0.0.0/0            # any host on any net (USE THIS WITH CARE!)

127.0.0.1              # always accept localhost
192.168.1.0/24

Alles anzeigen

Und am Client:

Code: /var/lib/vdr/setup.conf

streamdev-client.FilterSockBufSize = 0
streamdev-client.HideMenuEntry = 0
streamdev-client.LivePriority = 1
streamdev-client.MaxPriority = 99
streamdev-client.MinPriority = -99
streamdev-client.NumProvidedSystems = 1
streamdev-client.RemoteIp = 192.168.1.104
streamdev-client.RemotePort = 2004
streamdev-client.StartClient = 1
streamdev-client.StreamFilters = 0
streamdev-client.Timeout = 2

Alles anzeigen

cduerr · 18. Dezember 2021

Vielen Dank!

...habe ich so angepasst und auch noch die streamdevhosts.conf und svdrphosts.conf auf 0.0.0.0/0 erweitert - Verhalten bleibt dasselbe. Hm.

Mittendrin habe ich gesehen, dass im Server das Live-Plugin auch streamdev benutzt - da habe ich live.usestreamdev=0 gesetzt, aber brachte auch nichts.

seahawk1986 · 18. Dezember 2021

Ist die Netzwerkverbindung vom Client zum Server stabil? Hängt da irgendetwas dazwischen, dem man mal einen Neustart gönnen könnte? Gibt es eventuell Hinweise in der Ausgabe von dmesg auf Probleme mit den Netzwerkkarten?

cduerr · 19. Dezember 2021

Die sollte stabil sein. End-to-end funktioniert es (bis auf das obige Problem) und der Paketverlust über längere Zeit ist 0. Sind intel-Gigabit-Adapter.

Könnte das Problem vielleicht beim Aufbau der Datenverbindung entstehen (darauf deutet das Log ja hin)? Gibt es eine lokale Firewall, die angepasst werden müsste?

Ich finde auch den Eintrag "ERROR: Channel locked (recording)!" im syslog des Servers - ist das damit verbunden? Es läuft kein Recording (erst wieder Montag).

Code

Server:
Dec 19 10:35:32 vdrserver vdr: [2969] Streamdev: Accepted new client (VTP) 192.168.1.13:48301
Dec 19 10:35:32 vdrserver vdr: [2969] Streamdev: Setting data connection to 192.168.1.13:42711
Dec 19 10:35:32 vdrserver vdr: [3164] streamdev-writer thread started (pid=2948, tid=3164, prio=high)
Dec 19 10:35:32 vdrserver vdr: [3166] device 1 receiver thread started (pid=2948, tid=3166, prio=high)
Dec 19 10:35:32 vdrserver vdr: [3165] streamdev-livestreaming thread started (pid=2948, tid=3165, prio=high)
Dec 19 10:35:32 vdrserver vdr: [3167] device 1 TS buffer thread started (pid=2948, tid=3167, prio=high)
Dec 19 10:35:33 vdrserver vdr: [3164] ERROR: streamdev-server: couldn't send 702556 bytes: Connection reset by peer
Dec 19 10:35:33 vdrserver vdr: [3164] streamdev-writer thread ended (pid=2948, tid=3164)
Dec 19 10:35:33 vdrserver vdr: [2969] streamdev-server: closing VTP connection to 192.168.1.13:48301
Dec 19 10:35:33 vdrserver vdr: [3167] device 1 TS buffer thread ended (pid=2948, tid=3167)
Dec 19 10:35:33 vdrserver vdr: [3166] buffer stats: 149084 (0%) used
Dec 19 10:35:33 vdrserver vdr: [3166] device 1 receiver thread ended (pid=2948, tid=3166)
Dec 19 10:35:33 vdrserver vdr: [3165] streamdev-livestreaming thread ended (pid=2948, tid=3165)
Dec 19 10:35:33 vdrserver vdr: [2969] buffer stats: 702932 (18%) used

Client:
Dec 19 10:35:32 vdr3 vdr: [1257] streamdev-client: Connected to server 192.168.1.4:2004 using protocol version 1.0
Dec 19 10:35:32 vdr3 vdr: [1257] streamdev-client: Command 'DELP 5111' rejected by 192.168.1.4:2004: 560 Pid 5111 not transferring
Dec 19 10:35:32 vdr3 vdr: [1257] streamdev-client: Command 'DELP 5112' rejected by 192.168.1.4:2004: 560 Pid 5112 not transferring
Dec 19 10:35:32 vdr3 vdr: [1257] streamdev-client: Command 'DELP 5113' rejected by 192.168.1.4:2004: 560 Pid 5113 not transferring
Dec 19 10:35:32 vdr3 vdr: [1257] streamdev-client: Command 'DELP 5116' rejected by 192.168.1.4:2004: 560 Pid 5116 not transferring
Dec 19 10:35:32 vdr3 vdr: [1257] streamdev-client: Command 'DELP 5117' rejected by 192.168.1.4:2004: 560 Pid 5117 not transferring
Dec 19 10:35:32 vdr3 vdr: [1257] streamdev-client: Command 'DELP 5115' rejected by 192.168.1.4:2004: 560 Pid 5115 not transferring
Dec 19 10:35:32 vdr3 vdr: [1257] streamdev-client: Command 'DELP 5118' rejected by 192.168.1.4:2004: 560 Pid 5118 not transferring
Dec 19 10:35:32 vdr3 vdr: [1257] streamdev-client: Command 'DELP 5119' rejected by 192.168.1.4:2004: 560 Pid 5119 not transferring
Dec 19 10:35:32 vdr3 vdr: [2824] device 2 receiver thread started (pid=1257, tid=2824, prio=high)
Dec 19 10:35:32 vdr3 vdr: [2824] ERROR: streamdev-client: Couldn't establish data connection to 192.168.1.4:2004: Resource temporarily unavailable
Dec 19 10:35:32 vdr3 vdr: [2824] cStreamdevDevice::OpenDvr(): DVR connection FAILED
Dec 19 10:35:32 vdr3 vdr: [2824] device 2 receiver thread ended (pid=1257, tid=2824)

Alles anzeigen

Ich will hier nicht mit Windows-Denke ankommen, aber: macht es Sinn, die Systeme neu aufzusetzen? Sind nach Anleitung des yavdr-Projekts installiert.

davie2000 · 19. Dezember 2021

Zitat von cduerr

Ich finde auch den Eintrag "ERROR: Channel locked (recording)!" im syslog des Servers - ist das damit verbunden? Es läuft kein Recording (erst wieder Montag).

Was hast du den für die Aufnahme für einen Vorlauf (im OSD) eingestellt? Evtl. blockt der Server das Umschalten, weil er sich schon auf die Aufnahme "vorbereitet"?

Ich denke, aber doch, dass du noch ein - wie immer geartetes - Verbindungsproblem hast. Blockt dein Router vielleicht bestimmte Ports?

Viel Erfolg jedenfalls!

cduerr · 19. Dezember 2021

Vielen Dank!

Die Verbindung zwischen Server und Client sollte rein geswitcht (Layer2) sein. Zwar habe ich auch eine Fritzbox am Start (und denen trau ich einigen Schund zu; aber die übliche Problematik mit dem MAC-Filter sollte ausgeschlossen sein, wenn die Kommunikation im Prinzip funktioniert). Sie ist auch nur als Router "am Rande" angeschlossen; sämtliche Geräte sind im lokalen Netz und können sich mittels Layer2 direkt erreichen.

Ich habe mir einen Dump des Netzwerkinterfaces auf dem Server erstellt, während ich umschalten wollten.

Ich bekommen einen Control-Channel und einen Daten-Channel. Wenn ich mir nur den Daten-Channel angucke, habe ich

vdrserver (irgendein Port x)->vdr3 (irgendein Port y) TCP, SYN

vdr3 (y)->vdrserver (x) TCP, SYN, ACK

vdrserver (x)->vdr3 (y) TCP, ACK

vdr3 (y)->vdrserver (x) TCP, RST

Dazwischen (direkt vor dem RST) sind noch ein (für den Control-Channel)

vdrserver (2004) -> vdr3 (53001) TCP PSH, ACK und

vdr3 (53001) -> vdrserver (2004) TCP ACK.

In dem PSH, ACK-Paket ist ein Payload, aber nichts, was ich jetzt entziffern könnte. Da fehlt mir irgendwie die Spezifikation zu.

Von der Logik her hilft mir das leider auch nicht weiter. Entweder, der Server sagt "gut, ich leg dann mal los!" und der Client bricht unerwartet ab, oder der Server sendet schon eine Info, die den Client veranlasst, den RST zu schicken. Keine Ahnung.

Zitat von davie2000

Was hast du den für die Aufnahme für einen Vorlauf (im OSD) eingestellt? Evtl. blockt der Server das Umschalten, weil er sich schon auf die Aufnahme "vorbereitet"?

schau ich mir an, danke

Ist das "Margin at start"? Steht auf den Default-2min.

seahawk1986 · 19. Dezember 2021

IIRC hatte ich in zwei Netzwerken mit Fritzbox als Router und DHCP-Server merkwürdige Effekte nach dem Wechsel von yaVDR 0.5 zu einer neueren Version auf der selben Maschine, die nach einem Neustart weg waren.

Hast du mal versucht den Timeout fürs Umschalten am Client etwas hochzusetzen?

Zitat von cduerr

die PIDs kommen vom ersten Eintrag der channels.conf, die ich selbst erzeugt habe:

Ist die Handgeklöppelt? Hast du mal versucht mit w_scan2 (Paket w-scan2) oder w_scan_cpp (Paket w-scan-cpp) einen Kanalscan zu machen oder gibt es da irgendwelche Besonderheiten bei deinem Kabel-Empfang?

Ansonsten wäre ein ungekürztes Log des Servers ab Boot (journalctl -b -l > log.txt) interessant, vielleicht sieht man dann, warum da Tuner vermeintlich blockiert sind (IIRC kann das devstatus-Plugin auch Probleme im Zusammenspiel mit streamdev machen).

cduerr · 19. Dezember 2021

Zitat von seahawk1986

IIRC hatte ich in zwei Netzwerken mit Fritzbox als Router und DHCP-Server merkwürdige Effekte nach dem Wechsel von yaVDR 0.5 zu einer neueren Version auf der selben Maschine, die nach einem Neustart weg waren.

habe ich getan, hat nichts verbessert. Wie gesagt, dass die mitunter komische Dinge tun (vor allem wenn man die Internetsperre aktiviert hat), habe ich auch schon selbst leidvoll erleben dürfen - In dem Fall funktioniert der Handshake, von daher schließe ich die Fritzbox-Paketfilterfunktionalität einfach mal aus.

Zitat von seahawk1986

Ist die Handgeklöppelt? Hast du mal versucht mit w_scan2 (Paket w-scan2) oder w_scan_cpp (Paket w-scan-cpp) einen Kanalscan zu machen oder gibt es da irgendwelche Besonderheiten bei deinem Kabel-Empfang?

habe ich mittels w_scan -c de -f c > channels.conf.dvbc.pyur.20211218 erstellt.

Code

Das Erste HD;ARD:314000:C0M256:C:6900:5101=27:5102=deu@3,5103=mis@3;5106=deu@106:5104;5105=deu:0:10301:1:1019:0
arte HD;ARD:314000:C0M256:C:6900:5111=27:5112=deu@3,5113=fra@3,5116=mul@3,5117=mis@3:5114;5115=deu,5118=fra,5119=deu:0:10302:1:1019:0
SWR BW HD;ARD:314000:C0M256:C:6900:5121=27:5122=deu@3,5123=mis@3;5126=deu@106:5124;5125=deu:0:10303:1:1019:0
SWR RP HD;ARD:314000:C0M256:C:6900:5121=27:5122=deu@3,5123=mis@3;5126=deu@106:5134;5135=deu:0:10304:1:1019:0
ServusTV HD Deutschland;PYUR:554000:C0M256:C:6900:4920=27:4921=deu@4,4922=eng@4;4924=deu@106:4925:0:1537:61697:49158:0

Zitat von seahawk1986

Ansonsten wäre ein ungekürztes Log des Servers ab Boot (journalctl -b -l > log.txt) interessant, vielleicht sieht man dann, warum da Tuner vermeintlich blockiert sind (IIRC kann das devstatus-Plugin auch Probleme im Zusammenspiel mit streamdev machen).

ich probiere mal, das devstatus Plugin zu deaktivieren und würde mich dann mit dem Log noch einmal melden.

cduerr · 19. Dezember 2021

Devstatus zu deaktivieren (auf Client und Server) hat auch nichts gebracht. Das Log wäre jetzt angefügt.

Ich mach auch gerne den Debug-Modus für den streamdev-server/-client an - habe nur in der Plugin-Doku nicht den Parameter gefunden, den ich vermutlich in /etc/vdr/conf.d/50-streamdev-server.conf setzen müsste.

cduerr · 19. Dezember 2021

so, habe den Server jetzt auf einen USB-Stick neu aufgesetzt - und dasselbe Verhalten. Mit den Default-Einstellungen.

Was ist denn mit dem cloud-init gemeint? Ich fand die Auswahl auf der Ubuntu-Seite sehr verwirrend. Da stand was mit cloud-init, also habe ich nicht gleich das genommen, sondern noch auf die anderen Options geklickt. Das Ergebnis war dann aber ein Ubuntu 20.04._02_, wo beim Boot ganz viele cloud-init-Meldungen durchflitzen. Könnte das damit zu tun haben? Bis jetzt habe ich nur gelesen, dass der vielleicht bei X Probleme macht (hier betreibe ich aber headless ohne X), außerdem bekomme ich beim Betrachten der Playbook-Ausgaben den Eindruck, dass das deaktiviert werden können sollte.

Hm. Oder es liegt am Client. Argh. Wo ist der nächste USB-Stick?

davie2000 · 19. Dezember 2021

Mit yaVDR-Ansible darf/soll cloud-init NICHT installiert werden, afaik.

Lt. Doku muss es Ubuntu-Server ohne cloud-init sein.

btw: hab übrigens auch neuerdings eine Fritzbox und keinerlei VDR-Probleme damit.

streamdev-client Probleme

Jetzt mitmachen!

Teilen

Tags