Podcast download mechanism isn't robust enough and often fails

Bug #78524 reported by Trouilliez vincent
56
This bug affects 8 people
Affects Status Importance Assigned to Milestone
Rhythmbox
New
Unknown
rhythmbox (Ubuntu)
Fix Released
Low
Ubuntu Desktop Bugs

Bug Description

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.

Revision history for this message
Sebastien Bacher (seb128) wrote :

Thank you for your bug. What version of Ubuntu do you use? Do you have an example of podcast where you got the problem already? Could you try to get a log of what is happening when it hangs with "rhythmbox -d"?

Changed in rhythmbox:
assignee: nobody → desktop-bugs
status: Unconfirmed → Needs Info
Revision history for this message
Trouilliez vincent (vincent-trouilliez-modulonet) wrote :

> What version of Ubuntu do you use?

The latest (Edgy). I am also testing Feisty and AFAICR it's not better.

> 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

> Could you try to get a log of what is happening when it hangs with "rhythmbox -d"?

Sure. It will have to wait this evening though, as it's only 9h30 right now and it works fine, not much traffic on the French network at this time of day ;-)

Revision history for this message
Trouilliez vincent (vincent-trouilliez-modulonet) wrote :

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 ! ;-/
I guess we don't realy need information do we ? Can't we "just" ;-) look at the source code of wget and compare it with RB, to enhance the latter ?
I know I know, it's always easier said than done ;-)

Revision history for this message
Sebastien Bacher (seb128) wrote :

Ok, that's probably enough informations, I've forwarded the problem upstream: http://bugzilla.gnome.org/show_bug.cgi?id=395733

Changed in rhythmbox:
importance: Undecided → Low
status: Needs Info → Confirmed
Changed in rhythmbox:
status: Unknown → Unconfirmed
Revision history for this message
Srand (cyril-scetbon) wrote :

I get podcast download issues since feisty. And it's still the case under hardy :-(
I've tested to debug rhythmbox which says

(17:37:42) [0x80dc408] [rb_shell_clipboard_entryview_changed_cb] rb-shell-clipboard.c:745: entryview changed
(17:37:42) [0x80dc408] [rb_podcast_manager_next_file] rb-podcast-manager.c:585: looking for something to download
(17:37:42) [0x80dc408] [rb_podcast_manager_next_file] rb-podcast-manager.c:611: processing http://logc7.xiti.com/get/video.mp3?xts=180213&type=Podcast&flux=podcast_zdnet&pod=20080711&url=http://media.cnetnetworks.fr/zdnet-fr/hebdo/2008/07/zdnet-hebdo-podcast-110708.mp3
(17:37:42) [0x80dc408] [rb_podcast_manager_next_file] rb-podcast-manager.c:623: hiding query string xts=180213&type=Podcast&flux=podcast_zdnet&pod=20080711&url=http://media.cnetnetworks.fr/zdnet-fr/hebdo/2008/07/zdnet-hebdo-podcast-110708.mp3 from gnome-vfs
(17:37:42) [0x80dc408] [rb_shell_clipboard_sync] rb-shell-clipboard.c:543: syncing clipboard
(17:37:43) [0x80dc408] [rb_podcast_manager_download_file_info_cb] rb-podcast-manager.c:681: got file info results for http://logc7.xiti.com/get/video.mp3?xts=180213&type=Podcast&flux=podcast_zdnet&pod=20080711&url=http://media.cnetnetworks.fr/zdnet-fr/hebdo/2008/07/zdnet-hebdo-podcast-110708.mp3
(17:37:43) [0x80dc408] [rb_podcast_manager_download_file_info_cb] rb-podcast-manager.c:699: get_file_info request failed
(17:37:43) [0x80dc408] [rb_podcast_manager_next_file] rb-podcast-manager.c:585: looking for something to download
(17:37:43) [0x80dc408] [rb_podcast_manager_next_file] rb-podcast-manager.c:599: download queue is empty

For information, the podcast link is composed of 179 characters.

Changed in rhythmbox:
status: Confirmed → Triaged
Changed in rhythmbox:
importance: Unknown → Medium
Revision history for this message
Andrew (andrew-punch) wrote :

I have the same problem.

This podcast does not work (status "waiting"), it has worked in the past:
http://www.democracynow.org/podcast.xml

This podcast works correctly:
http://www.cpod.org.au/feed.php?id=257

Revision history for this message
Boyd (boyd-dyob) wrote :

I experience this bug in version 0.13.3 of Rhythmbox on Ubuntu 11.04 . I'm trying to listen to Democracy Now too ;-)

Changed in rhythmbox:
status: New → Expired
Revision history for this message
Paul White (paulw2u) wrote :

The upstream report has moved to:
https://gitlab.gnome.org/GNOME/rhythmbox/issues/301
but has seen no activity

Is this still an issue or have the updates to rhythmbox over the years rendered this bug report obsolete as the problem has been fixed?

Changed in rhythmbox:
importance: Medium → Unknown
status: Expired → Unknown
Changed in rhythmbox (Ubuntu):
status: Triaged → Incomplete
Changed in rhythmbox:
status: Unknown → New
Revision history for this message
Paul White (paulw2u) wrote :

Bug report won't expire due to bug watch
Upstream report last saw activity 11 years ago
No reply to request for information in comment #8
Example podcast in comment #6 works here with Ubuntu 18.04
so will close as issue probably fixed for some time.

Changed in rhythmbox (Ubuntu):
status: Incomplete → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.