https://bugs.gpodder.org/show_bug.cgi?id=1106
--- Comment #4 from sideral <[email protected]> 2010-09-16 18:00:08 BST --- (In reply to comment #3) Thanks for your reply. It raises some good questions, and here's my attempt to answer them. It looks like we should discern among two major cases, each with three subcases: 1. The episodes are from the same podcast ========================================= 1.a) Two episodes share the same download (enclosure) URL _and_ the same GUIDs This typically constitutes an update of the original episode posting. The newer episode should replace the old. The enclosure download status should not change. Not sure what gPodder does today in this case. 1.b) The two episodes share the same GUID, but have different download (enclosure) URLs An update of the original episode posting with an updated enclosure download URL. The newer episode should replace the old. The enclosure download status should not change, as the shared GUID indicates that the download content has not changed. Not sure what gPodder does today in this case. 1.c) Two episodes share the same download (enclosure) URL, but have different GUIDs (see Electronic Explorations example mentioned in comment #2) Although this could be a misrepresentation of an episode update (like Case 1.a), there is no way to be sure that this is the intention. Nonetheless, both episodes could share the enclosure download (which is easy in this case, as both episodes share the same download directory). Alternatively, they could be handled like entirely separate postings with separate downloads, taking duplicate downloads into account (and relying on the user to avoid them). gPodder currently shares the download status in some cases (enclosure is currently being downloaded) but not in others (episode has been downloaded), which I find confusing. The actual download is never shared: gPodder creates two different downloads with unique names. 2. The episodes are from different podcasts =========================================== 2.a) Two episodes share the same download (enclosure) URL _and_ the same GUIDs (see dradio.de example in comment #2) For lack of a better word, let's call this a “crossposting.” gPodder currently hides all crossposted episodes but the one it discovers first. This seems rather arbitrary and confusing; it does not adhere to the principle of the least surprise. It could be argued that crosspostings should be handled as in Usenet readers: all crosspostings share their status; mark all crosspostings as old as soon as one is marked as old. The counterargument is that, unlike in Usenet, RSS crosspostings are not discovered until an actual duplicate is found in one of the feeds. With the shared-status scheme, a user who's interested in one feed might miss an episode when it is crossposted to another, more boring feed the user habitually marks as old. So I believe that it would be most logical of gPodder handled the status separately for each episode, but still would be able to share the actual download. But that would imply that gPodder has to be able to share enclosure downloads across multiple podcast directories. (See below for an implementation idea.) The second best solution is to handle crosspostings entirely separately. 2.b) The two episodes share the same GUID, but have different download (enclosure) URLs Strange, shouldn't ever happen unless a crossposted episode is updated in one feed but not (yet) another. I think the correct interpretation is that these episodes and their downloads are entirely separate from each other. Not sure what gPodder does today in this case. 2.c) Two episodes share the same download (enclosure) URL, but have different GUIDs Two separate postings referring to the same attachment. As in Case 2.a, ideally both episodes share the actual enclosure download (but not the status); the second best solution is to handle both entirely separately. gPodder currently seems to implement the second solution. The previous solution (gPodder 2.4?) was to share the download status but not the actual download, which I considered broken. Summary ======= I think sharing the status is never appropriate unless an episode is updated (Cases 1.a and 1.b). It would be great if gPodder could transparently share enclosure downloads among multiple episodes with the same download URL. A simple implementation on Unix-like systems could just create a hardlink when the user attempts to download an enclosure that already has an existing download. (The advantage over creating hardlinks automatically at episode-discovery time is that this method does not burden the user with getting rid of a download she never wanted.) This new feature would probably raise a few new minor issues, but I think they could all be addressed easily. The following comes to mind: * A user may want to fix a broken download by deleting it and downloading it again, which would just recreate the hardlink if there was another copy of the download around. This problem could be alleviated by adding a “delete all instances” function. -- 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
