[Bug 788088] New: NotInitialized should not be raised if Gst already initialized by C

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=788088

            Bug ID: 788088
           Summary: NotInitialized should not be raised if Gst already
                    initialized by C
    Classification: Platform
           Product: GStreamer
           Version: git master
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gst-python
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: bmerry at gmail.com
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

I develop a plugin for Rhythmbox. Rhythmbox uses Gst from C, but also embeds a
Python interpreter to allow plugins to be written. The plugin does not call
Gst.init, because Rhythmbox already initializes it at the C level - I can check
that by calling Gst.is_initialized from the plugin with Gst 1.0.

Commit
https://phabricator.freedesktop.org/rGSTPYTHON6b32ccbbb250f7516f36a1ea82c0fbba8925af09
in gst-python 1.5.2 breaks the plugin (bug report from a user:
https://github.com/bmerry/rbtempo/issues/2). It's easy enough to work around by
initialising Gst again (fortunately Gst seems to protect against double-init),
but I still consider it to be a bug in gst-python that it raises NotInitialized
when Gst has been initialised.

I suggest that at minimum, the deinit_pygst at the bottom of Gst.py should be
made conditional on a check of is_initialized. A more robust approach that
would allow for an out-of-band (C-level) init after gst-python is loaded would
be to generate a separate fake function for each real function that would first
check is_initialized, and if true would put the real functions in place and
transparently forward to the real function.

I've filed this against git master because the code on master looks like it
will still do the same thing, although I haven't actually tried installing it.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.