GNOME Bugzilla – Bug 331942
Automatically delete old podcasts
Last modified: 2018-05-24 11:27:07 UTC
It would be nice to have a dialog in which preferences about each podcast's retention policies could be set. For example, my NPR hourly news podcast should be limited to 1 old download, while I'd like my BBC digital week feed to automatically get rid of all downloads older than 1 month. These policies might be enforced every time the "update all feeds" menu item is selected.
I would like to see that too. Another thing I would like would be when you refresh the list, the newest podcast should not download automatically.
Created attachment 90953 [details] [review] remove no-longer-available episodes that have not been downloaded not that it really addresses the above concerns, but it's a useful thing to do.
Can we split/clone this "bug" to deal with the both issues listed here? 1. Podcast retention policies. I currently have a crontab-job to do this. It deletes podcasts based on the number of podcasts per channel and the total size of files in the channel. The addresses Travis concern. 2. Add a setting in the preferences to automatically download (or not to download) the latest available podcast. Man can also specify the number of podcast to automatically download, in case the user want to catch up with the x latest podcasts in a channel and not only the latest one. This should deal with Bruce's request.
*** Bug 510273 has been marked as a duplicate of this bug. ***
The patch had been rotting for long enough, so I committed it.
I don't see it in my version of Rhythmbox, so I think this bug should be set as "confirmed". I tend to download podcasts that I do not nec. listen to, but I like using Rhythmbox as a downloader/manager/access mechanism. Much like DVRs these days, the expiration would be very useful. Expiration is useful for a) conserving disk space b) making the current listing and search of podcast less "diluted" and more relevant/timely. Rhythmbox 0.11.5 Gnome 2.22.3 Distro: Ubuntu 8.04 Hardy Heron
I think expiration should be handled flexibly, as miro does it. In miro, you can choose that watched expisodes are deleted after a certain period, by default 5 days, additionally, you can configure miro to stop downloading new episodes from a given channel, if a certain number of episodes in that channel is unwatched. So you don't have to fear that your hard disk will overflow, Last, in miro you have two lists: one of total items in a channel and a list of downloaded items. This is so much better than in rhythmbox, because it allows you to re-download an old episode, which you have deleted before. In rhythmbox, deleted episodes vanish from the list. There is no way to download them a second time. This is especially annoying for episodes which have been downloaded incompletely. There is now way to complete the download other than deleting it from the list, unsubcribing from the feed (because after deletion, the episode is no longer shown in the list), re-subscribing and re-downloading everything. All this together made me switch to miro for podcasts. Miro sucks in many ways, it is hoggish and buggy, but its handling of podcasts is still infinitely better than that of rhythmbox.
I dont understand why if a patch is available this has not been implemented. I suggest the solution should be changeable here: 1. As a preferences entry for all podcasts 2. In the properties entry for every podcast source I think this is a major problem, because the podcasts can fill up the hard disk quite soon if you have a lot of big podcasts. And since this bug is from 2006 I think 4 years are a lot of time. Is there actually a huge problem implementing this?
(In reply to comment #8) > I dont understand why if a patch is available this has not been implemented. The patch was committed a year and a half ago. It did not implement this feature. > I think this is a major problem, because the podcasts can fill up the hard disk > quite soon if you have a lot of big podcasts. Honestly, this sounds absurd to me. How many podcasts would I have to subscribe to in order to fill up a 500G disk? > And since this bug is from 2006 I think 4 years are a lot of time. Is there > actually a huge problem implementing this? Only lack of time and interest.
(In reply to comment #9) > > I think this is a major problem, because the podcasts can fill up the hard disk > > quite soon if you have a lot of big podcasts. > > Honestly, this sounds absurd to me. How many podcasts would I have to subscribe > to in order to fill up a 500G disk? Well, podcasts are of course not the only thing eating up disk space, but the same is true for any other kind of data. As for me, the lack of this functionality has been the reason why I switched to Miro for Podcast management. Please look at how it manages auto-downloads, stops auto-downloading new episodes if there is a particualar number of unwatched new episodes, configurable expiry times for watched episodes etc. The problem with miro is that it is a resource hog. I would very much prefer rhythmbox, but its podcast management is just too rough to be really fun to use
I started using a script to download podcasts, because the rhythmbox functionality just doesn't work for me. It might be OK for a few podcasts, but not if you really start using it.
Please don't turn this into a general complaint forum. I'm sorry that rhythmbox's podcast support doesn't work well for you, but this isn't the place to talk about that.
(In reply to comment #9) > Honestly, this sounds absurd to me. How many podcasts would I have to subscribe > to in order to fill up a 500G disk? Not everybody has a 500G drive and not everybody wants to have it full of obsolete podcasts. @Jonathan I have asked number of times at rhythmbox devel list about a Python methods how to get a list of all podcast issues in Python. I have never got any reply. http://live.gnome.org/RhythmboxPlugins/WritingGuide seemed to be awfully incomplete on podcasts.
@Jonathan 1) Well one episode might have 100MB - you have 10 podcasts of that sort, makes 1 GB maybe every week, in one year 52 GB 2) Also it might not fill hup the whole disk alone - but its sufficient if your 500 GB disk is filled to 90% and you struggle to clean up every unnecessary bits (I for one have to do this on my notebook, having alway < 10 GB available ). The problem is that RB forces you to do this extremely simple task by hand, which is something many users would happy to let be done automatically. Also I guess there are many users with small devices which have not even 50 GB of space. It would be cool if somebody or you could implement on this thing when you have some time. I think its worth it.
I'm not saying I don't think this is a worthwhile feature (I'd probably use it myself), just that "users might accidentally fill up their disks" is a poor argument for it, especially as the default would probably be to retain podcast episodes indefinitely.
I was bugged by this and had some time to scratch the itch. I've been implementing it by adding a "keep" column to the podcasts episode list that is initially unset. After a set time period (I just have a combo box with day, month, and year in it (maybe week would be good too?)) from their download time, RB will just delete them. I really don't think people need completely tunable times for this. If the 'keep' column is checked, then the purging code will ignore that episode. Does anything about that sound horrible to people? I just need to implement the timer and the deleting at this point.
Created attachment 157727 [details] [review] Add periodic podcast purging to RB Hopefully I didn't mangle all of this trying to make git work with me... This adds time-base podcast purging (day, week, month, year) and the ability to check a little box to save episodes from being deleted. It certainly needs some cleanup, but, I'm about as far as I can get on my own. Problems: Something isn't right with my new column and checkbox a la: (rhythmbox:968): GLib-GObject-WARNING **: unable to set property `active' of type `gboolean' from value of type `RhythmDBEntry' Could someone please check my deletion logic? Everything seems to work fine to me, but I'm sure I'm doing something wrong there. Also, my end goal was to put the post entry back into a 'pre-downloaded' state, so the user can easily re-download a post as desired. Right now, I reset the post status and set the RHYTHMDB_PROP_LOCATION to NULL.
Review of attachment 157727 [details] [review]: I'm not sure there's much value in having separate processes for updating podcasts and removing old episodes. Why not combine them? ::: data/rhythmbox.schemas @@ +726,3 @@ + <default>1</default> + <locale name="C"> + <short>Unit to apple to purge_interval</short> misspelled 'apply'? ::: data/ui/podcast-prefs.ui @@ +170,3 @@ + <property name="visible">True</property> + <property name="xalign">0</property> + <property name="label" translatable="yes"><b>Purging</b></property> generally we keep text attributes out of the translatable strings. since we depend on gtk+ 2.16 now, you should be able to use the separate text attribute settings in glade instead. ::: podcast/rb-podcast-manager.c @@ +2308,3 @@ + rb_podcast_manager_delete_download (pd, entry); + rhythmdb_entry_set (pd->priv->db, entry, RHYTHMDB_PROP_STATUS, &undownloaded); + rhythmdb_entry_set (pd->priv->db, entry, RHYTHMDB_PROP_LOCATION, &nolocation); What you need to do here is move the remote location from the mountpoint property back to the location property - opposite of what happens when you download an episode. Setting the location to null will cause weird database breakage. ::: rhythmdb/rhythmdb-private.h @@ +52,3 @@ 103: pause */ gulong post_time; + gboolean mark; Could probably use a bit in the 'flags' field to hold this instead, since it's probably useful across multiple entry types. It could be used for audio CD entries right now, since we have a checkbox column there used to select tracks to extract. To do this, we'd add RHYTHMDB_ENTRY_MARKED to the enum above 'struct RhythmDBEntry_' in rhythmdb-private.h and implement RHYTHMDB_PROP_MARKED similarly to RHYTHMDB_PROP_HIDDEN. ::: sources/rb-podcast-source.c @@ +1618,3 @@ +static void +rb_podcast_source_post_mark_cell_data_func (GtkTreeViewColumn *column, could move this into widgets/rb-entry-view.c once RHYTHMDB_PROP_MARKED is implemented using a flag bit, so it would be available to any source using it @@ +1637,3 @@ + +static gint +rb_podcast_source_post_mark_cell_sort_func (RhythmDBEntry *a, could move this into rhythmdb/rhythmdb-query-model.c along with the other sort functions too @@ +2300,3 @@ } +<<<<<<< HEAD remove this @@ +2306,3 @@ return g_strdup ("EditDelete"); } +======= and this @@ +2308,3 @@ +======= +/* Purging code config callbacks */ +>>>>>>> 926b188... Contuing work on stuff... interface now done, need to make the timer and purging code and this
-- 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/157.