[General Topics] Menneisyys:
Symbian

With AudioBay’s Symbian S60 version discontinued (because of Nokia’s app’s release), Nokia Podcasting has become THE podcasting app for all S60 v3 phones. It’s generally very well done, fast at downloading and only lacking in some advanced features like channel image view.

It offers pretty nice, pre-configured choices, parallel downloading (of course, it allows for multiple selection with the Key button + the up/down arrow):

, automatic scheduling. However, it isn’t capable of parsing generic URL’s like that of MoDaCo for feeds. In these cases, you must enter the URL directly in Podcasts / Options / Go to Podcasting / Podcasts / Options / New Podcast:

Don’t forget to set your storage card as the download target at Podcasts / Options / Go to Podcasting / Options / Settings / Download:

The chart

As with most of my generic bible / roundup articles, the focal point of this bible is the feature chart, which makes it possible to pack in as much information in an article as possible, also allowing for direct, easy comparison between the different solutions. As usual, you’ll want to maximize it and, on smaller-resolution screens, zoom out to avoid (excess) scrolling. Sorry for the size: as usual, I wanted to present a full roundup; hence the gigantic size. The chart is here.

Explanation

Today / home plug-in showing the number of new podcasts etc. (NOT just a start / stop / pause control, with the song title, of the currently playing track!): some podcatchers also display the number / title(s) of newly downloaded podcasts (or simple articles).

Does it allow for user-def’d podcast categories?: more advanced catchers allow for organizing podcast feeds into user-defined categories. If you have more than a handful of feeds, this capability can prove VERY useful.

Feed login/password?: there are some private feeds requiring a login/password pair to only allow authenticated users to access their content. Almost all podcast/catchers support this.

Terminology used: particularly if you test more than one app, you may run into terminology inconsistency problems. For example, feeds are referred to as “Channels” by many. Feed contents are generally referred to as “items”, “headlines” or “episodes”. In this row, I’ve collected the terminology used by all apps so that you can avoid any confusion.

Support for non-supported (in general, non-MM) stuff?: here, I’ve listed non-multimedia stuff. Some feeds (for example, the C&L feed) not only have multimedia audio / video content, but also other stuff like YouTube links, Flash (.swf) and Adobe Acrobat (PDF) files etc. In this group, I’ve tested whether these kinds of files can be (manually – automatic download, in general, won’t work, except for very few titles like FeederReader) downloaded.

Download benchmarks (~20M mixed content over 512 kbps ADSL): in this test, I’ve tested how fast the app downloads to a 8GB Class 4 Sandisk card over a lower-end (512 kbps) ADSL connection. High-speed connections, of course, may have resulted in a much more pronounced difference. Just an example: over a very fast connection, NewsBreak is flying, while Viigo remains abysmal, certainly showing its file buffering / flushing algorithm is very weak.

Auto download / fetching: Supported? Refresh intervals / timestamp to execute?: Automatic podcast download / fetching is very important. In this row, I elaborate on which (or both) of the two updating timing is used: interval-based or a given, pre-set time of the day. I’ve also elaborated on the freedom of settings these parameters – that is, the granularity of the timestamp / interval setting. (Can you configure it to refresh the contents every, say, 5 minutes? Or, are you only allowed to do an update, say, at most once an hour?)

Download restrictions settable separately for each feed, as opposed to one, global setting?: Especially with sizable podcasts, it may be very important to be able to set completely different for example auto-deletion / retention parameters for individual feeds.

The storage requirements of different feeds can vary a lot. For example, there can be a feed with podcasts only taking up some 2-3 Mbytes at most (an example of these is Heart of Space, which only offers 30-second-long podcasts taking up only some hundreds of kilobytes), while other podcast episodes can easily be 50-100 Mbyte long (an example is X-Play’s lengthier movies). This means if you have little storage space but would like to keep as many podcasts as possible on your handset, you may opt for only letting for the retention of, say, 1-2 episodes of feeds generally having huge files, while not having so strict restrictions on feeds with small podcasts. In these cases, feed-level configurability (as opposed to one, global setting) can really pay off.

Distinction between allowed / blocked connection types to avoid using (expensive) cellular data?: some podcatchers allow for restricting the type of connection for downloading to avoid high data bills. The majority offering this capability has the ActiveSync vs. cellular distinction.

Can you define whether to force to open a connection if it isn’t available: some (unfortunately, VERY few) apps allow for very advanced functionality like enabling Wi-Fi / BT / the cellular radio (if any) before starting the update (and, when needed, disabling them after the update). In this row, I explained this (and similar) capabilities.

Storage usage restrictable / automatic deletion of listened-to / expired enclosures?: in percentage of free / remaining storage?: this subgroup has detailed information on whether you can fine-tune the storage usage by not letting the podcatcher download stuff that would result in the storage fill up. This is a basic setting and should be supported by all podcatching applications.

Permanent storage in the file system: can the home directory be set?: better apps, in addition to storing the podcasts on a storage card (or a, size-wise, comparable entity), may also allow for setting their home directory to anything, not just a wired-in directory name like \Podcasts.

Settable maximal number of enclosures kept?: Better catchers striving for efficient storage usage may employ a deletion strategy stating the following: whenever the pre-set maximal number of enclosures becomes too small to download the newest podcast(s), the oldest one (or an already-consumed one) is deleted.

Auto-deletion of podcasts older than X days?: storage saving may also be enhanced by allowing for (unconditional – that is, not depending on whether it has been consumed or not; see on this the next row) automatic deletion of podcasts older than X days.

Flags: Already listened to? What functionalities (not listing, deletion etc.) are based on this flag?: A decent podcaster application should at least flag already-consumed media as “read”. Based on this flag (and the visual presentation), the user would have the chance of not listening to the same podcast twice.

Podcasters behave differently when it comes to the read flag. For example, NewsBreak makes sure articles already read are put at the of the headlines, should you still need them. That is, at the beginning of the headlines list, you will only see unread articles. Some other casters “only” unbold read articles. Also, some of them have the “Hide read articles” functionality.

Better podcaster applications also have even more advanced functionality based on the “read” flag. The most important of this is (mass) auto-deletion of such articles. Too bad this really basic functionality is missing from most of them.

Not listened to, but old enough to be deleted (expired)?: in addition to the pretty basic “read” flag, some casters also employ other flags like “expired”, which, in a decent caster, would allow for deleting old, but not (necessarily) listened-to podcasts.

Note that some apps do support this functionality by just offering the “Delete all podcasts older than X days” functionality.