Closed matthijskooijman closed 4 years ago
Here is the backtrace I promised:
ERROR:root:OMXPlayer failed to start
Traceback (most recent call last):
File "/home/pi/player.py", line 196, in start_player
self.player = omxplayer.OMXPlayer(source, args)
File "/usr/local/lib/python3.7/dist-packages/omxplayer/player.py", line 154, in __init__
self.load(source, pause=pause)
File "/usr/local/lib/python3.7/dist-packages/omxplayer/player.py", line 237, in load
self._load_source(source)
File "/usr/local/lib/python3.7/dist-packages/omxplayer/player.py", line 163, in _load_source
self._connection = self._setup_dbus_connection(self._Connection, self._bus_address_finder)
File "/usr/local/lib/python3.7/dist-packages/omxplayer/player.py", line 214, in _setup_dbus_connection
connection = Connection(bus_address_finder.get_address(), self._dbus_name)
File "/usr/local/lib/python3.7/dist-packages/omxplayer/dbus_connection.py", line 24, in __init__
self._bus = dbus.bus.BusConnection(bus_address)
File "/usr/local/lib/python3.7/dist-packages/dbus/bus.py", line 124, in __new__
bus = cls._new_for_bus(address_or_type, mainloop=mainloop)
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
When there is a problem with the DBUS connection, an omxplayer might end up running in the background without any way to kill it (other than something like
killall omxplayer
.I've seen this problem on a Rpi 1 and some specific movie, possibly because the rpi 1 is a bit slower. In any case, there is a problem connecting to omxplayer through dbus (I'll add a backtrace later, I do not have it handy her), but the connection failure is not the subject of this issue.
What happens when the dbus connection fails, is that the constructor raises an exception and now instance is created. However, the code does not kill the started omxplayer process in this case, so there is still a background omxplayer running. But since there is no player instance created, the caller can catch the exception, but then has no way to kill the player.
In general, I think that the constructor should either:
Alternatively, creating the omxplayer instance and starting omxplayer could be split up (e.g. like suggested in #161), so the constructor never throws. Then the
load()
method (or whatever starts the player) could throw, and the caller still has a player instance to callquit()
on to clean up (Though it might still make sense to always either start completely succesfully or clean up).