Plugin crashes when another VDR process with the plugin is still running

[fwolter]

Here

vdr-plugin-softhddevice-drm-gles/videorender.cpp

Line 2056 in 307dc4e

LOGFATAL("videorender: %s: cannot set atomic mode (%d): %m", __FUNCTION__, errno);

[rellla]

I would have expected that. Implementing the detach/attach feature would make it possible to start one of the plugin instances in detached mode without display/decoder.
But afaik only one can have control over display anyway.

[fwolter]

Implementing this might open the opportunity to do integration tests in CI (pushing sample PES packets into PlayVideo()). I think for now an appropriate error message would be sufficient.

[rellla]

https://github.com/rellla/vdr-plugin-softhddevice-drm-gles/tree/WIP/suspendV02
Still not finished. I think of creating such flow graphs for plugin startup and shutdown before...

[fwolter]

And it does not end the init when this fails, leading to a crash

vdr-plugin-softhddevice-drm-gles/drmdevice.cpp

Line 144 in 966657b

LOGERROR("drmdevice: %s: drmGetDevices2 failed: %s", __FUNCTION__, strerror(-num_devices));

This fails if dtoverlay=vc4-fkms-v3d is not set.

2025-11-06T09:48:10.273025+0100 raspberrypi vdr[4686]: [4686] [softhddevice] drmdevice: FindDrmDevice: drmGetDevices2 failed: No such file or directory
2025-11-06T09:48:10.273073+0100 raspberrypi vdr[4686]: [4686] [softhddevice] drmdevice: Init: Could not open device!
2025-11-06T09:48:10.273108+0100 raspberrypi vdr[4686]: [4686] [softhddevice] videorender: Init: failed

[rellla]

According to the readme, dtoverlay should be vc4-mks-v3d anyway!?

[fwolter]

Yes, it was a mistake on my side. But the plugin should not crash in this case.

[rellla]

Yes, probably. But what is the usecase of softhddevice without displaying anything?

[fwolter]

The point is an application must not crash, regardless how dumb the user is :)

[rellla]

Maybe we simply can try to always set detached state if sth with init went wrong?

[fwolter]

Makes sense, now that we have that ability!

[rellla]

needs testing, but maybe #269 could fix this