search

willprice / python-omxplayer-wrapper

:tv: Control OMXPlayer, the Raspberry Pi media player, from Python
http://python-omxplayer-wrapper.readthedocs.io
GNU Lesser General Public License v3.0
253 stars 71 forks source link

Allocate a new dbus_name for each new player instance #107

Open willprice opened 7 years ago

willprice commented 7 years ago

Use a UUID for the dbus_name and ditch the bus_finder

matthijskooijman commented 5 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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).