https://bugs.gpodder.org/show_bug.cgi?id=1107

sideral <[email protected]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|CLOSED                      |UNCONFIRMED
         Resolution|WORKSFORME                  |

--- Comment #4 from sideral <[email protected]> 2010-08-24 20:31:31 BST ---
(In reply to comment #2)

Thomas,

Thanks for responding.  May I suggest to keep this bug open for the duration of
this discussion?

> This is not planned, as the feeds are to blame in this case. If the
> episode disappears and then re-appears, the intention of the feed
> author might even be that they *want* it to re-appear as new (yes,
> some feed authors re-use URLs - not good, but we have to handle that
> too).

I strongly disagree with this reasoning.

Yes, a feed may reuse the same download URL for another episode. However, it
should assign a new GUID in this case, and this is how the feed reader
recognizes a new episode -- not by way of a newly appearing episode, which may
not even appear as new to a feed reader that missed the intermittent absence of
the episode.

In other words, feeds that reuse URLs _and_ GUIDs and rely on the feed reader
to recognize a new episode through temporary absence are even more broken than
those that sometimes do not deliver the complete list of episodes.  I believe
gPodder should be more forgiving towards the latter, true to the Internet
mantra of "Be liberal in what you accept, and conservative in what you send"
(Jon Postel).

Also, the behavior I'm requesting is implemented by any other respectable feed
reader that I know about.

> [...]
> (We remove episode metadata as soon as it disappers from the feed in
> order to have a performance and space gain on low-powered devices such
> as mobile phones and tablets.)

I do understand this concern.  That's why I proposed a user-configurable
timeout value (defaulting to a period such as 30 days) after which old episodes
would be deleted.

Also, you forgot to address my other concern (from comment #1): Another side
effect of gPodder forgetting about disappearing items too soon is that such
items will not be deleted from an MP3 player during synchronization should they
happen to still be on the MP3 player.

-- 
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

Reply via email to