106
Allgemein [ General ] / suspendoutput -> VDR Crash
« on: December 30, 2025, 16:02:55 »
Das ist ein rpi4 mit softhddevice-drm-gles.
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
107
Allgemein [ General ] / suspendoutput -> VDR Crash
« on: December 30, 2025, 15:32:14 »
Wenn ich das Plugin suspendoutput einbinde, schmiert der VDR beim Aktivieren des suspend reproduzierbar ab:
Bei VDR*ELEC schmiert das Plugin nicht ab, loggt aber analog Meldungen über "invalid PES packet".
Soweit ich das überblicke sind die Bilder in den Code einkompiliert (der Code scheint 8 Jahre alt zu sein).
Code: [Select]
Dec 30 15:23:12 MLD vdr[5158]: [5158] VDR version 2.7.7 started
Dec 30 15:23:04 MLD systemd[1]: Starting Video Disk Recorder...
Dec 30 15:23:04 MLD systemd[1]: vdr.service: Scheduled restart job, restart counter is at 2.
Dec 30 15:23:03 MLD systemd[1]: vdr.service: Consumed 44.506s CPU time.
Dec 30 15:23:03 MLD systemd[1]: vdr.service: Failed with result 'core-dump'.
Dec 30 15:23:03 MLD systemd[1]: vdr.service: Main process exited, code=dumped, status=11/SEGV
Dec 30 15:23:03 MLD kernel: audit: type=1701 audit(1767104583.706:46): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=4249 comm="vdr" exe="/usr/bin/vdr" sig=11 res=1
Dec 30 15:23:03 MLD vdr[4249]: [4249] [softhddevice] device: HandleStillPicture: invalid PES packet
Dec 30 15:23:03 MLD audit[4249]: ANOM_ABEND auid=4294967295 uid=0 gid=0 ses=4294967295 pid=4249 comm="vdr" exe="/usr/bin/vdr" sig=11 res=1
Dec 30 15:23:03 MLD vdr[4249]: [4249] skindesigner: Osd deleted.
Dec 30 15:23:03 MLD vdr[4249]: [4993] animator thread thread ended (pid=4249, tid=4993)
Dec 30 15:23:03 MLD vdr[4249]: [4249] suspendoutput: output suspended by userBei VDR*ELEC schmiert das Plugin nicht ab, loggt aber analog Meldungen über "invalid PES packet".
Soweit ich das überblicke sind die Bilder in den Code einkompiliert (der Code scheint 8 Jahre alt zu sein).
108
Allgemein [ General ] / Zapcockpit deaktvieren
« on: December 29, 2025, 15:56:41 »
Jetzt habe ich es auch geschnallt. Weil ich im VDR*ELEC eine Option Zapcokcpit an/aus gesehen habe, habe ich die Option auch in MLD gesucht.
109
Allgemein [ General ] / Zapcockpit deaktvieren
« on: December 28, 2025, 21:51:32 »
Die Einträge sehe ich auch, aber schalte ich es damit ab?
110
Allgemein [ General ] / Zapcockpit deaktvieren
« on: December 28, 2025, 17:19:09 »
Hm, es ist an (direkt nach der Installation RPI4 von heute Nacht) und unter VDR-Setup / Sonstiges ist keine Option um es abzuschalten - oder ich sehe den Wald vor lauter Bäumen nicht.
111
Allgemein [ General ] / Zapcockpit deaktvieren
« on: December 28, 2025, 15:30:19 »
Kann das Zapcockpit irgendwo deaktiviert werden?
Ich meine das müsste gehen, finde es aber irgendwie nicht.
Ich meine das müsste gehen, finde es aber irgendwie nicht.
112
Allgemein [ General ] / Raspberry Pi 5
« on: May 11, 2025, 10:12:42 »
Schneller Check nach der Meldung von neumann2k
Das Image vom 11.05. bootet (von der M.2),
Web-Interface ok, Bild ok, Konfiguration der Fernbedienung steht noch aus.
Ton aktuell nur bei den privaten (vermutlich Einstellungssache)
CPU konstant bei 50%
Das Image vom 11.05. bootet (von der M.2), Web-Interface ok, Bild ok, Konfiguration der Fernbedienung steht noch aus.
Ton aktuell nur bei den privaten (vermutlich Einstellungssache)
CPU konstant bei 50%
113
Allgemein [ General ] / Raspberry Pi 5
« on: May 04, 2025, 17:48:02 »
Ich wäre, im Rahmen meiner Möglichkeiten (kein Entwickler), auch dabei die MLD auf dem RPI5 flott zu machen.
114
Allgemein [ General ] / Raspberry Pi 5
« on: April 25, 2025, 18:44:50 »
Noe, Kernel Panic, zumindest mit dem Image vom 17. / 18.04. bei mir.
115
Hardware / PI5, Erste Eindrücke Argon ONE V3 M.2 Case
« on: December 04, 2024, 10:37:51 »
Das Gehäuse kommt zerlegt und selbstverständlich ohne den PI. Die Key Features sind für mich der SSD Steckplatz, der IR-Empfänger und die Lüftersteuerung.
Der Zusammenbau ist bewältigbar, auch wenn die Teile vereinzelt etwas schwer zusammen zu stecken sind, insbesondere den PI in das Gehäuse Board, aber auch das Stecken des HDMI-Power Boards an den PI. Vor der Montage des Flex Kabels vom PI zur NVME Platine habe ich mir ein YouTube Video angesehen, dann klappte auch das. Die Verarbeitung ist erfreulich, die Haptik stimmt und die GPIOs sind unter einer magnetisch gehaltenen Platte zugänglich.
Die notwendige Software habe ich unter Debian Bookworm installiert (MLD 6.5 unterstützt einige der benötigten Pakete nicht). Die SSD, der Power Button sowie die Lüftersteuerung funktionieren damit mehr oder weniger out of the box.
Das Gehäuse hat zwei Modi, die mit einem Jumper ausgewählt werden.
Im „Always on“ Modus liegt die Stromversorgung am PI dauerhaft an. Das ist ideal für 24/7 laufende Systeme wie einen VDR Server. Nach einem Stromausfall geht es ohne Interaktion am Power Button weiter. Das Einschalten durch den Power Button oder die Fernbedienung sind in diesem Modus nicht verfügbar. Wird das System mittels halt oder poweroff angehalten, dann leuchtet die Status LED des PI rot und man muss die Stromversorgung trennen (und einen Moment warten, bis alle Kondensatoren entladen sind und die Status LED aus geht).
Im „Normal“ Modus wird das Power Management vom Gehäuse übernommen und das System kann über den Power Button oder die Fernbedienung ein-/ausgeschaltet werden. Das ist ideal für interaktiv genutzte Systeme wie einen VDR Client. Der IR-Empfänger versteht zum Power On nur das NEC Protokoll. Meine alte TT S2-6400 Fernbedienung hat ein paar extra Tasten für das TV und eine integrierte Datenbank. Nach einigem ausprobieren hat der Gerätecode 0036 das gewünschte Verhalten erzeugt. Damit lässt sich der PI über die Fernbedienung einschalten. Es gibt eine zum Gehäuse passende Fernbedienung mit der das Einschalten vermutlich kein Problem ist. Ansonsten kann der IR-Empfänger mittels lirc auch mit anderen Fernbedienungen umgehen, nur lässt er sich damit nicht einschalten. In diesem Modus ist das RTC wakeup des PI nicht nutzbar – im ausgeschaltetem Zustand ist die Status LED des PI aus, das heißt in diesem Modus liegt am PI kein Strom an und deshalb kann er nicht starten.
Der Zusammenbau ist bewältigbar, auch wenn die Teile vereinzelt etwas schwer zusammen zu stecken sind, insbesondere den PI in das Gehäuse Board, aber auch das Stecken des HDMI-Power Boards an den PI. Vor der Montage des Flex Kabels vom PI zur NVME Platine habe ich mir ein YouTube Video angesehen, dann klappte auch das. Die Verarbeitung ist erfreulich, die Haptik stimmt und die GPIOs sind unter einer magnetisch gehaltenen Platte zugänglich.
Die notwendige Software habe ich unter Debian Bookworm installiert (MLD 6.5 unterstützt einige der benötigten Pakete nicht). Die SSD, der Power Button sowie die Lüftersteuerung funktionieren damit mehr oder weniger out of the box.
Das Gehäuse hat zwei Modi, die mit einem Jumper ausgewählt werden.
Im „Always on“ Modus liegt die Stromversorgung am PI dauerhaft an. Das ist ideal für 24/7 laufende Systeme wie einen VDR Server. Nach einem Stromausfall geht es ohne Interaktion am Power Button weiter. Das Einschalten durch den Power Button oder die Fernbedienung sind in diesem Modus nicht verfügbar. Wird das System mittels halt oder poweroff angehalten, dann leuchtet die Status LED des PI rot und man muss die Stromversorgung trennen (und einen Moment warten, bis alle Kondensatoren entladen sind und die Status LED aus geht).
Im „Normal“ Modus wird das Power Management vom Gehäuse übernommen und das System kann über den Power Button oder die Fernbedienung ein-/ausgeschaltet werden. Das ist ideal für interaktiv genutzte Systeme wie einen VDR Client. Der IR-Empfänger versteht zum Power On nur das NEC Protokoll. Meine alte TT S2-6400 Fernbedienung hat ein paar extra Tasten für das TV und eine integrierte Datenbank. Nach einigem ausprobieren hat der Gerätecode 0036 das gewünschte Verhalten erzeugt. Damit lässt sich der PI über die Fernbedienung einschalten. Es gibt eine zum Gehäuse passende Fernbedienung mit der das Einschalten vermutlich kein Problem ist. Ansonsten kann der IR-Empfänger mittels lirc auch mit anderen Fernbedienungen umgehen, nur lässt er sich damit nicht einschalten. In diesem Modus ist das RTC wakeup des PI nicht nutzbar – im ausgeschaltetem Zustand ist die Status LED des PI aus, das heißt in diesem Modus liegt am PI kein Strom an und deshalb kann er nicht starten.
116
Allgemein [ General ] / PI5, MLD 6.5, Paket Request rpi-eeprom-config
« on: December 02, 2024, 18:08:13 »
Mit "BOOT_ORDER kann die Reihenfolge festgelegt werden.
Das ist ein 32 Bit Wert mit folgenden (hier wichtigen Werten)
0x1: SD CARD
0x4: USB-MSD
0x6: NVME
0xf: RESTART
Der Wert wird von rechts nach links interpretiert.
Bei mir ist "BOOT_ORDER=0xf641" gesetzt, was heißt erst SD Card, dann USB-MSD und zuletzt NVME.
Außerdem ist noch "USB_MSD_DISCOVER_TIMEOUT=500" gesetzt, um die Wartezeit auf den USB-MSD zu verkürzen und den Boot-Prozess zu beschleunigen. Der Default ist 20000 und heißt, dass 20 Sekunden gewartet wird.
Mit "rpi-eeprom-config --edit" kann man die Parameter ändern (das Programm gibt es auch für den RPI4).
Wenn man das mit "-h" aufruft, bekommt man Infos, wie das tickt - eine Integration in das Webif müsste nach meiner Einschätzung mit den Infos dort machbar sein.
[Nachtrag:]
Dann sind bei mir noch gesetzt:
DTPARAM=PCIEX1_GEN=3
PCIE_PROBE=1
Ohne die sieht der PI die NVME beim Starten von einem non-HAT+ device nicht. Der dtparam Eintrag setzt aber nur die Geschwindigkeit auf Gen 3.0 speed - dafür ist der PI laut Doku aber nicht spezifiziert, deshalb die extra Aktivierung, Default ist Gen 2.0 Speed.
Das ist ein 32 Bit Wert mit folgenden (hier wichtigen Werten)
0x1: SD CARD
0x4: USB-MSD
0x6: NVME
0xf: RESTART
Der Wert wird von rechts nach links interpretiert.
Bei mir ist "BOOT_ORDER=0xf641" gesetzt, was heißt erst SD Card, dann USB-MSD und zuletzt NVME.
Außerdem ist noch "USB_MSD_DISCOVER_TIMEOUT=500" gesetzt, um die Wartezeit auf den USB-MSD zu verkürzen und den Boot-Prozess zu beschleunigen. Der Default ist 20000 und heißt, dass 20 Sekunden gewartet wird.
Mit "rpi-eeprom-config --edit" kann man die Parameter ändern (das Programm gibt es auch für den RPI4).
Wenn man das mit "-h" aufruft, bekommt man Infos, wie das tickt - eine Integration in das Webif müsste nach meiner Einschätzung mit den Infos dort machbar sein.
[Nachtrag:]
Dann sind bei mir noch gesetzt:
DTPARAM=PCIEX1_GEN=3
PCIE_PROBE=1
Ohne die sieht der PI die NVME beim Starten von einem non-HAT+ device nicht. Der dtparam Eintrag setzt aber nur die Geschwindigkeit auf Gen 3.0 speed - dafür ist der PI laut Doku aber nicht spezifiziert, deshalb die extra Aktivierung, Default ist Gen 2.0 Speed.
117
Allgemein [ General ] / PI5, MLD 6.5, kein Audiodevice
« on: December 02, 2024, 10:13:27 »
Ok, das es (noch) nicht funktioniert kann ich bestätigen.
Wenn ich helfen/unterstützen kann - gerne.
Wenn ich helfen/unterstützen kann - gerne.
118
Allgemein [ General ] / PI5, MLD 6.5, Paket Request rpi-eeprom-config
« on: December 02, 2024, 10:11:45 »
Die Konfiguration der Gehäusefunktionen und die Bootreihenfolge für die SSD werden damit gesetzt.
Das ist zwar persistent und kann von einem funktionierendem raspios gemacht werden, aber da muss man halt immer Booten um irgendetwas zu ändern. Ich meine beim RPI4 wäre das Paket verfügbar gewesen - sonst hätte ich nicht danach gefragt.
ja beim rpi4 hatte ich es aufgenommen,
muß dann wenn es funktioniert nur für den rpi5 auch angeboten werden.
Gruß,
Roland
Das ist zwar persistent und kann von einem funktionierendem raspios gemacht werden, aber da muss man halt immer Booten um irgendetwas zu ändern. Ich meine beim RPI4 wäre das Paket verfügbar gewesen - sonst hätte ich nicht danach gefragt.
ja beim rpi4 hatte ich es aufgenommen,
muß dann wenn es funktioniert nur für den rpi5 auch angeboten werden.
Gruß,
Roland
119
Allgemein [ General ] / PI5, MLD 6.5, Paket Request rpi-eeprom-config
« on: December 02, 2024, 07:47:33 »
Hallo Claus,
ja, das Paket passt - danke.
Stefan
ja, das Paket passt - danke.
Stefan
120
Allgemein [ General ] / PI5, MLD 6.5, kein Audiodevice
« on: December 01, 2024, 13:49:07 »
Hallo,
der VDR startet nicht (weil kein Audiodevice vorhanden ist?):
Ob der Abbruch wirklich durch das fehlende Sounddevice verursacht wird - keine Ahnung.
Das fehlende Audiodevice ist wohl kein Problem der Konfiguration des VDR, sondern des OS:
der VDR startet nicht (weil kein Audiodevice vorhanden ist?):
Dec 01 13:33:47 MLD vdr[1009]: [1009] [softhddevice] audio/alsa: using device 'default'
Dec 01 13:33:47 MLD vdr[1009]: [1009] [softhddevice] audio: AlsaOpenPCM: playback open 'default' error: No such file or directory
Dec 01 13:34:16 MLD run.sh[780]: /usr/share/vdr/run.d/50_vdr.sh: Zeile 3: 1009 Aborted (Speicherabzug geschrieben) vdr > /dev/tty5 < /dev/tty5
Dec 01 13:34:16 MLD systemd[1]: vdr.service: Deactivated successfully.
Dec 01 13:34:16 MLD systemd[1]: Started Video Disk Recorder.
Dec 01 13:43:12 MLD systemd[1]: Starting Video Disk Recorder...
Dec 01 13:43:15 MLD vdr[2547]: [2547] VDR version 2.7.3 started
...
Ob der Abbruch wirklich durch das fehlende Sounddevice verursacht wird - keine Ahnung.
Das fehlende Audiodevice ist wohl kein Problem der Konfiguration des VDR, sondern des OS:
root@MLD:~# aplay -l
aplay: device_list:279: keine Soundkarten gefunden ...