[outis]

Hallo,

in Absprache mit Claus eröffne ich hier eine Art Sammelstelle für Beobachtungen beim Einsatz des rpi4 unter MLD. Dass der rpi4 noch in der Hinsicht Baustelle ist, ist klar. Und dementsprechend geht es hier nicht darum, Kritik über die Entwickler auszuschütten. Sondern um Hinweise, wo noch Baustellen auftauchen könnten.

Vorab: Ich habe den rpi4 als Server laufen. Dass Clientbetrieb mangels Frontend im Moment nicht sinnvoll ist, sollte klar sein.

Anlass, den rpi4 als Server in Stellung zu bringen, waren Fehlermeldungen (mit einem rpi3) wie diese:

SATIP-ERROR: Detected invalid status code 404: rtsp://192.168.100.103/ [device 0]

In der Diskussion darüber wurde die Netzwerkgeschwindigkeit angesprochen. Und deswegen kam testweise der rpi4 zum Einsatz.
Für Interessenten: Um diesen thread geht es:
https://www.minidvblinux.de/forum/index.php/topic,9765.0.html

Die genannte Fehlermeldung taucht bisher beim rpi4 nicht auf. Dafür gönnt sich der das:

Apr 17 16:29:11 MLD user.err vdr: [1795] SATIP-ERROR: Detected invalid status code 0: rtsp://192.168.100.103/ [device 0]

Egal, das Thema soll hier nicht weiter verfolgt werden. Denn letztlich dürfte der im oben genannten thread erwähnte SAT-IP-Umsetzer halt das entscheidende Wörtchen beitragen. Und da Aufnahmen oder auch im allgemeinen Life-TV nicht gestört werden, ist es wirklich nachrangig, das Problemchen.

So, nun zum eigentlichen Thema:

1. Hinzufügen von Speichermedien war gestern holprig. Bei der Erstinstallation war alles problemlos: mergerfs und gut war. Dann habe ich ein wenig rumgespielt: Nur die SSD sollte für Aufnahmen genutzt werden, nicht mehr Teile der Speicherkarte. Und damit ging das Elend los. Die SSD wollte im Webif einfach nicht mehr Datenspeicher werden. Das ging erst dann wieder, nachdem mergerfs durch aufs ersetzt war. Dann stehen in der fstab Einträge, die das Webif offenbar verdaut:

#MLD-SERVER:/data  /mnt/data  nfs    bg        0 0
#192.168.100.105:/data  /mnt/data  nfs  bg  0 0
/dev/sda1   /mnt/sda1       ext4    defaults         0 0
/mnt/sda1  /data  none  bind  0 0

Die auskommentierten Zeilen stammen noch vom mergerfs?? Das passte offenbar nicht. Keine Ahnung, warum da nfs auftaucht. Möglicherweise hat mergerfs nach nfs-Laufwerken gesucht und die vom rpi4 bereitgestellten genutzt.

2. nfs-Exports:
Nach der Installation von aufs und Integration der SSD als Speichermedium wollte die /etc/exports angepasst werden:

## export the data dir rw for everyone
#/mnt/data   *(rw,all_squash,anonuid=0,anongid=0,no_subtree_check,crossmnt,fsid=1)
/data   *(rw,all_squash,anonuid=0,anongid=0,no_subtree_check,crossmnt,fsid=1)

Denn /mnt/data existiert nicht.

3. SVDRP

Gestern zumindest klappte die Kommunikation zwischen rpi3-Client und rpi4-Server offenbar nicht stabil. Denn der Client "vergass" gelegentlich den Eintrag SVDRP-Standardmaschine, wenn als SVDRP-Verbindung "nur mit der Standardmaschine" eingegeben war. Entsprechend konnte der Client nicht mehr die Server-Timer und -Aufnahmen sehen. Erst wenn am Client "mit jeder Maschine" konfiguriert war, tauchte der Server wieder als SVDRP-Standardmaschine auf. Das kann ich aber im Moment nicht gezielt reproduzieren.

Insgesamt läuft der rpi4 schon recht stabil als Server.  Und gefühlt auch performanter als der vorher eingesetzte rpi3. Kanalumschalten am Client geht schneller, das via streamdev ausgelieferte Bild steht schneller. Also bleibt der rpi 4 vorerst im Einsatz. Und wird weiter beobachtet.

[clausmuus]

Danke für die Rückmeldung.
Punkt drei beobachteten Probleme sind keine RPI4 spezifischen Sachen. Die Einträge in der fstab sollten unabhängig von aufs, mergerfs oder keinem von beiden so aussehen solange kein zweites Datenlaufwerk ausgewählt ist. Die beiden auskommentierten Zeilen dürften daher rühren, das Du mal einen nfs Mount hinzugefügt hattest.
Den Fehler in der /etc/exports muss ich mir noch mal anschauen. Da fehlen wohl noch ein paar korrekturen/aktualisierungen bei meinen Datenlaufwerk Verwaltungs-Aufräumarbeiten.
Das SVDRP Problem sollte eigentlich nicht mehr auftreten, sofern es das ist was ich vermute. Bis vor ein paar Tagen wurde per Voreinstellung nicht der Name des Servers sondern dessen IP beim Client eingetragen. Das funktioniert aber nicht. Bei einer frischen Client Installation steht jetzt der Server Name in der Konfiguration, und damit sollte die Verbindung dann auch funktionieren. Das kann aber auch bei älteren Client Installationen über das OSD oder in der VDR Config Datei korrigiert werden.

[outis]

Zum Thema SVDRP:

Eben wieder: Der Client hatte eingegeben Verbindung nur mit der Standardmaschine (dem MLD-Server). Eben nur nebenbei beim Client auf die Timer geschaut - keine da. Also flugs in die SVDRP-Einstellungen geschaut: MLD-Server nicht mehr als Standardmaschine aufgeführt, die Option wurde wieder gar nicht angezeigt. Also im Client Verbindung auf alle Maschinen gesetzt und sofort ließ sich die Standardmaschine wieder sehen. Eigentlich also im Prinzip das, was im Manual steht. Was aber stört: Der Client (MLD 5.4 stable) vergisst die Standardmaschine, wenn der rpi4 bzw. dessen Software im Spiel ist. Ich kann mich nicht erinnern, dass diese Vergesslichkeit mit rp3-MLD5.4 stable auftrat. Und ich habe im log keinerlei SVDRP-bezügliche Einträge, weder auf dem Server noch auf dem Client. Stochern also im Nebel, wann und warum das Problem akut wird.

[clausmuus]

Ist der Server immer an, wenn der Client läuft?

[outis]

Ja. Behaupte ich mal frech. Allerdings scheint zeigt er mir auch das Bild im Anhang. Das kann aber nicht stimmen, im Moment zeichnet er nämlich eine Aufnahme auf. Und das live-Plugin ist immer (!) erreichbar. Und das ist ja nur dann der Fall, wenn der vdr läuft. Und auch das folgende spricht dafür, dass der vdr durchläuft:

Code: [Select]

MLD-Server> cat /var/log/vdr
INFO: validating live server ip '0.0.0.0'
Wenn der vdr zwischenzeitlich des öfteren neu gestartet wäre, müsste das doch öfters verzeichnet sein, oder?

[outis]

Noch eine Auffälligkeit:

Code: [Select]

MLD-Server> grep markad /var/log/messages
Apr 18 20:10:04 MLD user.err markad: [24866] starting v0.1.6 (45fcc0f) (32bit)
Apr 18 20:10:04 MLD user.err markad: [24866] on /mnt/sda1/tv/Klassik_am_See_-_A_Tribute_to_John_Williams/2020-04-18.20.10.5-0.rec
Apr 18 20:10:04 MLD user.err markad: [24866] paused by signal

Code: [Select]

MLD-Server> grep markad /etc/vdr/setup.conf
markad.DeferredShutdown = 1
markad.Execution = 0
markad.GenIndex = 0
markad.HideMainMenuEntry = 0
markad.IgnoreMargins = 0
markad.Log2Rec = 0
markad.LogoOnly = 1
markad.OSDMessage = 1
markad.SaveInfo = 1
markad.SecondPass = 1
markad.Verbose = 0
markad.whileRecording = 0
markad.whileReplaying = 0

Konfiguriert im OSD ist Ausführung Markad "danach".

Immerhin zeigt der Menüpunkt Markad Status etwas an. OK, wir hatten des Thema Markad ja schon neulich im Kontext MLD 5.4 stable. Und so bleibt die Erkenntnis, dass immer mal etwas Anderes passiert. Und der Dokumentation halber hier aufgeführt ist.

[outis]

SVDRP:

Der Client hat's wieder vergessen. Siehe Bild mld.png im Anhang. Auf dem Server mld1.png. Streamdevinfo auf dem Server mld2.png.

In mld3.png haben wir uns wieder lieb, Client und Server.

Ist das Trennen bei Inaktivität das Problem?

[clausmuus]

Stellst Du das denn nach dem Auswählen der Standartmaschine wieder auf "Nur mit der Standartmaschiene" zurück?
Hast Du mal fünf Minuten nach dem einstellen geschaut, wie die Konfiguration dann aus schaut?
Das Trennen bei Inaktivität bezieht sich eigentlich nur auf andere Tools die den svdrp Port nicht blockieren dürfen wenn die nichts machen.

[outis]

Kleine Testreihe:

15:04 Stand Serverkonfig wie oben im Beitrag von gestern (dort mld1.png), Client hatte mal wieder die Standardmaschine vergessen (lief ohne Unterbrechung seit gestern 19:00). Also wieder eingetragen (SVDRP Verbindung aus, Verbindung mit jeder Maschine, dann Standardmaschine wieder verfügbar). mld.png
15:08 Wieder nachgeschaut. Standardmaschine wieder weg, also wieder eingetragen und Verbindung "mit jeder Maschine" so belassen (mld1.png). Server-Konfiguration unverändert. Bis jetzt (15:25) ist die Standardmaschine noch vorhanden. Offenbar verschwindet die nur, wenn die Verbindung auf "nur mit Standardmaschine" gesetzt wird.

Ach ja - Markad pausiert seit gestern (mld2.png). Das nur deswegen erwähnt, weil ich es interessant finde, dass ein Code, der, wie anderen Orts erwähnt, seit Jahren unverändert übernommen wird, in unterschiedlichen Images sich unterschiedlich verhält. Bei rpi3-MLD 5.4 tat Markad nur dann etwas, wenn händisch angestoßen, egal, was ansonsten konfiguriert wurde. Hier bei der 5.5 ist es hingegen übereifrig: Läuft an, auch wenn es das gar nicht soll, pausiert dann und tritt in Streik.

[outis]

Nur für's Protokoll (steht ja schon auf der Todo-Liste):

Auch wenn der Client Verbindung "mit jeder Maschine" vorgegeben hat, vergisst er die Standardmaschine.