After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 356604 - Podcast files misnamed
Podcast files misnamed
Status: RESOLVED DUPLICATE of bug 330766
Product: rhythmbox
Classification: Other
Component: Podcast
0.9.x
Other All
: Normal normal
: ---
Assigned To: RhythmBox Maintainers
RhythmBox Maintainers
Depends on:
Blocks:
 
 
Reported: 2006-09-18 18:41 UTC by Veronica Crabtree
Modified: 2006-09-18 23:06 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Veronica Crabtree 2006-09-18 18:41:08 UTC
Please describe the problem:
Several podcasts I listen to have the same file name for each cast. For example http://feeds.theonion.com/theonion/radionews. The files all get labeled as "podcast_redirect.mp3". The old casts are (mistakenly) overwritten. 

Steps to reproduce:
1. Add http://feeds.theonion.com/theonion/radionews to the podcast list
2. Play one cast.
3. Download the next pod cast.
4. Play the first again, it will be the new cast.


Actual results:
The audio is of the second cast, not the first

Expected results:
It plays the original podcast. All podcasts are named uniquely.

Does this happen every time?
Yes, if you follow the steps.

Other information:
Have a list of steps the plugin goes through to name the file uniquely:
1. Using the 'link' tag.
2. By using the HTTP 'filename' header. 
3. Serial Numbering.

As more cases arise, you can prepend the list with more ways of naming a file uniquely. Serial numbering should be a last resort. You could also have an option in each podcast to specify how to name it 'Auto', 'HTTP filename', 'Incremental numbering', 'date'. And of course default it to Auto to give it sane functionality.
Comment 1 Jonathan Matthew 2006-09-18 23:06:56 UTC
We've fixed this in CVS by always using the filename component of the final download URL.  This works for every feed I've ever seen.  If you can find one that still exhibits this problem with CVS HEAD or 0.9.6 (when released), please reopen this bug.  I'd be very reluctant to add per-feed options to determine downloaded file names (which should more or less be invisible).

*** This bug has been marked as a duplicate of 330766 ***