GNOME Bugzilla – Bug 352493
Podcasts produce errors if no internet connection is available
Last modified: 2008-08-13 00:50:11 UTC
Please describe the problem: When an internet connection is not available, RB produces errors when trying to update podcasts, one per. Over a period of hours, these can total up to over 100 error dialogs. If one finds the right one, you can begin to close them, but otherwise, the quickest way to get rid of them is to exit and restart RB, which is only good until RB checks for updates again. Steps to reproduce: 1. Disable the internet connection. 2. Let RB run with podcasts in the db. 3. Wait for the errors to pour in. Actual results: RB produces gobs of errors over a period of hours that are uncloseable. Expected results: I would expect that these errors would be suppressed and that RB would recognize that there is no connection available. Does this happen every time? Yes, on the hour (my update interval). Other information: For what it's worth, I was connected to my router during this time (valid IP address etc.), but my router was unable to connect to the internet.
The only way we're going to determine that no network connection is available is through network manager (unless you have a better/different suggestion?). There's already a bug open for that (bug 322266), and I've done a small amount of work towards it. We can definitely improve the way we report these errors, though. We shouldn't be using error dialogs when there was no user action that triggered the error. Perhaps we could mark feeds that gave an error on the last update differently in the feed view, and show the error text in the properties dialog? Is there some reason you marked this as a blocker? It has a trivial workaround.
(In reply to comment #1) > We can definitely improve the way we report these errors, though. We shouldn't > be using error dialogs when there was no user action that triggered the error. > Perhaps we could mark feeds that gave an error on the last update differently > in the feed view, and show the error text in the properties dialog? Yes, I suppose this is the real bug. What about the same "blocked" icon over each podcast feed? > Is there some reason you marked this as a blocker? It has a trivial > workaround. It made more sense the way Bugzilla described it when reporting; the severity description here seems to imply otherwise.
*** Bug 363527 has been marked as a duplicate of this bug. ***
*** Bug 367831 has been marked as a duplicate of this bug. ***
*** Bug 372741 has been marked as a duplicate of this bug. ***
I think this is very anoying too. I would add some kind of indicator to each podcast to show if the last download of the feed was successful. If it succeeds on the next try, this could be cleared. Error/Warning dialogs are the worst solution.
Ubuntu bug about that: https://launchpad.net/bugs/73128 "I have subscribed to a dozen or so radio/audio podcasts, so I set RB to check and download new podcasts automatically, every hour. The problem is that (probably partly due to my crappy ISP), RB regularly has some sort of problem with some podcast or another, and that everytime, it pops up an error window to tell me about it. Thing is, in practice I get these windows very often, sometimes if I leave the computer unattended or a few hours or half a day, there are a dozen windows I must close one by one, when I come back ! Basically, all these error windows do more harm than good : 1) they interrupt my work randomly 2) I can't do anything about the problem anyway, and can only click the "ok" button to make it go away 3) the problem is always temporary, and if I update the feeds manually, the problem has already cured itself. This is the way I would expect RB to behave: - When set for automatic downloads : never require user input, no pop up windows. If an error occurs, just try again 5 minutes later, most (all, so far) of the time it will suffice. The error should only be notified by an "error" icon next to the podcast (as is already the case), and cleared once the problem is gone. Additionnaly, if RB deems it worthwhile to inform the user of an error, it can just use the notification area, using a bubble. This way the user can see the information, but is not too disturbed by it. - Pop up messages should only be used when the user operates RB manually."
I get the same issue when I suspend Ubuntu 6.10. When I power it back on again in the morning I have one dialog for each hour it's been suspended for. I would have thought that when the computer is suspended it wouldn't be checking for new podcasts?
*** Bug 421430 has been marked as a duplicate of this bug. ***
(In reply to comment #8) > I get the same issue when I suspend Ubuntu 6.10. When I power it back on again > in the morning I have one dialog for each hour it's been suspended for. I would > have thought that when the computer is suspended it wouldn't be checking for > new podcasts? > Sorry, it's not for every hour it's been suspended, it's for how many podcasts I'm subscribed to. duh
Created attachment 85565 [details] [review] better podcast feed error reporting - only use dialog boxes for user-requested podcast feed updates - only complain about mime types for newly added feeds - add an error indicator column to the podcast feed view - if we couldn't load the feed, display the gnome-vfs error message
Note that it makes the computer unusable if it happens for a few days when you're away: metacity is unbelievably slow when there are a lot of windows...
Btw, I didn't look at the patch, but it probably doesn't fix this issue: there shouldn't be two error dialogs for the same feed. So if the user requests an update twice, he should get only one dialog, not two.
(In reply to comment #13) > Btw, I didn't look at the patch, but it probably doesn't fix this issue: there > shouldn't be two error dialogs for the same feed. So if the user requests an > update twice, he should get only one dialog, not two. Well, there shouldn't be an error dialogue in the first place. It should be an error icon next to the feed name.
(In reply to comment #13) > Btw, I didn't look at the patch, but it probably doesn't fix this issue: there > shouldn't be two error dialogs for the same feed. So if the user requests an > update twice, he should get only one dialog, not two. This would only happen if the user manually requested an update (by using the button/menu item) a few times in a row, automatic updates shouldn't cause dialogs with this patch applied. On the patch, should this chunk be there? it looks otherwise fairly sane to me. @@ -1445,7 +1454,7 @@ switch (index) { case UPDATE_EVERY_HOUR: - value = time (NULL) + 3600; + value = time (NULL) + 37; //3600; break; case UPDATE_EVERY_DAY: value = time (NULL) + (3600 * 24);
The 37s update interval was just there for testing. One thing I'm not sure about here is whether we should show error dialogs when the user updates multiple feeds at once. As the patch stands, we would, but I think perhaps we shouldn't. This might appear to be a weird inconsistency, though.
Created attachment 87651 [details] [review] updated patch now includes the patch from bug 370772
My suggestion for a fix is more generic: Rhytmbox also creates a number of other message boxes about starting and ending podcast downloads etc that are also quite bothersome, so why not just limit these popup boxes generically. So that at most there is only one active. And that they can (by default, really) could all be eliminated altogether. The status indicator may provide some way of displaying more info.
Created attachment 90928 [details] [review] updated, reworked a bit - return GErrors from rb-podcast-parser so we can return specific information about what's going wrong - move UI bits out of rb-podcast-parser (only slightly better; probably shouldn't be in rb-podcast-manager either)
Created attachment 90929 [details] [review] this time without the stupid 37s update change
Are there plans to fix this? I'm still getting this problem in Ubuntu Gutsy on my laptop (which frequently doesn't have an internet connection) and it's very infuritating. Let me know if there's anything I can do to help debug, although the bug report seems pretty clear to me. Gerv
*** Bug 525632 has been marked as a duplicate of this bug. ***
I figured this has been sitting around for too long, so I updated it, tested it a bit, and committed it.
*** Bug 492154 has been marked as a duplicate of this bug. ***