GNOME Bugzilla – Bug 507541
Error message on Edit - Preferences because Podcasts dir does not exist
Last modified: 2008-09-07 01:31:40 UTC
Please describe the problem: Rhythmbox by default sets ~/Podcasts as the default directory where podcasts will be downloaded. However, it seems Rhythmbox does not create this at first startup. When I go to Edit - Preferences just after I started Rhythmbox for the first time, an error message pops up stating that the Podcasts directory does not exist. Steps to reproduce: 1. Start Rhythmbox for the first time in your user account 2. Go to Edit - Preferences Actual results: The error "error accessing 'file:///home/frederik/Podcasts/': File not found" appears Expected results: Rhythmbox should just create the directory instead of complaining. Does this happen every time? Yes, if you have not yet created that directory (for example the first time you start Rhythmbox in a fresh user account) Other information: It would be even better if the default directory would be a podcast subdirectory in the xdg-user-dirs Music directory: http://freedesktop.org/wiki/Software/xdg-user-dirs But that change does not fix this bug: whatever the directory is, it should create it instead of complaining if it does not exist.
I can reproduce this problem also under Gentoo, with a new user account or after removing configuration directories
Just run the Gusty live CD or install the system and this also happens. Quite annoying and I don't know but creating a ~/Podcasts at first startup is not a solution becaus I don't even use podcasts, I don't want a folder in my home that has no use. In fact I should be able to disable the podcast list in Rhythmbox. Just like any other plugins.
Then perhaps you'd be interested in helping convert the podcast code into a plugin. See bug 323057.
I would propose to check if the directory exists only when a podcast is added or downloaded and when the user visits the Edit - Preferences - Podcasts tab. If it does not exist, Rhythmbox can ask the user whether this directory has to be created. If the user answers no, then cancel the podcast add/download, and never ask the user again, except if he later tries to add a new podcast again. I guess such a mechanism would be needed even if podcasts would be a plug-in, because you can never exclude that a user did not removed the podcasts directory by hand.
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 357768 ***