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 492154 - All podcasts 'fail' after Suspend/Resume cycle.
All podcasts 'fail' after Suspend/Resume cycle.
Status: RESOLVED DUPLICATE of bug 352493
Product: rhythmbox
Classification: Other
Component: Podcast
0.10.x
Other All
: Normal minor
: ---
Assigned To: RhythmBox Maintainers
RhythmBox Maintainers
Depends on:
Blocks:
 
 
Reported: 2007-10-31 20:25 UTC by Paul Wayper
Modified: 2008-08-13 00:50 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Paul Wayper 2007-10-31 20:25:39 UTC 
Please describe the problem:
After I resume from a Suspend To RAM cycle, RhythmBox pops up an error message for each podcast feed saying that the podcast could not be downloaded.

Steps to reproduce:
1. Suspend your machine (I've only checked suspend to RAM, but hibernating to hard disk may also cause this).
2. Resume your machine.


Actual results:
Podcast download error messages appear.

Expected results:
No error messages appear.

Does this happen every time?
Yes

Other information:
This happens both when my laptop has a wired permanently-on internet connection and when I have to reconnect to a WiFi access point manually later.  It does not happen when NetworkManager loses or regains a network connection.
Comment 1 Paul Wayper 2007-11-05 10:08:17 UTC 
Obviously I left out a step:

0. Have RhythmBox running with podcasts set up.

Also, it doesn't matter if the podcasts are all up-to-date before suspending, and the period before resuming isn't long enough to trigger another check.  (I tested with a five-minute suspend/resume, just after refreshing all podcasts).
Comment 2 Jonathan Matthew 2008-08-13 00:50:11 UTC 
I fixed (or at least modified) this behaviour in 0.11.6.  It will no longer display error dialogs for automatic podcast updates, and should be more sensible about reporting errors overall.  If you still have problems with this, please reopen this bug or open a new one.


*** This bug has been marked as a duplicate of 352493 ***