GNOME Bugzilla – Bug 706173
Future lastBuildDate in RSS feed causes crash when "Download new episodes" is set
Last modified: 2013-08-25 07:09:06 UTC
The feed which causes this for me is http://www.abc.net.au/triplej/review/film/podcast/podcast.xml , preserved at http://pastebin.com/WPeucW6D . I start Banshee, it runs for a while then disappears without any error message. If I restart it immediately it then usually runs okay. Steps to reproduce: 1. Under Media menu choose Add Podcast 2. Enter the url http://www.abc.net.au/triplej/review/film/podcast/podcast.xml and check Download New Episodes 3. Click Subscribe Banshee will start downloading some episodes of this podcast, after a few moments it will crash. I've also tried updating to 2.6.1. Banshee doesn't crash in this version but if new podcasts are downloaded from the problem feed it chews up CPU and then hangs on Quit.
Created attachment 251966 [details] Exception detail I checked out the source and ran with make run. The output shows a tight loop in Migo/Migo.Syndication/Feed.cs which causes a StackOverflowException.
Created attachment 251967 [details] [review] Patch to handle future lastBuildDate in RSS
Thank you for your bug report, the detailed description, and the patch ! I was a bit uncomfortable with setting LastAutoDownload to LastBuildDate, because, as this bug shows, you never know what crazy value could be set in the RSS. And if the dates are ever corrected in this particular RSS, I think the feed would then not get updated at all. So I went with a different approach, to try to avoid any possibility of an infinite loop between CheckForItemsToDownload and Save. You can see the commit here (in git master): https://git.gnome.org/browse/banshee/commit/?id=78ff9e54d4 If you haven't done so already, it would be great to contact the podcast publisher to ask him to fix his feed. Unless he is really doing his podcast in the future... :)
I see your point about what happens when the feed is corrected. I have sent feedback to Triple J now, I thought I'd wait until after the bug was addressed. This bug may also show up if there are feeds out there that mistakenly publish local time as UTC or if a user's system time is wrong. I think the real issue here is that checking the LastBuildDate is not the best test of whether an RSS feed has changed since the last auto download, especially considering that this field is optional - http://www.w3schools.com/rss/rss_channel.asp . Would it be possible to use the Last-Modified field from the HTTP header? Another thing I noted is that dates are all stored and compared as local time. Wouldn't it be better to work in UTC where you won't get weirdness like hours repeating themselves during daylight savings?
Response from Triple J: Hi Cathy, Thanks for your feedback. We're aware of the issue and created a new feed about a year ago. Unfortunately there's no way of retiring an old feed and seamlessly migrating people to a new one, even though all the references on our site and iTunes point to the correct feed. I'd suggest unsubscribing from the current feed and resubscribe to this one http://www.abc.net.au/triplej/film/podcast.xml Cheers triple j dev team