well it seems that is the same problem, i resolved to let the pipeline "blocked" for a long time...and after something like 23min it happens the same thing (Could not close resource.). i run a full debugged launch and attached the part where the error occurs (after 23 minutes). gst-launch -v gnomevfssrc location=<a href="ftp://194.44.214.3/pub/music/Collection/ArtofNoise.mp3">ftp://194.44.214.3/pub/music/Collection/ArtofNoise.mp3</a> ! decodebin ! fakesink --gst-debug=5 2> no_queue.log Setting pipeline to PAUSED ... /GstPipeline:pipeline0/GstDecodeBin:decodebin0/GstTypeFindElement:typefind.GstPad:src: caps = audio/x-wav Pipeline is PREROLLING ... ERROR: from element /GstPipeline:pipeline0/GstGnomeVFSSrc:gnomevfssrc0: Could not close resource. Additional debug info: gstgnomevfssrc.c(889): gst_gnome_vfs_src_stop (): /GstPipeline:pipeline0/GstGnomeVFSSrc:gnomevfssrc0: Could not close vfs handle: Operation cancelled Setting pipeline to NULL ... /GstPipeline:pipeline0/GstDecodeBin:decodebin0/GstTypeFindElement:typefind.GstPad:src: caps = NULL Freeing pipeline ... any hints if this is normal and i have to always use a queue after using a vfs src element? maybe a bug on gnomevfssrc regarding an specific behaviour of the ftp server? <div class="gmail_quote"> On Mon, Apr 19, 2010 at 10:35 PM, Tiago Katcipis <<a href="mailto:katcipis@inf.ufsc.br">katcipis@inf.ufsc.br</a>> wrote: <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> trying to solve my problem i found another one :-). using a public ftp i run this: gst-launch -v gnomevfssrc location=<a href="ftp://194.44.214.3/pub/music/Collection/ArtofNoise.mp3" target="_blank">ftp://194.44.214.3/pub/music/Collection/ArtofNoise.mp3</a> ! queue ! decodebin ! fakesink and it works ok, the ftp is really slow...it takes a good time before it starts to download and decode....but works even if i try: gst-launch -v gnomevfssrc location=<a href="ftp://194.44.214.3/pub/music/Collection/ArtofNoise.mp3" target="_blank">ftp://194.44.214.3/pub/music/Collection/ArtofNoise.mp3</a> ! queue ! decodebin ! alsasink i can hear the music (it takes a while to go from paused to playing, something like 20-30 seconds....but if you wait it wil happen). But if i take the queue element out: gst-launch -v gnomevfssrc location=<a href="ftp://194.44.214.3/pub/music/Collection/ArtofNoise.mp3" target="_blank">ftp://194.44.214.3/pub/music/Collection/ArtofNoise.mp3</a> ! decodebin ! fakesink the pipe stays blocked for ever (on both cases)... is this behavior expected? have anyone faced something like that? is a good policy to always put a queue after a gnomevfssrc? if someone have other ftp server to test this i would appreciate. best regards, Katcipis<div><div></div><div class="h5"> <div class="gmail_quote">On Fri, Apr 16, 2010 at 2:03 PM, Tiago Katcipis <<a href="mailto:katcipis@inf.ufsc.br" target="_blank">katcipis@inf.ufsc.br</a>> wrote: <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> now i got some interesting results, testing with a pipeline like this: gst-launch gnomevfssrc location="ftp://user:password@ftp.myserver.com:/myfile.wav" ! filesink location="test.wav" im able to get the file and play it locally. even if i run: gst-launch gnomevfssrc location="ftp://user:password@ftp.myserver.com:/myfile.wav" ! audio/x-raw-int,signed=true,channels=1,rate=8000,width=16,endianness=1234 ! pulsesink it works(and i hear a lot of noise :-)). But if i run: gst-launch gnomevfssrc location="ftp://user:password@ftp.myserver.com:/myfile.wav" ! audio/x-raw-int,signed=true,channels=1,rate=8000,width=16,endianness=1234 ! audioparse ! pulsesink or gst-launch gnomevfssrc location="ftp://user:password@ftp.myserver.com:/myfile.wav" ! wavparse ! pulsesink or<div> gst-launch gnomevfssrc location="ftp://user:password@ftp.myserver.com:/myfile.wav" ! decodebin ! pulsesink </div>it gives the same error:<div> ERROR: from element /GstPipeline:pipeline0/GstGnomeVFSSrc:gnomevfssrc0: Could not close resource. </div>it seems that every time i try to parse the file to get its type and play it, it fails, but if i only play it raw or download it.... works fine. any toughts? <div><div></div><div> <div class="gmail_quote">On Fri, Apr 16, 2010 at 11:42 AM, Tiago Katcipis <<a href="mailto:katcipis@inf.ufsc.br" target="_blank">katcipis@inf.ufsc.br</a>> wrote: <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Im having some trouble using gnomevfssrc and ftp, what troubles me is the error, a simple Could not open would make me understand that i did something wrong or something is wrong with the server.... but this error msg "Could not close"... i simply cant find anything about it, I'm not quite sure if this is something wrong on the ftp server i am using here or if it is a problem with gnomevfs or gstreamer. The test is simple: gst-launch gnomevfssrc location="ftp://user:password@ftp.myserver.com:/myfile.wav" ! decodebin ! pulsesink The output is: (gst-launch-0.10:2735): GLib-WARNING **: g_set_prgname() called multiple times Setting pipeline to PAUSED ... /GstPipeline:pipeline0/GstDecodeBin:decodebin0/GstTypeFindElement:typefind.GstPad:src: caps = audio/x-wav Pipeline is PREROLLING ... /GstPipeline:pipeline0/GstDecodeBin:decodebin0/GstWavParse:wavparse0.GstPad:sink: caps = audio/x-wav ERROR: from element /GstPipeline:pipeline0/GstGnomeVFSSrc:gnomevfssrc0: Could not close resource. Additional debug info: gstgnomevfssrc.c(889): gst_gnome_vfs_src_stop (): /GstPipeline:pipeline0/GstGnomeVFSSrc:gnomevfssrc0: Could not close vfs handle: Operation cancelled ERROR: pipeline doesn't want to preroll. Setting pipeline to NULL ... /GstPipeline:pipeline0/GstDecodeBin:decodebin0/GstWavParse:wavparse0.GstPad:src: caps = NULL /GstPipeline:pipeline0/GstDecodeBin:decodebin0/GstWavParse:wavparse0.GstPad:sink: caps = NULL /GstPipeline:pipeline0/GstDecodeBin:decodebin0/GstTypeFindElement:typefind.GstPad:src: caps = NULL Freeing pipeline ... Even the wav file header is being read, but on the prerolling this odd error happens. The same url that generates this error works just fine on wget (the file gets downloaded and i can hear it perfectly). can someone help me? I'm not very used to ftp...maybe I'm missing something. best regards, Katcipis </blockquote></div> </div></div></blockquote></div> </div></div></blockquote></div>