After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 595904 - gnlfilesource unable to seek: "Sending seek event failed!"
gnlfilesource unable to seek: "Sending seek event failed!"
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gnonlin
git master
Other Linux
: Normal normal
: 0.10.16
Assigned To: GStreamer Maintainers
Edward Hervey
Depends on:
Blocks:
 
 
Reported: 2009-09-22 04:37 UTC by Gabriel Burt
Modified: 2010-11-01 18:24 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
txt file containing both relevant log snippets (11.91 KB, application/octet-stream)
2009-09-22 04:37 UTC, Gabriel Burt
  Details
Full disclosure - I have this patch applied to my gnonlin (1.58 KB, patch)
2009-09-22 04:54 UTC, Gabriel Burt
none Details | Review
Log using gnlfilesource (5.72 KB, text/plain)
2009-09-22 16:30 UTC, Gabriel Burt
  Details
Tgz with code in question (341.35 KB, application/x-compressed-tar)
2009-09-22 17:29 UTC, Gabriel Burt
  Details

Description Gabriel Burt 2009-09-22 04:37:55 UTC
Created attachment 143653 [details]
txt file containing both relevant log snippets

If I import a file into Pitivi, it's able to play it, even if cut into pieces.

But if I try to even play a file using a gnlfilesource in some of my code, I
get:

gnlcomposition.c:1719:no_more_pads_object_cb:<gnlcomposition0> Sending seek
event failed!

Though I'm still digesting them, the attached logs make me think this isn't a
bug with the h264 decoder but with gnonlin itself.
Comment 1 Gabriel Burt 2009-09-22 04:54:36 UTC
Created attachment 143654 [details] [review]
Full disclosure - I have this patch applied to my gnonlin

This patch

1. forces gnlfilesource not to use uridecodebin (I was trying to rule it out as the problem)

2. fixes a Critical warning about calling control_element twice (already filed in a separate bug)

3. Fixes "Couldn't set Async pad blocking" error when the pad is already blocked (docs say the func will return false in that case)

Maybe this bug is related to needing (3) in the first place.
Comment 2 Edward Hervey 2009-09-22 05:57:43 UTC
Which version of gnonlin are you using ? current git now only uses uridecodebin.
Comment 3 Gabriel Burt 2009-09-22 06:02:15 UTC
I was using b478055dafff633e1a8f0cb6db1e3b7ffe2d682a - I will test again w/ latest
Comment 4 Gabriel Burt 2009-09-22 16:30:30 UTC
Created attachment 143709 [details]
Log using gnlfilesource

This is with the latest git with no patch applied.  Looks the same as the previous gnlfilesource log to me.
Comment 5 Gabriel Burt 2009-09-22 17:29:38 UTC
Created attachment 143717 [details]
Tgz with code in question

If you have gstreamer-sharp built and copy the gstreamer-sharp.dll* files to this directory, "make" should work.
Comment 6 Edward Hervey 2010-04-13 08:25:44 UTC
I think this issue was fixed with 

commit 94127891402a16382eb4242f354f681af6934705
Author: Edward Hervey <bilboed@bilboed.com>
Date:   Fri Mar 19 12:13:07 2010 +0100

    GnlSource: Handle multiple pad_blocked calls.
    
    The pad blocked handler can be called by multiple threads, we
    therefore need to make sure we only start the ghost_seek_pad handler
    once.

Gabriel, can you confirm it's fixed in git head ?
Comment 7 Tobias Mueller 2010-05-29 13:59:11 UTC
Gabriel, Ping.
Comment 8 Akhil Laddha 2010-08-19 04:45:21 UTC
Please feel free to reopen the bug if the problem still occurs with a newer
version of Gstreamer.