[gst-devel] Possible gstreamer errors: volume, dispose, loop detected - oh my!

[Ryan Kelln]

Thanks for the info Stefan, most helpful. Some comments below.

Stefan Kost wrote:
> Ryan Kelln schrieb:
>> ** (GSVideo:9501): CRITICAL **: volume_transform_ip: assertion
>> `this->process != NULL' failed
> This means that the volume element is not configured. I use volume a
> lot and have never seen it. Could it be that the java bindungs
> handling something different here.
>
Yup, I'll take a look  at the java that is between me and gstreamer,
however on my end I don't every delete any sounds once they are around.
They are started and stopped, seeked, panned and volume changed, but I
don't see why the volume element would ever become unconfigured from any
of those actions.

If I slow down the rate at which the volume is checked and never
start/stop the sounds then this is the only error I get and it
drastically slows the crash (I've not seen it in 8+ hours of continuous
running).

Hmm, here is the gstreamer-java code between me and gstreamer. It seems
simple enough, unless there is a bug in the jna library stuff that this
relies on:

public void setVolume(double volume) {
        gobj.g_object_set(this, "volume", volume);
}

public double getVolume() {
        double[] volume = { 0d };
        gobj.g_object_get(this, "volume", volume);
        return volume[0];
}

public interface GObjectAPI extends Library {
    static GObjectAPI gobj = GNative.loadLibrary("gobject-2.0",
GObjectAPI.class, new HashMap<String, Object>() {{
        put(Library.OPTION_TYPE_MAPPER, new GTypeMapper());
    }});
    ...
    void g_object_set(GObject obj, String propertyName, Object... data);
    void g_object_get(GObject obj, String propertyName, Object... data);

See anything wrong with that?

>> (GSVideo:9501): GStreamer-CRITICAL **:
>> Trying to dispose element test, but it is not in the NULL state.
>> You need to explicitly set elements to the NULL state before
>> dropping the final reference, to allow them to clean up.
> Do you set your pipeline to NULL state before releasing it. Dunnon how
> much this is abstracted by java-bindings again.
The problem I'm having tracking this down is one in is making an element
called "test" specifically in any of the code. A grep or search of the
code turns up nothing interesting for "test". And as I stated I'm not
disposing any elements (until the software exits), unless the sounds or
some element of the sounds is being disposed when stopped.... hmm, nope,
that isn't the case.

A question about your statement. Are you saying that before you call
dispose() you need to stop the pipeline (set the state to NULL)? This
does seem to be what is happening.

>> (GSVideo:9501): GStreamer-WARNING **: loop detected in the graph of bin
>> GStreamer Audio Data Extractor: mysoundfile.wav!!
>
> No idea where this comes from.
Damn, I hoped this would be something that other people had run into:
here it is in context (sadly the code makes no sense to me):
gstbin.c: line 1747:

/* get next element in iterator. the returned element has the
 * refcount increased */
static GstIteratorResult
gst_bin_sort_iterator_next (GstBinSortIterator * bit, gpointer * result)
{
  GstBin *bin = bit->bin;

  /* empty queue, we have to find a next best element */
  if (g_queue_is_empty (bit->queue)) {
    GstElement *best;

    bit->best = NULL;
    bit->best_deg = G_MAXINT;
    g_list_foreach (bin->children, (GFunc) find_element, bit);
    if ((best = bit->best)) {
      if (bit->best_deg != 0) {
        /* we don't fail on this one yet */
        GST_WARNING_OBJECT (bin, "loop dected in graph");
        g_warning ("loop detected in the graph of bin %s!!",
            GST_ELEMENT_NAME (bin));
      }
      /* best unhandled element, schedule as next element */
      GST_DEBUG_OBJECT (bin, "queue empty, next best: %s",
          GST_ELEMENT_NAME (best));
      gst_object_ref (best);
      HASH_SET_DEGREE (bit, best, -1);
      *result = best;
    } else {
      GST_DEBUG_OBJECT (bin, "queue empty, elements exhausted");
      /* no more unhandled elements, we are done */
      return GST_ITERATOR_DONE;
    }
  } else {
    /* everything added to the queue got reffed */
    *result = g_queue_pop_head (bit->queue);
  }
....

> I don't think the volume element causes these issues. Its safe to set
> this property at any time. Can you explain how you check for the
> volume? Are you checking the actual data or are you using the level
> element.
See above for how I'm checking the volume.

Thanks again for the help, the more I test this bug and learn about
gstreamer the more bizarre this seems to be. I'll test the entire thing
with entirely different sounds tomorrow.

Ryan