31

Allgemein [ General ] / Neuinstallation

« Last post by purzel on August 24, 2026, 15:52:57 »

Eventuell hilft es, wenn Du beim herunterfahren einmal die ESC Taste drückst. Dann sollten alle Logmeldungen angezeigt werden, und auch, auf welche Prozesse gewartet wird. Alternativ kannst Du beim Booten den Verbose Modus auswählen, das wirkt sich auch auf das herunterfahren aus.

EINmal Esc drücken reichte nicht, ich musste mehrmals drücken; verbose beim Start führte nicht zu ausführlichen Meldungen beim RUNTERfahren. Nach mehrmals Esc-Taste beim Runterfahren aber konnte ich ein bisschen sehen: Vieles wurde schnell gestoppt, bis einschließlich "MLD webIf". Danach kommt noch "A stop job is running for Foreground App" mit 'runterzählender Zeit. Nach über einer Minute dann kommen für Bruchteile von Nanosekunden noch irgendwelche Meldungen und dann schaltet er aus.

Es kann Durchaus sein, dass ein VDR Plugin das Herunterfahren des Systems verlangsamt. Dies tritt z.B. auf, wenn dies sehr ausgiebige stop Aktionen durchführt, oder das Beenden des VDRs komplett blockiert. Allerdings würde ich so was eher beim EPG-Daemon vermuten, als beim vaapi Plugin.

Du bist der Boss - aber der Effekt ist meiner Erinnerung nach erst seit Benutzen von VAAPI da. Kann es sein (so richtig gut bin ich in Sachen Systemd (noch) nicht), dass er den wegen VAAPI ohnehin nicht mehr laufenden X-Server versucht abzuschießen? (Bezug: /etc/systemd/system/multi-user.target.wants/appstarter.service und /usr/bin/appstarter.sh )
Ich probiere es vielleicht nochmal mit softhddevice. Snapshot nicht vergessen

Übrigens fährt er bei Drücken des Hardware-Powerknopf gar nicht runter. Warum nicht?

Du kannst eigene Scripte z.B. unter /usr/share/vdr/shutdown.d ablegen, wenn es sich um VDR spezifische aktionen handelt, und dort auch steuern ob das herunterfahren unterbunden/verschoben werden soll.
Oder Du erstellst Dir einen eigenen systemd Service, den Du unter /etc/systemd/system ablegst, und rufst über den Dein Script auf. Dann kannst Du genau festlegen wann das ausgeführt werden soll.

Das Script in  /usr/share/vdr/shutdown.d klappt - nachdem ich gefühlte 100 Mal über einen Tippfehler der das wirkungsvoll verhindert hat hinweg geschaut hatte  Mit Systemd habe ich mich wie oben erwähnt noch nicht nicht so richtig angefreundet 

32

Allgemein [ General ] / Neuinstallation

« Last post by clausmuus on August 24, 2026, 11:29:12 »

Du kannst eigene Scripte z.B. unter /usr/share/vdr/shutdown.d ablegen, wenn es sich um VDR spezifische aktionen handelt, und dort auch steuern ob das herunterfahren unterbunden/verschoben werden soll.
Oder Du erstellst Dir einen eigenen systemd Service, den Du unter /etc/systemd/system ablegst, und rufst über den Dein Script auf. Dann kannst Du genau festlegen wann das ausgeführt werden soll.

33

Allgemein [ General ] / Bild erst nach VDR Restart

« Last post by clausmuus on August 24, 2026, 11:25:14 »

Wenn Dein System aktuell ist, sollte in der ld.so.preload ist die Zeile '/opt/lib/libmediaclient.so' nicht mehr existieren, wobei ich nicht sicher weiß, ob diese beim Update auch entfernt wird. Entferne also einfach mal die Zeile und teste ob das Problem dann nicht mehr besteht.
Sollte das Entfernen der Preload Zeile nicht helfen, erstelle mal Bitte ein Debug-Log. Dann erstelle ich Dir eine angepasste /etc/fstab

Der VDR wartet beim Booten bis zu einer halben Minute auf die DVB Devices. Deshalb ist in den Service Dateien keine Abhängigkeit eingetragen (das erledigt das VDR Startscript).

34

Allgemein [ General ] / Neuinstallation

« Last post by clausmuus on August 24, 2026, 11:11:21 »

Es hätte auch ein Snapshot existieren müssen, das vor Deinem wechsel auf den älteren Stand erstellt werden sollte.
Da ich im Moment keine Idee habe, warum bei dir das automatische erstellen der Snapshots nicht zuverlässig funktioniert, empfehle ich erst mal manuelle Snapshots zu erstellen, bevor Du größere Änderungen vornimmst.

Eventuell hilft es, wenn Du beim herunterfahren einmal die ESC Taste drückst. Dann sollten alle Logmeldungen angezeigt werden, und auch, auf welche Prozesse gewartet wird. Alternativ kannst Du beim Booten den Verbose Modus auswählen, das wirkt sich auch auf das herunterfahren aus.
Es kann Durchaus sein, dass ein VDR Plugin das Herunterfahren des Systems verlangsamt. Dies tritt z.B. auf, wenn dies sehr ausgiebige stop Aktionen durchführt, oder das Beenden des VDRs komplett blockiert. Allerdings würde ich so was eher beim EPG-Daemon vermuten, als beim vaapi Plugin.

35

Allgemein [ General ] / Neuinstallation

« Last post by purzel on August 24, 2026, 09:24:57 »

Moin!

Das mit den Snapshots versuche ich weiter zu beobachten - vielleicht ergibt es sich wieder.

"Es geht schon los". Meiner Meinung nach müsste doch eigentlich ein Snapshot da sein von der deinstallation von vdr-plugin-softhddevice-intel gestern Vormittag - ist aber nicht; siehe Screenshot.

Ich würde nämlich gerne noch einmal zu softdevice zurück um zu sehen ob das die Zeit des Herunterfahrens beeinflusst...

... noch beobachten muss: entweder seit ich das vaapi Plugin nutze oder seit dem ersten (Test-)Timer habe ich den Eindruck, dass er deutlich länger zum 'runterfahren braucht. ...

... im Moment braucht er ~100 Sekunden (!) zum Herunterfahren. Links oben sind währenddessen drei Punkte auf dem Bildschirm. Was macht der da so lange? (Wenn meine Erinnerung nicht total daneben liegt ging das vorige Woche deutlich schnellerer)

Apropos 'runterfahren: wo und wie binde ich in der 6.x ein Shellscript ein, welches beim Herunterfahren ausgeführt werden soll?

36

Allgemein [ General ] / Bild erst nach VDR Restart

« Last post by gustavgans on August 23, 2026, 23:34:53 »

Hmmm...,

der RPi ist ja nun schon etwas speziell. Ich hab zwar nen NVMe-HAT, aber keine SSD dran (sind mir momentan einfach zu teuer), deshalb die USB-SSD (vom Vorgänger Recorder, der ein richtiges Mistdings war, übrig geblieben) genommen. Ich hab also keine Ahnung, ob auch das Mounten der NVMe-SSD irgend welchen Ärger macht.

Bootzeitbedarf hat wohl AUCH was mit ggfs. laufender Dateisystemprüfung zu tun, die je nach Dateisystem mal länger oder mal kürzer dauert. clausmuus empfiehlt dringend, /data in XFS zu formatieren, ich bin dieser Empfehlung gefolgt. Am Einfachsten geht das, indem man im WebIF (Einstellungen/Speichermedien) die SSD beim Hinzufügen neu formatieren lässt - die MLD verwendet dabei XFS.

Hier mal meine fstab, vll. möchtest du mal auf Verdacht einen möglichen bind raus nehmen. Mein RPi5 bootet in knapp einer Minute, das ist inklusive RPi-Preboot-Screens. Laut clausmuus kann man, während des Hochlaufs, sofern man eine Tastatur angeschlossen hat, mit <ESC> zwischen dem MLD-Logo und dem Bootlog umschalten. Bei mir funktioniert das aber nicht, da ich (natürlich) eine Uralt-PS/2-Tastatur über ein USB-Wandlerdings verwende. Das wird erst enumeriert nachdem alles schon vorbei ist. Nachträglich kann man ja im WebIF ("Meldungen" oder im "Terminal" 'dmesg') ebenfalls das Bootlog prüfen.

Ich habe:
- die MLD auf SD-Karte UUID=C272-F76A
- Aufnahmen (/data) auf USB-SSD 500GB UUID=b124a09...
Die auskommentierten Zeilen ('#') sind paar Experimente gewesen, außerdem die Original Version mit bind.

Der Gewinner war am Ende das Entfernen des bind und die Verwendung von nofail. Das noatime ist ja Standard und mMn auch vernünftig.

/dev/root            /                    auto       noatime              1  1
proc                 /proc                proc       defaults              0  0
devpts               /dev/pts             devpts     mode=0620,ptmxmode=0666,gid=5      0  0
tmpfs                /run                 tmpfs      mode=0755,nodev,nosuid,strictatime 0  0
tmpfs                /var/volatile        tmpfs      defaults              0  0

# uncomment this if your device has a SD/MMC/Transflash slot
#/dev/mmcblk0p1       /media/card          auto       defaults,sync,noauto  0  0

UUID=C272-F76A /boot auto noatime 1 201

UUID=b124a098-f5f6-4c16-aab4-9b619a1a5d44 /data auto defaults,nofail,noatime 1 2
# UUID=b124a098-f5f6-4c16-aab4-9b619a1a5d44 /data  auto  defaults,nofail,x-systemd.automount,x-systemd.idle-timeout=10min  0  0
# UUID=b124a098-f5f6-4c16-aab4-9b619a1a5d44 /mnt/b124a098-f5f6-4c16-aab4-9b619a1a5d44 auto noatime 1 2
# /mnt/b124a098-f5f6-4c16-aab4-9b619a1a5d44 /data none bind 0 0
# last line (to make sure we don't accidently delete linefeed in previous line...)

Aber ich bin am Ende auch nur Anwender und kann nicht allzu tief reinsehen...

37

Allgemein [ General ] / Bild erst nach VDR Restart

« Last post by rkp on August 23, 2026, 22:52:10 »

Danke für deinen Hinweis.

In der ld.so.preload ist die Zeile '/opt/lib/libmediaclient.so aber enthalten. Das dürfte es wohl nicht sein.

Komisch ist: Gelegentlich funktioniert es nach dem Start sofort.

Das verhält sich bei meiner Fernbedienung RP2040 ähnlich. Manchmal funktioniert sie nach dem Start von MLD sofort, manchmal nicht.

Habe MLD schon dreimal neu installiert, immer das gleiche.

Ach, noch eine Kleinigkeit: Ein Reboot dauert bei mir immer ca. 70 Sekunden, man hat dann nur einen schwarzen Schirn mit MDL Logo, und bis MLD dann wieder startet vergehen nochmal so ca. Sekunden. Ich verwende ein NVme. Das kommt mir auch recht komisch vor. Libre*VDR benötigt nur Sekunden.

38

Allgemein [ General ] / Bild erst nach VDR Restart

« Last post by gustavgans on August 23, 2026, 22:22:26 »

Ich bin nicht sicher, ob in den Install-Skripten der MLD6.5 inzwischen eine Änderung eingebaut wurde, die im Zusammenhang mit dem Sundtek-Treiber vor ein paar Wochen aufkam. Ich hatte Probleme mit dem Bootvorgang des RPi5 und es zeigte sich, dass das UNTER ANDEREM mit dem preload des Sundtek-Treibers zusammenhing.

Ganz kurz die Geschichte: USB-SSD am RPi5 wird nicht gemountet und RPi5 landet in der EmergencyShell. Muss irgend was mit der speziellen Architektur der RPi5-USB Hardware zu tun haben. Ich konnte das lösen, indem ich in der /etc/fstab die SSD direkt gemountet habe und nicht, wie es MLD-Standard ist, über bind. Es wäre wohl ebenfalls dadurch lösbar gewesen, dass man den preload des Sundtek-Treibers entfernt. Obwohl mir das empfohlen wurde, habe ich es NICHT gemacht (aus der Datei /etc/ld.so.preload die Zeile '/usr/lib/libmediaclient.so' entfernen).

Falls nun in der MLD der preload raus genommen wurde, habe ich das nicht mehr "mitbekommen", denn ich habe seither ja nicht erneut installiert. Soweit ich mich erinnere WOLLTE clausmuus den preload raus nehmen und den bind drin lassen, weil der bind einige andere mögliche Probleme adressiert. Ich könnte mir nun vorstellen, dass MEIN RPi5 tadellos startet und läuft, aber DEINER nicht, weil wir an genau dieser Stelle unterschiedliche Setups haben.

ALSO: Bitte mal in deinem RPi5 schauen, wie es eingerichtet ist cat /etc/fstab und cat etc/ld.so.preload. Falls in deiner preload die besagte Zeile NICHT drin steht, schreibe sie bitte mal rein und schau nach ob dann das Bild nach dem Hochfahren sofort kommt.

OBACHT: Solltest du deine Aufnahmen auf einer USB-SSD oder -HDD speichern, dann musst du vermutlich in deiner /etc/fstab den mount für /data ohne bind machen. Keine Ahnung wie das geht? Dann nochmal melden oder erstmal den zweistufigen mount deiner USB-SSD/HDD aus der fstab rauskommentieren, so dass KEIN /data gemountet wird. Wenn du deine Daten jedoch mittels NVMe-SSD über den PCIe-SSD-HAT angebunden hast, sollte keine Anpassung der fstab erforderlich sein.

Sollte danach das Bild im VDR gleich kommen haben wir vermutlich etwas gelernt: Der Preload scheint notwendig zu sein, denn mein RPi5 (MIT preload) rennt ebenfalls sofort nach dem Hochfahren. VDR startet, schaltet sich auf den Sundtek, dann gehen am Sundtek-Empfänger die beiden blauen LEDs an und 2sec später sind Bild und Ton da.

39

Allgemein [ General ] / Bild erst nach VDR Restart

« Last post by rkp on August 23, 2026, 22:21:42 »

Nachtrag: Nach der Installation der Sundtek Treiber läuft ein sundtek.service:

[Unit]
Description=Sundtek MediaTV
Wants=graphical.target

[Service]
Type=oneshot
ExecStart=/usr/bin/mediaclient --start=4 --serverpath=/usr/bin --pluginpath=/usr/lib/sundte
ExecStop=/usr/bin/mediaclient --shutdown
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target


In vdr.service habe ich mal

[Unit]
Description=Video Disk Recorder
Requires=sundtek.service
After=webif.service sundtek.service

eingetragen. Hat aber nicht geholfen.

40

Allgemein [ General ] / Bild erst nach VDR Restart

« Last post by rkp on August 23, 2026, 19:57:31 »

Hallo Klaus,

ich hatte eine ähnliches Problem bei Libre*VDR. Die Lösung war folgender Beitrag:

"Allerdings ist der VDR beim Booten zu schnell gestartet, nämlich bevor die DVB Karte aktiviert war. Deshalb habe ich den systemd service vdropt.service darum ergänzt, dass der Treiber der Sundtek Karte required ist und vdropt erst nach dem Treiber geladen werden soll.
Das sieht dann so aus:

Code
[Unit]
Description=VDR Client
Requires=network-online.target graphical.target driver.dvb.sundtek-mediatv.service
After=network-online.target graphical.target driver.dvb.sundtek-mediatv.service

...


Jetzt suche ich bei MLD die geeignete Stelle, wo ich diesen Eintrag vornehmen kann. Kann du mir helfen?