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 395733 - Podcast download mechanism isn't robust enough and often fails
Podcast download mechanism isn't robust enough and often fails
Status: RESOLVED OBSOLETE
Product: rhythmbox
Classification: Other
Component: Podcast
0.9.7
Other Linux
: Normal normal
: ---
Assigned To: RhythmBox Maintainers
RhythmBox Maintainers
Depends on:
Blocks:
 
 
Reported: 2007-01-12 10:46 UTC by Sebastien Bacher
Modified: 2018-05-24 12:15 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Sebastien Bacher 2007-01-12 10:46:22 UTC
That bug has been opened on https://launchpad.net/ubuntu/+source/rhythmbox/+bug/78524

"Binary package hint: rhythmbox

I have subscribed to a few radio podcasts in RB.
I have broadband so it's fast, and it used to work just fine, however, in the past couple of months, the quality of my internet connection (blame crappy ISP here!) has decreased significantly (takes ages to connect to a server, transfer speed is highly unstable, and sometimes plain stops, then resumes when it feels like it, a second later, or a minute... depends on the mood and server !).
This revealed a serious weakness/problem in RB: 99% of the time, RB fails to download the podcasts ! Most of the time it just says "Waiting", and sometimes it downloads 5% of the file then sits there forever and won't move an inch even if I let it run for 3 days.
Thing is, if I try to download these podcasts in a terminal, using the "wget" command, it works just fine, and in the worse case, it takes 3 minutes to grab an episode and that's it.
That's why I think the problem lies within RB...
I suspect that the problem might be that RB times out way too easily, and most importantly, when it does time out, it gives up for good, and won't insist.
So the solution is probably to do as wget likely does (from what I can see) : increase the time out greatly when connecting initially to the server. Say a 2 minute time out, not less.
Then once it starts downloading the file, and in the event that transfer speed drops to zero : DO NOT time out, and just patiently wait for transfer to resume.
...
> Do you have an example of podcast where you got the problem already?

I have a variety of podcasts and they all have this problem. Again, the problem isn't wit the podcast server, but my ISP/internet connexion. In the middle of the night, the podcasts download just fine, but in the evening, that is the "rush hours" ;-), it gets more challenging ! ;-)

Here are some feeds anyway (France Inter, Europe1, The BBC, LUG radio):
http://radiofrance-podcast.net/podcast/rss_10212.xml
http://www.europe1.fr/podcast/connaissance.jsp
http://downloads.bbc.co.uk/rmhttp/downloadtrial/worldservice/digitalplanet/rss.xml
http://www.lugradio.org/episodes.ogg.rss
...
Ok, as expected, the problem showed up this evening: one podcast had started downloading, but was stuck at 14%. I tried with wget in a terminal, and oh miracle, it worked. For sure it was slow, but it worked !
So RB definitely is not as "bullet proof" as wget !
UNFORTUNATELY..... even with the debug option, it printed nothing at all in the terminal while sitting at 14%. So I think RB just finds it "normal" to act this way, and doesn't feel the need to comment about it ! ;-/"
"
Comment 1 Jonathan Matthew 2007-07-01 12:16:25 UTC
There are two things that may lead to wget working where rhythmbox (through gnome-vfs) fails: proxy settings and the ability to resume transfers.  The former is the user's problem, the latter can only be fixed by switching to something other than gnome-vfs for podcast downloads (gvfs, maybe..).

We might not be handling broken connections in our gnome-vfs callbacks correctly.
Comment 2 Leon Barrett 2007-10-02 21:02:38 UTC
I also suffer from this bug. Sometimes Rhythmbox only downloads the beginning of a podcast and marks it as complete. So I have 1-minute podcasts that are labeled as complete but are nothing of the sort.

One possible source of the bug is that I may have (all unaware) shut off the computer while it's downloading the podcast, but the bug has occurred often enough that I don't think this is the problem. So I think the source of the bug is just an issue with downloading.

I'm using Rhythmbox 0.10.0 on Ubuntu Feisty.
Comment 3 Tuomo Sipola 2007-11-29 21:35:24 UTC
I have the same problem. If a podcast download fails for some reason (eg. disconnecting) the download is shown as complete. Thus an episode that is meant to be 12:47 long downloads only for example 00:07 because of my unstable Internet connection. 

A simple reload functionality would solve this problem partially. By clicking on the episode with right mouse button and then selecting download from the menu I could easily download the podcast again from start to the finish.

I'm using Rhythmbox 0.11.2 on Ubuntu Gutsy. 
Comment 4 Dean Pierce 2007-12-27 16:58:27 UTC
I am using 0.11.2 on gutsy

A tip to help a developer reproduce the issue:
Podcasts normally work alright for me at home, or when I am at work, but whenever I go to a coffee shop (wireless), I am never able to successfully grab a podcast.  Maybe I just have many sketchy coffee shops in my neighbourhood, but the less "stable" network environment definitely causes more issues.

I get the behaviour of the whole download looking like it completes, and once it gets to 100% it says "Downloaded" (for about .1 seconds), but quickly turns to "Failed".  I am assuming that the hash check is failing or something, I haven't really looked into the internals.
Comment 5 Emmanuel Fleury 2008-01-28 11:46:49 UTC
I still experiment such a problem when downloading from http://radiofrance-podcast.net/podcast/rss_10212.xml (actually not only this one).

Rhythmbox should at least offer the possibility to "Re-download" once you did it once and it failed before reaching 100%... 

I'm stuck with a pile of 3 minutes, 2 minutes, 5 minutes where the original podcasts should have lasted 45 minutes.
Comment 6 Bastien Nocera 2008-01-28 14:05:02 UTC
(In reply to comment #5)
> I still experiment such a problem when downloading from
> http://radiofrance-podcast.net/podcast/rss_10212.xml (actually not only this
> one).

Radio France takes the podcasts down as it goes, you can only download the last episode at any one time (at least that's what it does for my few podcasts on that site).
Comment 7 Emmanuel Fleury 2008-01-28 14:29:32 UTC
I didn't get exactly what you meant... :-/

Even thought I could download only the last episode, why can't I download it several times if it is still available ? And why can't we have a "Reload/Redownload" action in the contextual menu about a Podcast-stream episode ?
Comment 8 Albert Lightfoot 2008-03-09 07:50:08 UTC
Using Fedora 7 (Kernel 2.6.23.15-80.fc7) and Rhythmbox 0.10.1 I also find that MOST of my podcast downloads are being truncated at anything from a few percent of the file successfully downloaded to almost complete download. I have only recently (last few weeks) started using this facility, and it initially seemed to work alright.  There was recently a major KDE update which may be involved (<10 days ago).  Downloading podcasts through Firefox 2.0.0.12 is similarly unsuccessful MOST of the time.  These podcasts are mp3 format (aren't they all!) and are from several different podcasters in several different countries.  No difficulty with other downloads (text, pdf, rpm etc).

Is there a known bug here? I have an ADSL connection which mostly seems to download at about 25-27 MiB/sec.

Albert Lightfoot
Comment 9 Ashok Narayanan 2008-07-16 19:15:37 UTC
One of the things I have noticed with this is that it seems to happen for me with podcasts which have very long filenames. For example, MSNBC podcasts for some shows have 245-character filenames; they don't download properly. Most Linux filesystems have a 255-byte limit. I wonder if this is the problem with podcast downloads.
Comment 10 George Toderici 2008-09-03 23:29:00 UTC
I also experience downloading problems. It seems that if the server is unresponsive immediately, rhythmbox seems to "give up" for a while. The issue is that it takes a long while to retry, and there is no notification of what is actually happening. I think a "viable" fix would be to replace "waiting" to some more meaningful string, such as "retrying for the Xth time" or "Tried X times and now giving up."

I have experienced the problem with Rhythmbox bundled in Ubuntu Dapper (0.10.xx) and Hardy (0.11.5).
Comment 11 GNOME Infrastructure Team 2018-05-24 12:15:35 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/rhythmbox/issues/301.