python-omxplayer-wrapper icon indicating copy to clipboard operation
python-omxplayer-wrapper copied to clipboard

Allocate a new dbus_name for each new player instance

Open willprice opened this issue 6 years ago • 4 comments

Use a UUID for the dbus_name and ditch the bus_finder

willprice avatar Sep 26 '17 21:09 willprice

I've also seen that omxplayer-wrapper can end up using /tmp/omxplayerdbus.* files from another user, since there is no filter on that. Implementing this enhancement would also fix that.

matthijskooijman avatar Oct 12 '19 17:10 matthijskooijman

I just tried to implement something like this (for now by passing a custom Connection object, but the end result should be the same), and I had a bit of trouble with this. I'm not sure I entirely understand, but it seems that in addition to the dbus_name, we also need the actual socket path to connect to the dbus daemon (which does not seem to be the default session or system bus, switching to dbus.SessionBus() complained that no session bus could be autostarted). I'm also not quite sure who actually starts the dbus-daemon that omxplayer connects to... Things might have been complicated by running as root, though.

Did you have any thoughts about this already?

matthijskooijman avatar Feb 20 '20 21:02 matthijskooijman

Just had a look in the omxplayer source, it seems it connects to the session bus (OMXControl::dbus_connect in OMXControl.cpp). I tried that one, which did not work, but maybe I did something wrong (or maybe the session bus was not running before omxplayer was started, dunno). I might try a bit harder (but my test setup has moved elsewhere now...).

matthijskooijman avatar Feb 20 '20 22:02 matthijskooijman

Tried again just now, using dbus.SessionBus() from python fails to connect to DBUS:

bus.exceptions.DBusException: org.freedesktop.DBus.Error.NotSupported: Unable to autolaunch a dbus-daemon without

a $DISPLAY for X11

Looking more closely, it turns out that omxplayer does not actually use the normal session bus, but insists on starting its own dbus server (and tracks its address in the /tmp/omxplayerdbus.${user} variable to reuse it on subsequent player calls). It then overrides the DBUS_SESSION_BUS_ADDRESS environment variable, which makes dbus use this private dbus server as the session bus. See https://github.com/popcornmix/omxplayer/blob/ecd446d2de7eb86a43acaae59807a8e5c173f80d/omxplayer#L46-L65

I guess this means that we cannot really drop the finder, since we'll need to figure out the dbus server address used by omxplayer (unless omxplayer would use the pre-existing one, see https://github.com/popcornmix/omxplayer/issues/255, or unless we would run omxplayer.bin directly and bypass this stuff).

matthijskooijman avatar Feb 21 '20 12:02 matthijskooijman