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 479897 - Podcast containing m4a always returns failed upon download
Podcast containing m4a always returns failed upon download
Status: RESOLVED FIXED
Product: rhythmbox
Classification: Other
Component: Podcast
0.11.x
Other All
: Normal normal
: ---
Assigned To: RhythmBox Maintainers
RhythmBox Maintainers
: 559002 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2007-09-24 17:27 UTC by David Nielsen
Modified: 2009-06-08 10:42 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description David Nielsen 2007-09-24 17:27:50 UTC 
Please describe the problem:
I've seeing a problem when adding podcasts that contain m4a files rather than mp3/ogg files. Rhythmbox will download the song then instead of listing it as done it will list it as failed. Once downloaded the file will play however the statusbar will always be at 100%. 

An rss feed for testing can be found here:
http://www.quackcast.com/QuackCast/Podcasts/rss.xml

Steps to reproduce:


Actual results:


Expected results:


Does this happen every time?
100%

Other information:
Running Fedora 8 (Development) on AMD64 using the da-DK.UTF-8 locale.
Comment 1 Jonathan Matthew 2007-09-30 10:18:42 UTC 
The problem here is that the podcast episodes contain images as well as audio.  The metadata reader only likes files that only contain audio.  Unfortunately that code is awfully brittle.
Comment 2 Jonathan Matthew 2008-11-02 23:06:42 UTC 
*** Bug 559002 has been marked as a duplicate of this bug. ***
Comment 3 Tim Jackson 2009-03-15 15:19:55 UTC 
I still get this on 0.11.6/Fedora 10. It happens too with some video podcasts. It's a real shame because in other ways they play fine (including video podcasts using the Visualisation plugin), but because Rhythmbox thinks it failed, it's not possible to skip through the tracks (the play position bar is disabled).
Comment 4 Jonathan Matthew 2009-06-08 10:42:25 UTC 
I've fixed this as part of a set of metadata reader changes; now we don't check file types on podcasts at all.  Some time soon I'll add some special handling for video and non-audio (pdf, for example) podcast items, probably to launch them in applications that can actually handle them properly.