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.htmlDie 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.