GNOME Bugzilla – Bug 557985
multiple entries for same podcast episode
Last modified: 2011-12-22 03:24:46 UTC
Please describe the problem: occasionally (or in case of one of my podcasts every week), the podcaster will make corrections to the rss feed. In Banshee this means that I end up with the same episode listed twice, sucking up diskspace, bandwidth. As such I would love for the case of episode renaming to be handled nicer or at least that an option to remove all trace of a single episode be added. This would at least allow me to manually clean up the mess. Steps to reproduce: 1. subscribe to podcast 2. wait for podcaster to realise he made a mistake and enter a correction Actual results: watch in horror as you now have cloned your podcast episode Expected results: just one episode, corrected and updated Does this happen every time? hard to tell, if works you never notice it but it happens very often so I assume 100% Other information: x86_64, da_DK.UTF-8, Fedora 10, Mono 2.0.1
I have very same problem with even latest banshee 1.4.1. Steps to reproduce: 1. Subscribe to podcast 2. Download all episodes 3. Close banshee completely 4. Remove banshee config files: rm -rf $HOME/.config/banshee-1 5. Start Banshee again 6. Subsribe to feed again and observe what's going on in $HOME/Music/Podcasts/ folder Banshee blindly downloads the same episodes. Files have the same tags, file size and so on. The only thing it does it adds extra hash to filename. This makes such mess. What I'd like to see: - Banshee finds file and asks me if that's the one I want to use. Could be even more clever and check filename, size and tags and if the same as file on disk use it. - Banshee also will forget all your old files that already are not in the feed (are too old) but you have them on disk. My system is Ubuntu 8.04 with banshee-1 from launchpad.
This issue is beginning to drive me nuts... :( Banshee should - just "blindly" add episodes with a newer date - for episodes with older dates, check if the same filename was already added, if yes, check if the discription etc changed, if yes, just update that
Bulk changing the assignee to banshee-maint@gnome.bugs to make it easier for people to get updated on all banshee bugs by following that address. It's usually quite apparent who is working on a given bug by the comments and/or patches attached.
The original bug would seem to be a problem with the RSS feeds, but it can be a huge problem. The feeds should have a unique ID identifying the particular episode. That ID should never change, but some podcasts do not do this properly. Podiobooks.com has free audiobooks distributed by podcast, but their RSS feeds are all broken. They redate (and likely regenerate the ID) for all episodes in the feed when a new episode is released. Subscribing to any on-going Podiobook feed will demonstrate this problem as soon as the author adds a new episode. (Usually once a week.) Never redownloading files presents issues when a podcast accidentally publishes a broken episode and then goes and fixes things. The file would show up with the same name in the feed, and if you always never download duplicates there will be no way for the user to get the updated file. (Unfortunately while you can try checking for changes in the media length some podcasts -- like Podiobooks.com do not present an accurate length. Additionally, if the problem was an issue of mixing you wouldn't expect a difference in length.) It would be nice if Banshee could indicate when an episode is updated without automatically redownloading it. This would be the ideal solution when dealing with the original issue as you could ignore it if it was a metadata change and you could act on it if it was a broken episode. In the short-term I'd like to have an option to specify that a particular podcast should ignore duplicate enclosures. Of course, to obey GNOME human interface guidelines you probably can't present a checkbox and instead need to trigger the behavior when a podcast fails to contain an existing episode and yet the enclosures have the same names as existing files. Even with the ideal solution in place, you may want to keep this check in place and then squash the updated-episode feature if the entire feed appears updated. I would like podcast enclosures sitting in an existing directory to be added to Banshee, (as described by Marcin), as that would ease migration from existing podcatchers. Depending on the podcast, folks may go back through and listen to all the episodes from the beginning. Also, in some cases the early episodes may no longer be available in the feed and you'd need to download them manually. This sounds like a different issue than the feed issue, though.
*** Bug 625057 has been marked as a duplicate of this bug. ***
Closing in favor of bgo#577982 which seems to track the same issue but has more information. Thanks for the bug report. This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find. *** This bug has been marked as a duplicate of bug 577982 ***
I would like to note that this does not seem to be a duplicate of bug 577982. In fact it seems to be quite the opposite: Bug 577982 is that Banshee is duplicating items on the list of podcast episodes available for a feed. If you download, archive, or delete one, it deletes the other, so the duplicate acts like a symlink and there is only one file, but the feed <item> shows twice (or more) in Banshee. This bug, 557985 is that Banshee is actually downloading, renaming, and storing duplicate files of the same podcast <item> whenever the correct conditions are met.