[Walter]

Moin,
hier funktioniert auf einem rpi3 per streamdev-Client mit der MLD-5.4-testing, das Umschalten auf einen anderen Channel, nicht korrekt.
Wird auf den nächsten Channel per P+ geschaltet, wird die Info für den Channel kurz angezeigt aber es wird nicht umgeschaltet,
anschließend wird dann wieder die Info für den bisherigen Kanal angezeigt.
Oder nach dem Umschalten wird das Bild schwarz, keine Kanalinfo wird angezeigt, irgendwann kommt wieder ein TV-Bild.
Gelegentlich gibts auch die Meldung, Channel nicht verfügbar, bei nur 1 gleichzeitig genutzter Karte in den Plugin Einstellungen von Stream-Client. 

Ab und an kann man auch mal 3-4 Kanäle am Stück ohne diese Probleme schalten.

Genutzt wird per streamdev eine yaVdr (vdr-2.0.6) Installation mit 7 dvb devices (Jess Multischalter).
Mit einem MLD-5.1-Testing Client (rpi2) funktioniert das alles problemlos, da gab es bisher noch nie diese Probleme.

Habe dann auf eine andere SSD alles auch neu installiert, vaVDR-0.62 u vdr-2.40 (ppa v. Frodo). Da ist es ebenso, nur Probleme beim Umschalten.
   
aus dem Log, schwarzes Bild

Code: [Select]

May 26 17:16:01 (none) user.err vdr: [4201] ERROR (device.c,1902): Bad file descriptor
May 26 17:16:03 (none) user.err vdr: [2010] cStreamdevFilters::Action(): stream disconnected ?
May 26 17:16:16 (none) user.err vdr: [1505] ERROR: streamdev-client: Failed reading reply to 'PROV 0 S19.2E-1-1089-12003' from 192.168.111.77:2004: Connection timed out
May 26 17:16:19 (none) user.err vdr: [4638] cStreamdevFilters::Action(): stream disconnected ?
Wo ist die Ursache zu suchen, was tun?

mfg

 
 

[clausmuus]

Am besten postest Du das mal im VDR-Portal, da es ja wohl ganz allgemein den VDR-2.4 betrifft. Bitte Poste hier dann den Link zum VDR-Portal.

[Walter]

Hallo,
der Fehler mit dem Umschalten scheint ja nur hier aufzutreten. 
Installiere gerade noch vdr-2.4.0 unter raspbian stretch. Mal schauen, ob es sich dort ebenso verhält.
Der cec.Kram für die FB fehlt leider noch.
Dann kann ich es ja mal vdr-portal posten.
mfg

[Walter]

Moin,
habe es mal ohne FB getestet (raspbian), im Terminal  per  'svdrpsend CHAN +'

Code: [Select]

tail -f /var/log/syslog
May 30 08:11:03 ras145 vdr: [2634] device 2 receiver thread ended (pid=2560, tid=2634)
May 30 08:11:03 ras145 vdr: [2636] device 1 TS buffer thread started (pid=2560, tid=2636, prio=high)
May 30 08:11:03 ras145 vdr: [2637] streamdev-client: sections assembler thread started (pid=2560, tid=2637, prio=high)
May 30 08:11:03 ras145 vdr: [2638] device 1 receiver thread started (pid=2560, tid=2638, prio=high)
May 30 08:11:03 ras145 vdr: [2639] device 1 TS buffer thread started (pid=2560, tid=2639, prio=high)
May 30 08:11:04 ras145 vdr: [2638] rpihddevice: set video codec to H264
May 30 08:11:04 ras145 vdr: [2572] rpihddevice: set HDMI audio output format to 2ch PCM, 48.0kHz
May 30 08:11:05 ras145 vdr: [2571] rpihddevice: video stream started 1920x1080@50i, PAR=1/1
May 30 08:11:05 ras145 vdr: [2571] rpihddevice: display PAR=1,000, setting video render PAR=1/1
May 30 08:11:07 ras145 vdr: [2633] cStreamdevFilters::Action(): stream disconnected ?
May 30 08:11:22 ras145 vdr: [2633] ERROR: streamdev-client: Failed reading reply to 'ABRT 2' from 192.168.111.77:2004: Die Wartezeit für die Verbindung ist abgelaufen
May 30 08:11:22 ras145 vdr: [2632] device 1 TS buffer thread ended (pid=2560, tid=2632)
May 30 08:11:22 ras145 vdr: [2633] buffer stats: 20680 (1%) used
May 30 08:11:22 ras145 vdr: [2633] StreamdevFilters::Action() ended
May 30 08:11:22 ras145 vdr: [2633] streamdev-client: sections assembler thread ended (pid=2560, tid=2633)
bleibt leider auch länger schwarz, bis dann ein Bild angezeigt wird
Der vdr startet dabei nicht neu, es dauert einfach paar Sekunden.

mfg

[rfehr]

Moin,
habe es mal ohne FB getestet (raspbian), im Terminal  per  'svdrpsend CHAN +'

Code: [Select]

tail -f /var/log/syslog
May 30 08:11:22 ras145 vdr: [2633] ERROR: streamdev-client: Failed reading reply to 'ABRT 2' from 192.168.111.77:2004: Die Wartezeit für die Verbindung ist abgelaufen
bleibt leider auch länger schwarz, bis dann ein Bild angezeigt wird
Der vdr startet dabei nicht neu, es dauert einfach paar Sekunden.

mfg

das sieht nach einem Netzwerk Problem aus.

Es gibt doch einen Parameter
streamdev-client.StreamFilters = 1
setze den mal auf 0.

Gruß,
  Roland

[Walter]

Hallo,
leider unverändert mit 'streamdev-client.StreamFilters = 0' . Danke.

Aber, habe jetzt festgestellt, das es wahrscheinlich an einem von den Patches liegen sollte.
Vdr-2.4.0 und lediglich mit den 4 Patches von KLS getestet, da funktioniert es scheinbar problemlos. Aber nur kurz getestet per

/usr/local/bin/vdr -c /etc/vdr -v /srv/vdr/video -P"streamdev-client" -P"rpihddevice"

Hatte bisher auch unter Raspbian diese Patches von MLD für vdr-2.4.0 angewandt

04_vdr_menuselection.patch
05_vdr_editrecording.patch
06_vdr_avcdescriptor.patch
10_vdr_epgsearch_exttimeredit_vdr-2.3.5.patch
15_vdr_mainmenuhooks_vdr234.patch
26_vdr_menuorg.patch

Werde heute Abend mal schauen, ob es an einem der Patches liegt.
mfg

[Walter]

Hallo,
lasse ich von den genannten sechs Patches, den 15_vdr_mainmenuhooks_vdr234.patch weg, funktioniert es ohne Probleme.

Der Fehler tritt auf, wenn vdr-2.4.0 mit den 4 Patches von KLS und diesen beiden

15_vdr_mainmenuhooks_vdr234.patch
12_vdr_pin.patch

gepatched wurde.

Gibt es noch einen anderen, vielleicht aktuelleren mainmenuhooks Patch ?
Mfg 

[Walter]

Moin,
habe jetzt noch mal die beiden Patches von MLD, pin und mainmenuhooks, durch den
MainMenuHooks-v1.0.1.patch von yavdr ersetzt, auch der Fehler.
mfg

[Walter]

Moin,
habe beim  Testen jetzt festgestellt, das es problemlos läuft, auch mit dem mainmenuhooks.patch.

Habe dazu jetzt diese Patches angewandt
vdr und der 4 Patches von KLS

04_vdr_menuselection.patch  05_vdr_editrecording.patch  06_vdr_avcdescriptor.patch  10_vdr_epgsearch_exttimeredit_vdr-2.3.5.patch
15_vdr_mainmenuhooks_vdr234.patch 26_vdr_menuorg.patch

vdr-plugin-rpihddevice lediglich

Code: [Select]

-LDLIBS  += -lbcm_host -lvcos -lvchiq_arm -lopenmaxil -lGLESv2 -lEGL -lpthread -lrt
+LDLIBS  += -lbcm_host -lvcos -lvchiq_arm -lopenmaxil -lbrcmEGL -lbrcmGLESv2 -lpthread -lrt

und beim
vdr-plugin-streamdev-e2a9b979d3fb92967c7a6a8221e674eb7e55c813

13_streamdev_api-version-check.patch und 14_streamdev_detlock_fix.patch

unter Raspbian kompiliert, kein Docker, und einfach die Files in die MLD-5.4.0 testing Installation kopiert.

Damit trat der Fehler beim Umschalten bisher nicht mehr auf.

Mit allen Patches der Plugins,  streamdev-client rpihddevice, gibts die Probleme beim Umschalten.
Den vdr selbst mit allen Patches habe jetzt noch nicht getestet.

mfg

[clausmuus]

Na, da bin ich ja weiterhin gespannt, welcher Patch sich letztendlich als Ursache des Problems herausstellt.

[Walter]

Hallo,
habe mal nur libvdr-streamdev-client.so.2.4.0 gegen die originale von mld getauscht. Wieder die Probleme.

Code: [Select]

Jun  3 13:08:04 (none) user.err vdr: [22882] ERROR (device.c,1881): Bad file descriptor
Jun  3 13:08:30 (none) user.err vdr: [22810] ERROR: streamdev-client: Failed reading reply to 'PROV 0 S19.2E-1-1011-11130' from 192.168.111.77:2004: Connection timed out
Mit der originalen libvdr-rpihddevice.so.2.4.0 läuft es.
Die ori vdr binary mit allen Patches habe ich gerade nicht. 
mfg

[clausmuus]

Ähhm, da waren mir jetzt ein paar zu viele "Originale" in deinem letzten Post. Was nimmst Du von der MLD und was musst Du ändern, damit es geht?

[Walter]

Moin,
momentan geändert
vdr incl. 4 Patches von KLS

04_vdr_menuselection.patch  05_vdr_editrecording.patch  06_vdr_avcdescriptor.patch  10_vdr_epgsearch_exttimeredit_vdr-2.3.5.patch
15_vdr_mainmenuhooks_vdr234.patch 26_vdr_menuorg.patch

und
streamdev-client (vdr-plugin-streamdev-e2a9b979d3fb92967c7a6a8221e674eb7e55c813)

13_streamdev_api-version-check.patch und 14_streamdev_detlock_fix.patch

damit funktioniert es, kein einziges mal Probleme beim Umschalten.
vdr mit allen patches (pin etc) habe ich jetzt noch nicht getestet
mfg

[Walter]

Moin,
habe dann nochmal die 5.4-testing-rpi3 installiert.
Das Umschalten funktioniert ohne Probleme, wenn beim vdr-plugin-streamdev-client, der  11_streamdev_channelchange.patch,
nicht angewendet wird.
Mit dem Patch gibt es hier die genannten Probleme beim Umschalten.
mfg

[clausmuus]

Danke für's testen. Ich habe dieses Problem auf meine ToDo Liste gepackt.