GNOME Bugzilla – Bug 123249
[PATCH] spider doesn't work with file size smaller than 150 Ko
Last modified: 2005-08-15 01:57:03 UTC
There is a problem with spider if the file size is smaller that the *bufsizelimit* in gstspideridentity.c
I'm marking this as a blocker for 0.6.4. Not to annoy you, but simply because we need this fixed before 0.6.4 comes out. I'll look into this a.s.a.p.
Created attachment 20452 [details] [review] Possible fix
Does the above patch fix it? It properly handles EOS during buffer build-up.
I applied the patch and am getting crashes
+ Trace 40608
The stack trace doesn't make much sense to me though :(
Created attachment 20454 [details] [review] new try
There was a missing check for whether something is NULL causing this. The above should fix that.
apoc, could you comment on the new fix ?
I tried the fix myself; it doesn't hang my machine for a long time anymore with: (process:27628): GStreamer-CRITICAL **: file gstdata.c: line 239 (gst_data_unref): assertion `GST_DATA_REFCOUNT_VALUE (data) > 0' failed but instead it doesn't play, and gives me a lot of GStreamer-WARNING **: pull on pad filesrc0:src but it is not active
This is starting to get really annoying... I've got the fix as far as not to hang the app. However, I cannot get spider to understand that it should *properly* EOS *some* elements inside it. I just don't understand spider well enough, I suppose. Issue is as follows: as soon as the typefinder in spider fetches EOS, it should typefind with the buffer it has and then push that buffer forward, followed by EOS. All this works. However, on EOS, spider calls gst_element_set_eos () on all its elements inside it (i.e. everything). This is wrong, imo, it should just set it on the first element in its own chain of elements. Anyway, even if I comment that whole part out and just push EOS to ident->src in the chainfunc of spider, weird stuff happens. I get warnings such as "(process:15180): GStreamer-WARNING **: pull on pad mad0:src but it is not active" and fail to understand why from this point on. The whole pipeline should be set to EOS, but that doesn't happen... This is weird, because I'm following the exact same path that a >150kB file would follow, and that still works. I'm really missing a point here... Apparently, I'm badly misunderstanding something here. What I *think* is going on: everything in spider is one thread, and with opt, that kills several things. It means that if I push my buffer inside spider and then push another, both will be queued internally and, when the loopfunc/chainfunc of spider returns, handled by the next element. *However*, spider has then already set EOS on those elements, which is why I don't want it to call gst_element_set_eos() on its children. But it does, somehow. This is proven by the fact that my fix works if I use the basic scheduler instead of the opt one (here, every element is its own thread). Anyway, this is complicated. I don't know how to fix it easily. Help! ;).
Created attachment 20492 [details] [review] current patch, not 100% working :(
I found the problem. The scheduler (opt) puts the decoder and filesrc in the same group (thread), which means that the next call to filesrc will hang because filesrc (or whichever source) is in PAUSED (eos). I've got a pretty horrible workaround for this, please don't kill me right away but let me first explain that this is the only way I could fix this...
Created attachment 20500 [details] [review] /me ducks
postponing bug
*** Bug 125479 has been marked as a duplicate of this bug. ***
*** Bug 128056 has been marked as a duplicate of this bug. ***
Adding the PATCH keyword and upgrading the priority to High due to the attached patches.
This is definately not a blocker bug. I'm moving it back to 'major'. Note that (IIRC) HEAD CVS doesn't have this issue. Only 0.6.x does.
Ronald: Did you mean to remove the PATCH keyword?
Yes, because the patch is already in CVS for as far it's worth applying.
This appears to be fixed in 0.8.0. If not, someone will reopen it, right?