Global setting for podcast download limits

[drmrbrewer]

At the moment, each individual podcast has settings for the maximum number of episodes you want downloaded for that podcast. Whilst I can see that it is useful to have a per-podcast setting, I can't help feeling I'd like to be able to set this globally as well. Individual podcasts could override the global setting, if desired. Generally, I want the same setting for all podcasts, and not necessarily the default that is set by the developer. It's a hassle having to go into each and change.

On the same topic, would it be reasonable to have a "podcast length" limit, rather than a number limit? The only reason I want to limit podcasts downloads is because of limited space (and limited bandwidth)... if I had infinite storage and bandwidth I'd want all episodes downloaded and available to me.

So to me it makes sense to limit based on podcast length (or podcast size, but that means a lot less to the average user than length), because that more closely relates to size (a podcast could be any arbitrary length). I know there isn't an exact correlation between length and file size, but it's better than that between number and file size, I think.

Some podcasts spew out very short episodes, while others spew out longer ones. A per-podcast *length* limit would mean that you could apply it as a global setting that would be a reasonable choice for all podcasts. For the shorter ones, you download more. For the longer ones, you download fewer. That's generally how I judge what number limit to use at present.

Of course, some podcasts are more interesting to the user, and you could then override the global setting and say you want to download up to 2 hours' worth instead of the default of 30 minutes.

Just some thoughts.

Mike

[jzamoras]

I second that.

[marwatk]

I'll definitely add something like this to my todo list, it's a great idea. Though it may be based on file size instead of length, since that's really the crux of the problem... storage space. (Plus, it's MUCH easier for me to see, for length I'd have to feed everything through the media player, which I'm hesitant to do for complexity reasons).

Would that work? Basically something like, "Keep XXmb of episodes for this podcast"

-Marcus

[drmrbrewer]

That woul serve the purpose. However, just thinking from a user perspective, everyone knows what a minutes worth of podcast is, but few people would really know what a megabyte's worth would give them. A minute is more meaningful than a megabyte in this situtation, although I agree that directly setting MB is an easier way to control memory useage.

Mike

[ag5bpilot]

personally, I'd prefer it to be in megabytes. There's a huge difference in MB/min between the different podcasts I download, and pretty much, the number of episodes I get of each is determined by the storage requirements. NPR's audio podcasts? I'll DL a few hours worth. JPL's video podcasts? An hour, at most. 60 second science? I'll DL all of those. It's a matter of space, not time. If I had a big enough SD card, I'd just DL every episode and let them sit in the berry until I get around to them. From my perspective, it's just the storage.

Here's how I would do it:

1) Global setting: Keep at least XXXX MB free. Lets you set the amount of free space to keep.
2) Global setting: Preferentially download [audio|video|none]. - download one type before the other.
2a) Per podcast setting: Add setting for overriding this setting [use-default|audio|video|none]. (I'm not sure if I would use this, but perhaps that's just a failure of my pre-morning-caffeine ability to dream up a use case for it.)
3) In the current per/podcast settings for DL and Keep numbers, add an ALL option.

What I would do with these setting is set 1) to 1024 (1 GB), 2 to Video (or maybe none), and 3) to ALL for both. Podtrapper would then spread the DL's around the podcasts (could just DL round-robin) until I'm down to a gig of free space.

Round robin isn't how Podtrapper works now. It could work like this:

A) Have we reached the limit yet? If yes, we're done.
B) Select the set of podcasts that have anything to download, based on whether there there's any undownloaded podcasts remaining.
C) From the set in B, remove any podcasts whose next DL is too big and would drop free memory below the limit.
D) Is the set of podcasts empty? If so, skip to step F.
E) Download ONE episode from the set. Remove this podcast from the set (so only one episode gets DL'd).
E) Go back to step A and repeat.
F) See if there are any podcasts who have something still to download AND the next download is small enough to fit in the remaining allocated space. If so, go back to step A and repeat the process. Otherwise, we're done.


Edit:

I realized after posting this that there's two flaws in the above algorithm. That's what you get for designing code before you're fully awake.

The first problem is that it doesn't take into account the [video|audio] preference. That's easily solvable. If a preference is set, run the algorithm with ONLY that type of podcast first and then, if space remains, run it a second time for the other type of file. If no preference is set, run the algorithm only once for all files.

The second problem is a bit harder to solve. If a podcast has a particularly huge episode (I've seen video podcasts in the half-gig range), it won't get downloaded, and anything behind it in the queue in that podcast won't get downloaded either until enough space gets freed up on your berry. That, in turn, won't happen until all backlog queues of episodes are downloaded. Put simply, a huge episode will block a podcast from downloading anything until all other podcasts have nothing in their not-downloaded (scheduled or un-sheduled) queues.

I wonder when 32 gig micro-SDHC cards go on sale???

Mike

[drmrbrewer]

I can't disagree that using a MB limit is the most direct way of controlling storage (I made that point myself), I just think that using minutes is more appropriate for normal people, and better suited for a global setting. For Example, setting a MB limit that gives a decent amount of audio would provide insufficient video. I personally want to be sure I have just enough to occupy me for the hour's train journey I do each day (hypothetically), and how on earth that translates to MB is impossible to tell.

Sounds like it would be difficult to do a time limit anyway, and a global space limit would be better than nothing.

Mike

[marwatk]

I think what I'm probably going to do is base it on size, but display the sizes in library of congress type units.

For example:

Limit this podcast to approx: [1h audio, 10m video (30mb)] | [2h audio, 20m video (60mb)], etc...

I'll have to try to come up with what the approximate conversion is, maybe I should go read some hard drive boxes

What do you think?

-Marcus

[ag5bpilot]

I've found that 1 min ~= 1 MB of audio and ~= 10 MB of video.

That's a rough estimate, of course, and varies according to the bitrate for audio and the resolution for video. I've seen some videos that were more like 20MB/min, but, hey, they berries can't play those higher rez videos anyway.

[Geoff]

Not sure this is in reference to limits but i would like to see global settings for how often the program checks for new episodes. It's cumbersome to set it for each one, esp when you have a lot.

[marwatk]

Hi Geoff, what frequency do you usually set them to?

-Marcus

[Geoff]

Hi Geoff, what frequency do you usually set them to?

-Marcus

Marcus,

I usually set it to pull them all at the "four hour" interval. I would like to not have to edit them all individually, but i'm just now updating to 1.6.7 from 1.6.6. If this has been addressed please disregard this post.

- Dana

[marwatk]

Hi Dana,

Just as an FYI, the next version (probably 1.7.0) will have settings definable that apply to new podcasts, will that work?

-Marcus