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 436610 - How do I delete podcast files without deleting them from the list of available podcasts?
How do I delete podcast files without deleting them from the list of availabl...
Status: RESOLVED OBSOLETE
Product: rhythmbox
Classification: Other
Component: Podcast
0.10.0
Other All
: Normal enhancement
: ---
Assigned To: RhythmBox Maintainers
RhythmBox Maintainers
: 510275 536654 620478 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2007-05-07 14:46 UTC by jjvenkit
Modified: 2018-05-24 12:33 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description jjvenkit 2007-05-07 14:46:59 UTC
I don't have a lot of space on my laptop's harddrive. So I would like to delete some podcast files that I've downloaded with Rhythmbox. But I want to be able to redownload them later. If I right-click on the podcast in Rhythmbox and choose delete, the file AND entry disappear. I only want to delete the file. Is it currently possible to do this with the GUI?  I'm willing to edit the rhythmbox.xml, if that's what it takes.  But this seems (to me) to be a handy feature to have.

Other information:
I'm using Ubuntu 7.04 (Feisty Fawn).
Comment 1 Jonathan Matthew 2007-07-01 13:48:31 UTC
I think the current podcast delete options are backwards.  I don't see a use case for deleting the episode from rhythmbox but leaving the downloaded file in place, but here you've described one for deleting the downloaded file without removing the episode from the UI.

In addition, deleted episodes are added again next time the feed is updated if they're still present in the feed.  Instead, deleted episodes should be hidden, with some way of unhiding them.  An item in the feed browser context menu, maybe.
Comment 2 Jihad Daoud 2007-07-27 13:38:34 UTC
(In reply to comment #1)
I think that Jonathan's suggestion is better. Can we allocate and use a status code (if possible) for this?

We can then add a setting in the preferences that unhide/hide the deleted podcasts . The verey same setting should be accessible when right clicking on the podcast channels as well when right cklicking on the podcast icon in the source list. The hide/unhide should not be a per channel setting but a global setting for all podcast channels.
Comment 3 jjvenkit 2007-12-06 15:08:06 UTC
I agree.  We're up to Rhythmbox 0.11.2 now, is there anything in gconf that could be manually set to allow the episode and file to be handled separately or will this require some coding and a patch?
Comment 4 Jonathan Matthew 2007-12-06 21:43:43 UTC
As far as I am aware, no one has done any work on this.
Comment 5 nachodelosrios 2008-06-03 12:53:35 UTC
(In reply to comment #1)
> I think the current podcast delete options are backwards.  I don't see a use
> case for deleting the episode from rhythmbox but leaving the downloaded file in
> place

I agree with that. I see no use in deleting the index entry but keeping the sound file, and moreover, it is then extremely difficult to locate the soundfile and play it again with Rhythmbox.

The nomenclature is far from clear, too. What is exactly "the episode" and what is "the file"? Does the file include all episodes?

> In addition, deleted episodes are added again next time the feed is updated if
> they're still present in the feed.  Instead, deleted episodes should be hidden,
> with some way of unhiding them.  An item in the feed browser context menu,
> maybe.

That does not happen in my case. Once the episodes are deleted, they are gone for good, and only new episodes appear when the podcast is refreshed. Some hidden gconf option, maybe? If the full episode list reappeared with the refresh it would be easy to clear space, but then reload when desired.

Comment 6 nachodelosrios 2008-06-03 12:58:52 UTC
As for the hide/reveal deleted episodes option, wouldn't it be clearer if we could just set a limit on how many not-currently-loaded episodes were shown?
Comment 7 Jonathan Matthew 2008-06-04 22:58:45 UTC
*** Bug 536654 has been marked as a duplicate of this bug. ***
Comment 8 jjvenkit 2008-06-27 13:34:36 UTC
As the OP, my `bug' was that I could not:
1. delete the mp3 file from my harddrive AND
2. still see the podcast entry in rhythbox

It is the ability to continue to see the full list of podcast entries that I had wanted.  I want the harddrive space from deleting the mp3 file BUT I want to still see the podcast entry listed with all the other podcasts.

For this, the delete option would work like this:

right-click
delete
choice 1. delete only the file
choice 2. delete file and podcast entry

Definitions:
mp3 file: the mp3 file on the harddrive
entry: the line item displayed by rhythbox--this may be called a title
Comment 9 Jihad Daoud 2008-06-27 14:08:45 UTC
I can't see why we would like to delete an entry, it's a job of the content provider right? We only update the podcast channel and then the entries are updated according to the content provider setup.

Anyway we can end up in a situation where a content provider deletes an entry but a user have it on her/his HD. In that case we shal not delete the entry until the corresponding file is removed from the HD.

I.e. The right-click Delete always delets the corresponding file and not the entry, unless it's removed by the content-provider.  
Comment 10 Kalin Agrawal 2008-10-23 19:34:44 UTC
FYI:
I think the UI etc. should take into account the podcast expiration Bug 331942.  These are very similar and the user (me!) will be confused if there are different points of entry to adjusting  settings wrt deletion and/or expiry.
Comment 11 Jonathan Matthew 2008-11-23 10:46:29 UTC
*** Bug 510275 has been marked as a duplicate of this bug. ***
Comment 12 Jonathan Matthew 2010-06-03 13:35:58 UTC
*** Bug 620478 has been marked as a duplicate of this bug. ***
Comment 13 GNOME Infrastructure Team 2018-05-24 12:33:50 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/rhythmbox/issues/368.