https://bugs.gpodder.org/show_bug.cgi?id=1106
--- Comment #3 from Thomas Perl <[email protected]> 2010-08-27 12:56:38 BST --- (In reply to comment #2) > (In reply to comment #1) > > Can you provide two feeds for which this happens, ideally with the > > episodes that are affected? > > Here's a simple example with only one feed: The following podcast > (accidentally) references the same download twice in two episodes with the > same > enclosure URL, but different GUIDs. > http://electronicexplorations.org/feed/ > The episodes in question are both titled “093 — Kontext”. The GUIDs are: > http://electronicexplorations.org/?p=272 > http://electronicexplorations.org/?p=274 This is a very special case, and I hope it does not happen too often. What would you expect gPodder to do in this case? Hide the second occurence because of the same download URL? Let gPodder download the same file twice, acting as if it was two separate episodes (because the GUID is different)? Downloading the file and after that setting the download filename on both episodes (deleting one episodes would then also delete the other one)? I agree that this case could be better handled, but I'm not sure what's the best way to handle it, as the semantics of this is not clear (I also wonder what the motivation behind this is from the feed author's POV..). > While trying to reproduce the problem with the latest git version of gPodder, > I > found that apparently this version cannot be confused nearly as easily as > earlier versions. But at least one of the problems I reported is easily > reproducible: Downloading one episode changes the status icons of both > episodes > to “downloading.” Yes, this is because we use the download URL to "compare" episodes instead of using the GUID. I think we do this because it's the easiest, and adding the GUID to the check would probably decrease the performance a bit (unscientific estimation). It could also lead to other problems where the GUID is not set (although we should fall back to the download URL in this case). Using the download URL as comparison key for downloads has the advantage that I can be sure that the URL is set and unique, and when downloading a file from a given URL, it is (due to the nature of URLs) *really* downloading both episodes at the same time. The problem here is that the usual assumption "one item in the feed = one unique episode = one unique download URL" breaks for these feeds, and this is the point where things get ugly :) > When two episodes in two different podcasts share both download URL and GUID, > gPodder shows the episode in the podcast in which it was discovered first, and > hides / ignores it in the other. While being more sensible/useful than the > behavior shown when just the URL is shared, I still think this is confusing. Three options come to my mind: * The current behaviour (first come, first served - second one ignored) * Separately handle each episode (the user has to download them separately) * Share the download between feeds (tricky, because of download folders, etc..) > gPodder should somehow make the user aware of the duplicates. I'm open for suggestions on how to do this :) > Here are two podcasts that exhibit this behavior. Both share a lot of > episodes > (the second has the superset of all episodes of the first): > http://www.dradio.de/rss/podcast/sendungen/wirtschaftammittag/ > http://www.dradio.de/rss/podcast/sendungen/wirtschaftundverbraucher/ Yes, this also happens with feeds like Chaosradio Express (which has two feeds: one for the most recent episodes and one for all episodes). How should this be handled? Ignore that these feeds share the same download URL and let the user download from both feeds separately, ignoring the possible gain from "sharing" a download (so for example the user sees both episodes as new from each feed, and (s)he has to download both, even though the file downloaded is exactly the same). -- Configure bugmail: https://bugs.gpodder.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes. _______________________________________________ gPodder-Bugs mailing list [email protected] https://lists.berlios.de/mailman/listinfo/gpodder-bugs
