GNOME Bugzilla – Bug 330498
Podcast status stays as "Waiting" for the entire download.
Last modified: 2007-06-29 12:58:49 UTC
Please describe the problem: The summary says it all, for some downloads all I am shown is Waiting in the status column instead of the percentage counting up from 1% to 100%. Steps to reproduce: 1. 2. 3. Actual results: Expected results: Does this happen every time? Other information:
What version of gnome-vfs do you have? I think we had a bug about this earler, which turned out to be a gnome-vfs issue.
I did notice that bug (325861) after I submitted the bug because I only looked under rhythmbox->podcast component. I'm running ubuntu dapper with: libgnomevfs2-0 2.13.4-0ubuntu1
This works for me with cvs and 0.9.3, also using Dapper (same gnome-vfs version). Is it all your podcasts or only some? If only some, could you post a url here?
No, it isn't with all podcasts. I'm trying to remember if it was the new scientist or nature one that was one of the main culprits. I'm pretty sure it was the nature one. IIRC one of the podcasts was the nature podcast: http://www.nature.com/nature/podcast/rss/nature.xml If that works ok maybe try new scientist: http://www.newscientist.com/podcastfeed.ns And if they both behave, let me know and I'll track down another misbehaving feed.
I can confirm this. ./test-xfer 'http://www.nature.com/nature/podcast/v437/n7060/nature-2005-10-06.mp3' /tmp/foo.mp3 [snip] Transferring `http://www.nature.com/nature/podcast/v437/n7060/nature-2005-10-06.mp3' to `file:///tmp/foo.mp3' (file 1/1, byte 0/0 in file, 0/1024 total) HTTP:[0x9fe6520] [read] bytes read 3849 {in do_read} Status: OK Transferring `http://www.nature.com/nature/podcast/v437/n7060/nature-2005-10-06.mp3' to `file:///tmp/foo.mp3' (file 1/1, byte 3849/0 in file, 3849/1024 total) HTTP:[0x9fe6520] [read] bytes read 4096 {in do_read} Status: OK On the surface this looks very much like bug 325626 but that bug was fixed.
Since this appears to be a gnomevfs issue, reassigning there.
the latest Ricky Gervais podcast is another example of this: http://www.guardian.co.uk/podcasts/rickygervais/mp3.xml
oops, the gervais podcast may be broken in a different way.
And here's why: jonathan@pointy:~$ curl -I http://www.nature.com/nature/podcast/v437/n7060/nature-2005-10-06.mp3 HTTP/1.0 200 OK Via: 1.1 tinyproxy (tinyproxy/1.6.3) Content-Type: audio/x-mpeg ETag: W/"18348703-1150520384000" Server: Apache-Coyote/1.1 Date: Tue, 16 Jan 2007 11:20:59 GMT Last-Modified: Sat, 17 Jun 2006 04:59:44 GMT Content-Length: 0 <-- gnome-vfs uses the content-length from the file info (HTTP HEAD) request as the file size during the transfer. If the server doesn't return the correct content-length (as it SHOULD), transfer callbacks don't get the right file size.
Created attachment 80383 [details] [review] proposed fix Updates progress->progress_info->file_size in xfer_open_source if the file size was not already known. gnome_vfs_get_file_info_from_handle() will return values from the HTTP GET response for HTTP transfers, so in this case it will have the correct file size.
Its sort of hacky to have this in the code xfer code, but it shouldn't break anything, so i guess its ok.
This patch introduced bug 450909.