New podcasts overwrite existing files if filenames coincide

[lapseofreason]

Some feeds give all their audio files the same name (e.g. http://rss.sciam.com/sciam/60-second-earth). This will lead to AntennaPod overwriting the existing audio file when a new episode is downloaded, so basically only one episode can be present at any time.

[danieloeh]

I have made some changes to how the downloaded files are named and made sure that they are named differently (for example episode-1.mp3 if episode.mp3 already exists) if necessary.So it should work in the next version of the app.

[lapseofreason]

Thanks a lot, I will do some testing when the next version is out.

[lapseofreason]

I just tested Antennapod-issue47.apk and it now correctly uses a different name if the name already exists, thanks!

[oaubert]

I still have the same issue, using for instance feed http://radiofrance-podcast.net/podcast09/rss_10867.xml : media file enclosures all have the same advertised name, even though they point to different URLs. Antennapod just uses the advertised name and overwrites previous episodes.

Looking at the DownloadRequester.java code, code seems to be in place to avoid this, but could this be a concurrency issue ? This happened during my migration from google listen to antennapod, so I downloaded multiple medias almost at the same time. If a download is enqueued but not started (with a given filename) when a second download of the same stream (different episode, but same filename) is initiated, the " if (dest.exists()) { " test will not succeed, since the first download has just been registered but not started, and this could lead to filename overwriting.

[oaubert]

After further testing, it looks like the bug is indeed closed: I noticed it on 0.9.5.3, and thought to still see it after upgrading to 0.9.6, but in fact I was just confused by some remaining downloads from the previous version. Sorry for the false alert, and thanks for the great app. I am looking forward to finding some time to contribute.

[danieloeh]

I just tried to reproduce the problem you had and it turns out that you have to enqeue more downloads than the maximum number of parallel downloads (which is 4 at the moment) for this bug to occur. So the problem is that the DownloadRequester isn't checking if any of the pending downloads has been given the same filename as the one which is being requested.