Beiträge von blau-sls

Auf einem aktuellen RaspiOs hab ich auch mit einem selbst generierten Kernel 5.10.35 Ton über HDMI.

Wahrscheinlich hilft es Dir nicht weiter, aber bis einschließlich 5.10.23 hatte ich mit folgender Vorgehensweise und den oben schon erwähnten vc4-hdmi.conf und /boot/config.txt Ton über HDMI:

#Als User pi
mkdir -p ~/Src
cd ~/Src
git clone --depth=1 --branch rpi-5.10.y https://github.com/raspberrypi/linux
cd linux
KERNEL=kernel7l
make bcm2711_defconfig

make -j4 zImage modules headers dtbs
sudo make modules_install
sudo make headers_install INSTALL_HDR_PATH=/usr
sudo cp arch/arm/boot/dts/*.dtb /boot/
sudo cp arch/arm/boot/dts/overlays/*.dtb* /boot/overlays/
sudo cp arch/arm/boot/zImage /boot/$KERNEL.img

Irgendwann lief's dann direkt mit dem von RaspOS ausgelieferten Kernel, sodass das Bauen eines eigenen Kernels für mich nicht mehr notwendig war.

Ich hab Ton über HDMI bei softhddevice-drm mit dem aktuellen 5.10'er kernel von raspbian ohne jegliche Modifikationen und folgender /boot/config.txt:

#gpu_mem=256

hdmi_force_hotplug=1
hdmi_edid_file=1

hdmi_group=1
hdmi_mode=31

# Doesn't sent initial active source message.
# Avoids bringing CEC (enabled TV) out of standby and channel switch when
# rebooting.
hdmi_ignore_cec_init=1

# Uncomment this to enable infrared communication.
#dtoverlay=gpio-ir,gpio_pin=17
dtoverlay=gpio-ir,rc-map-name=rc-hauppauge,gpio_pin=18

#dtparam=audio=on

dtoverlay=vc4-kms-v3d-pi4,cma-384
dtoverlay=rpivid-v4l2
disable_overscan=1
disable_fw_kms_setup=1

Wenn ich mich recht erinnere, war das entscheidende die geänderte /usr/share/alsa/cards/vc4-hdmi.conf.

So wie das z.B. nafets227's Skript aus diesem Thread macht.

Freut mich sehr, dass ich auch mal was beitragen konnte.

Gruß
Rainer

Zitat von Ein Eike

Da will etwas einen Systemaufruf absetzen und das gelingt nicht.
Wenn du an der Stelle das Kommando ausgeben würdest (wäre wohl auch eine sinnvolle VDR-Änderung), könnte man mehr erfahren:

Code

dsyslog("%s", Command);

... vor dem LOG_ERROR sollte das tun.

Und ich sach' schon mal: Permashift ist unschuldig! :o)

Hallo Eike,

zunächst mal vielen Dank für Dein tolles Plugin! Ist bei uns seit einigen Monaten im täglichen Einsatz und wir möchten es nicht mehr missen.

Allerdings hatte ich in der Vergangenheit auch öfter Mal das Problem, dass sich der VDR wegen Speichermangel nicht mehr ausschalten ließ. Diese Woche hab ich die Ursache herausgefunden und muss Dir leider mitteilen, dass - zumindest bei mir - da doch ein Fehler in Permashift die Ursache war.

Da ich keine Signatur habe: Ich benutze ein 32-Bit Ubuntu-Precise und baue meinen VDR aus den yavdr-Quellpaketen selbst. Darin eingebaut habe ich Dein Permashift-1.0.0. Mein System hat 3 DVB-Receiver.

Der Fehler passiert bei mir folgendermaßen:

• Ich schaue Live. Dabei benutzt VDR device 3 und im receiver thread ist ein Ringbuffer eingehängt, auf den m_bufferReceiver zeigt.
• Dann benutze ich permashift, um live zurückzuspoolen, und gehe irgendwann aus dem Abspielen dieser Aufnahme wieder raus, ohne die Aufnahme zu beenden
• Wenn ich anschließend, während die Aufnahme noch läuft, live auf ein Programm auf einem anderen Transponder schalte, startet VDR einen receiver thread auf device 1 (device 3 braucht er ja für die Aufnahme) und permashift legt einen neuen Ringbuffer an, auf den m_bufferReceiver zeigt.
• Irgendwann endet die oben gestartete Aufnahme. Dabei ruft das darin eingehängte bufferReceiver-Objekt die Funktion BufferDeleted auf.
• Damit wird m_bufferReceiver auf NULL gesetzt. Und das ist falsch, denn m_bufferReciever ist ja inzwischen eigentlich für den Ringbuffer in device 1 zuständig
• Schalte ich nun wieder auf einen anderen Transponder, benutzt VDR wieder einen receiver thread auf device 3 und würde normalerweise den receiver thread für device 1 beenden.
• Da jedoch m_bufferReceiver auf NULL gesetzt wurde, wird der Ringbuffer für device 1 nicht angehalten und deshalb beendet sich der receiver thread auf device 1 auch nicht.

Langer Rede kurzer Sinn: BufferDeleted darf m_bufferReceiver nur dann auf NULL setzen, wenn die Funktion von dem Objekt aufgerufen wurde, auf die m_bufferReceiver auch zeigt. Das kann man mit folgendem kleinen Patch erreichen:

diff -rupN permashift-1.0.0.org/bufferreceiver.c permashift-1.0.0/bufferreceiver.c
--- permashift-1.0.0.org/bufferreceiver.c   	2014-07-30 13:48:39.000000000 +0200
+++ permashift-1.0.0/bufferreceiver.c   2015-04-25 12:37:42.000000000 +0200
@@ -38,7 +38,7 @@ cBufferReceiver::~cBufferReceiver()


    	if (m_owner != NULL)
    	{
-           	m_owner->BufferDeleted();
+           	m_owner->BufferDeleted(this);
    	}
    	if (m_bufferWriter != NULL)
    	{
diff -rupN permashift-1.0.0.org/permashift.c permashift-1.0.0/permashift.c
--- permashift-1.0.0.org/permashift.c   2014-08-16 13:25:00.000000000 +0200
+++ permashift-1.0.0/permashift.c   	2015-04-25 12:47:39.000000000 +0200
@@ -170,10 +170,13 @@ bool cPluginPermashift::StopLiveRecordin
    	return true;
 }


-void cPluginPermashift::BufferDeleted()
+void cPluginPermashift::BufferDeleted(cBufferReceiver* callingReceiver)
 {
    	// our buffer is about to be deleted by other means
-   	m_bufferReceiver = NULL;
+   	if (m_bufferReceiver == callingReceiver)
+   	{
+           	m_bufferReceiver = NULL;
+   	}
 }


 cMenuSetupPage *cPluginPermashift::SetupMenu(void)
diff -rupN permashift-1.0.0.org/permashift.h permashift-1.0.0/permashift.h
--- permashift-1.0.0.org/permashift.h   2014-05-24 17:44:06.000000000 +0200
+++ permashift-1.0.0/permashift.h   	2015-04-25 12:35:41.000000000 +0200
@@ -75,7 +75,7 @@ public:
    	bool StopLiveRecording(void);


    	/// our buffer tells us that it's gone
-   	void BufferDeleted();
+   	void BufferDeleted(cBufferReceiver* callingReceiver);


    	/// status callback
    	void ChannelSwitch(const cDevice *device, int channelNumber, bool liveView);

Damit läufts bei mir nun seit 3 Tagen intensiven Testens, ohne dass nochmal Speichermangel gemeldet wurde.

Gruß
Rainer