Episode: 3161
Title: HPR3161: How I manage podcast listening
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr3161/hpr3161.mp3
Transcribed: 2025-10-24 18:01:00

---

This is Hacker Public Radio Episode 3161 for Monday, 14 September 2020. Today's show is entitled,
How I Manage Podcast Listening. It is hosted by Dave Morris
and is about 20 minutes long, and carries an explicit flag. The summary is
another reply to MRX's episode on how he listens to podcasts.
This episode of HPR is brought to you by An Honesthost.com.
Get 15% discount on all shared hosting with the offer code HPR15. That's HPR15.
Better web hosting that's Honest and Fair at An Honesthost.com.
Hello everybody, Dave Morris here.
Welcome to Hacker Public Radio. This episode is called How I Manage Podcast Listening.
I'm replying to MrX's episode on how he listens to podcasts.
He was asking for other people to chip in and say how they do what he was describing.
I've got my own home brew semi-home brew podcast management system.
I have spoken about it before quite a long time ago.
There's a link to it in the notes, but I didn't talk much about this area of things, playing episodes.
So I thought I would do that now.
MrX's episode was called Keeping Track Where I Am, dealing with the problem of what he's
listening to, how far he's got through a thing and sort of stuff.
So in summary then, my podcast, the details of my podcast are held in a database
which runs on my desktop PC, and I keep details from the feed for each episode.
If there's currently a file relating to the episode that's mentioned in the feed,
I have downloaded it, haven't deleted it, then the database knows where it is.
I keep episode details in the database for episodes I've already listened to.
Just for interest, I guess, really.
Now every podcast feed that I have is assigned to a group.
So I have music, science, documentary, technical, and...
I interface the database on my desktop PC using my interface to it.
I should say using command line scripts.
I'm a great command line user.
I use the PD menu tool, I've done a show about in the past, and I use the menu through that.
So that gets me to where I want to be very quickly and easily.
I don't really want to have a GUI to do all this sort of stuff.
GUIs are a useful in certain contexts, but quite limited as far as I'm concerned.
The actual episode is on a Raspberry Pi, which runs all the time.
I used to keep it upstairs in my spare room, but it's now downstairs because I've got a bunch of shelves
over the top of my desk area.
The Pi has got an SSD attached to it, and so I mount the podcast directory on it
to my desktop through FS tab using NFS.
I download podcast episodes overnight on the Raspberry Pi using my own hacked version of the old,
venerable, bash podder, which is what I did talk about in the past.
I have a bunch of MP3 players which have got rockbox installed.
Rockbox is key to what I'm doing here, and I usually load up my players with episodes
using a script that's aware of the feed groupings I mentioned earlier.
It makes a playlist in the database and writes a copy of that to the player.
Rockbox knows what it's supposed to be playing in and what order.
The database playlist table holds the alias of the player so I can have a playlist
per player out of the database.
As I play an episode, I run a script that adds data to the database to show
that the episode is being played.
Rockbox itself tracks which episode I'm listening to where I am in the audio on the player.
After playing an episode, I run a script that lists episodes marked to be playing
at the previous point, and it allows me to delete them from my PC and from the database.
I don't usually delete anything from the player until I next upload to it,
which I think might be a mistake, but at least I need to add a step that handles that a bit better.
The reason for this is there's an issue with the size of a group and the space on a player,
especially in recent times because I'm not listening to podcasts as quickly as I used to
or maybe I have more feeds than I used to or maybe there are more episodes coming out on feeds.
I think there's a bit of that.
And these players are not vastly huge, they're only like four gigs, six gigs, eight gigs.
So sometimes the number of shows in a group are more than the player can take
and the mechanism is organised per group because that was not a problem when I first did it.
I don't delete files on the player until I upload new ones.
There's part of the process, the script says, always told if you find anything on there, delete it first.
So doing it that way, I don't know how much space is there there is on the player before I upload to it.
So that's something I'm going to have to work on.
I have a script that shows the numbers of files and total sizes for the groups
and both files which have been copied to players and those pending to be written at your course.
So I'm going to use these sizes to make decisions about what gets uploaded.
In the worst case I can write episodes to a player selected by feed name if they're a capacity issue.
So I don't have to go by groups, I can pick out individual feeds if I want to.
I don't have an easy way of at the moment of working at how much capacity I have in a feed.
That's also something I need to have to work on.
So the sizing issue, capacity issue is something that needs work.
So I addressed in my notes to talking about how I upload the contents of a feed to a player.
So I'm using, I actually did this and then snap shorted the output and stuff for the notes.
The player actually being used is one of my Sansa clips and it's got an alias of clip.
The player runs rock box as usual.
It gets mounted by the software I have on media slash USB2.
And there's an alias I run called player underscore mount and you can see it demonstrated here.
And the commands that are run by that alias, they're just a collection of command and script.
They look on the player for a file called player name and display it using the figlet tool which just gives you an interesting looking display of a word.
So I do player mount and it says clip. That's the name of the thing you've plugged in.
It's not one of the other ones that I have and so confusion doesn't easily.
And the database needs to know what player the stuff's been written to just to help manage things.
So then I run a script called copy episodes and it performs the upload of episodes.
This is the one that just does a feed.
It uses an option hyphen locacy followed by a capital C and it that tells it to remove any media found on player before writing stuff.
There's a directory. This is a rock box thing directly called podcast in other case and I use that to write stuff to.
If I were to use hyphen locacy space capital N then that allows me to append stuff to the player.
So I could use copy episodes to write the contents of several feeds to the player if I wanted to.
The feed name itself is a regular expression so in the example you'll see hacker.
So the actual command is dot slash copy episodes hyphen locacy and space slash media slash U of B2.
Hyphen locacy clip of the player locacy hyphen locacy capital C and then hyphen locacy F hacker.
So that says go and find a feed that's got hacker in it and nobody got one and it's hacker probably radio.
So the script then generates a playlist on the player and it's stored in the directory playlists which again is a thing that rock box needs.
It's called podcast dot M3U and it contains the path to the episode relative to the player.
So rock box and use that to find the episode and play them in sequence I hand them in.
And of course I hand them in in date order and there you go.
So it shows what happened and you run this.
Delete the files off the player it then copies them and displays what it's copying.
The way I run the bash pod of clone is that it writes it's daily downloads to a directory with the date.
I mean I saw it 601 format so you'll see there's a list of directory which are actually in date order.
I don't use that is the date stored in the database to sort them.
Then there's just a few other messages which really when I look at them they're fairly redundant.
It says it's created a playlist said it copied seven files pretty redundant.
That's the database saying that it got seven files added to the playlist.
Then I run the alias player underscore you mount and mount the thing.
And there you go it's it done.
There is an alternative script copy group which does the something very similar but it does it by groups.
It will for a given group there's usually multiple feeds so it will iterate through.
So once I've got the episodes on the rock box player,
I then use the standard rock box menu to navigate to the playlist catalog entry in the main menu.
And that lists all the playlists currently on the device.
When I click on the central button on the Sansa clip which means you know into this particular menu entry,
then it shows a list a playlist with the name podcast.
That's what I wrote there remember.
And then if you click on that it shows a numbered list of episodes.
And you just click on the first one then it starts playing the playlist.
You do need to go through these steps to make the playlist play but don't find that to be a huge typical.
They can do it pretty much even looking.
I've got sound prompting turned on, the majority of my rock box players.
So it says it just reads the menu entry back to me and tells me what where it is.
So I often do do this in the dark.
And my rock box players are set to write a bookmark for the currently playing episode when the player is turned off.
They're also set to auto resume after stopping.
So I can stop and turn off during playback minutes.
So it usually stop it first or just hit turn off.
They can do that.
But after I've done that the player will make a bookmark.
And if you've got the speech turned on it will say but it's doing that.
And then when I switch back on again it will leave off.
It will resume where I left off.
If for any reason I navigate away from the playlist some of the players have got a few other things on like music and stuff like that.
Then I can get back to where I was with the resume playback.
I took on the main menu or I could look in recent bookmarks to find a bookmark relating to the podcast that I played.
Or I could go back to the playlist catalog and work my way down the list to find which one I last listened to.
I don't think there's probably a point in there where you might fail to resume where you left off.
I don't think I've ever managed to trigger that.
I guess because I tend just to use these players as podcast players.
But on the whole I'm very, very, very happy with it.
The previous software I had on my earlier players couldn't do anything nearly as sophisticated as this.
They imposed their own sorting on playlists or they didn't handle playlists and they didn't save state after you stopped them or they didn't resume after you restarted them.
All these sorts of things. Rockbox handles it all. Rockbox is brilliant.
But unfortunately the number of players that can handle it these days is dwindling.
I put a list of my players here just a dump from me from the database.
I tend to use the Sansa Clip Zip.
So I've got Clip Zips and Clip Pluses and one Clip.
The one called Clip was when I bought new. Some of the other ones have been bought off eBay.
I did a show on all of this so I won't go into any more.
So how do I track what's been played and what's not and delete stuff?
Well, what I do is I have a bunch of scripts which get run as I am listening to stuff when I've changed podcast or even changed player.
So I've got a script which will mark an episode as being played.
Another script which will delete those that I've selected to, after I've listened to them.
So I did this as I was preparing the notes.
And at that particular point I had two players in which were in action.
One's called Clip which we saw earlier on getting loaded up.
And the other one's called Zip 2 which is a Clip Zip red one.
And that's got a whole bunch of things on it. Some of which I've already played.
So there's a transcript of what happened when I run my scripts.
It's again run out of menu or PD menu.
I get a list of all of the episodes on the Clip and they're in numerical order.
They have a number again on the left hand side.
And then it's square brackets, a player name and the sequence number within the play list.
And then they have the title. So it's pretty easy to know what you can.
In fact, change the order if you want to.
You'd have to gone to listen to a specific thing manually on the player in order.
The two are only logically linked together, linked together in my...
So the second chunk of data here is what's on the Zit player.
And there's a lot. I didn't list it all. Just listed from the current one.
Episode 38, sequence 30, as you'd say, in up to 43.
And it's mintcast and listening to the backlog of mintcast.
So having displayed all this a lot, you can be a little bit long.
That might be a disadvantage, I don't know.
But just sort of lip with it. It's not a thing that bothers me. It's just the way it is.
You get the prompt select number, call it bracket s.
Because you can select multiple episodes if you want.
And I select number eight. Well, number eight is on the zip two.
It's sequence number 38 and it's mintcast 338.
So it marks that as playing, being played.
So this is me. I've just finished the previous episode and I'm now going to listen to the next one.
So this is marking it as in process.
And this message is like marking and it says what it's marked and it says someone changed.
Then the second script is called and it shows two zip two entries marked 0102.
It says mintcast 337.5 and 338.
So 337.5 is the one I've just finished listening to.
338 is what I'm going to listen to next.
And oh, I should say the rock box. I've got it configured runs from one episode to the next.
So there's no stopping between them or anything. I've just taken the action.
But I do need to come here to the PC and run this sequence of commands in order to keep the database contents in step with actually happening on.
So I'm asked to select a number. I select one from this list, which means I want to delete mintcast 337.
Then there's a bit more in the listing. I split it up into pieces.
I actually put text around it just to explain.
So the next bit shows how many podcast files still exist.
It says 262 episodes are sitting around in the database in 83 directories, which is information for the sake of it, I guess.
It also computes the total size of all these podcast, which was 10 gigabytes at that particular point.
Then there's a log kept of the duration of all of these episodes, just because I like doing this sort of thing.
And it's currently a listing of this.
The last few lines of this particular file is kept in a cache file.
And at that particular time, which was the 24th of August, 11.02 in the morning, there's one week, one day 47 minutes and 58 seconds of podcasts to listen to.
I want to list them sequentially.
The final thing is there's a script that's run to analyze what podcasts I'm actually listening to or actually active on whatever players I have.
And there's only one at this moment, and that's the main cast for it.
And it's the information's listed out, the player, the podcast and all that sort of stuff.
So I'd say I usually only have maximum of three players active any time, mostly just one, sometimes two, three very rare.
Final thing I wanted to say was the ID3 in similar tags on episodes.
And I did say this in the previous episode.
Previous episode I'm talking about is number 2211, my podcast, which talks a bit about this stuff.
But I thought it was worth just doing a brief update on things.
So as I process the day's batch of incoming podcasts, because they're happening overnight on a Raspberry Pi.
And I go to a run something on my desktop first thing in the morning, which checks everything and make sure all the information's stored in the database and all that.
But a longer way I manipulate the audio metadata, generally, to its tags.
I think ID3 only refers to MP3 tags.
I have a pulse script, which I wrote, which is the rules file for each field and performs checks and actions on the episodes it finds.
And I, in general, I tried to make sure that there's a valid title, because I want to see the title in the list or go.
And sometimes there's no tags whatsoever in the script can fill them in from the feed itself.
So feed contains bits of information, titles, comments.
And so it stuffs them into the tag in the actual file.
Now, some feeds put the feed name in the title.
So the mincast case, it's easy to look at the list and say, all right, next I'm going to be listening to mincast.
Sometimes all you get is a title that's just the title of the episode doesn't say what it's actually going to be.
I know this is a feature of the way I do think that there's no compulsion for them to do this.
In the case of HBR, there's no flag for HBR in the title itself.
So my rules add this to it, just for my convenience I can see it.
Do you find it's supposing how many feeds produce episodes that have no metadata to it?
I'm saying I used to write to feed owners and ask for these to be filled in.
But mostly they said, go away or who are you?
Why are you talking to me?
So that's why I involved my own method of dealing with that stuff and a thing that annoys me still.
I don't know why you would bother to make podcasts and not put stuff in the tags and the tags.
Anyway, that's it really.
It's a weird and wonderful way of doing things.
Mistrex's solution to this is a fascinating one.
I think there's another response in the queue.
I haven't heard yet.
Down to person has done one, I think.
And so it's an interesting subject, I thought.
You have anything to add to this one.
I would be fascinated to hear what you do.
All right then.
Bye.
You've been listening to Heka Public Radio at HekaPublicRadio.org.
We are a community podcast network that releases shows every weekday Monday through Friday.
Today's show, like all our shows, was contributed by an HPR listener like yourself.
If you ever thought of recording a podcast, then click on our contributing to find out how easy it really is.
Heka Public Radio was founded by the digital dog pound and the Infonomicon Computer Club.
And it's part of the binary revolution at binrev.com.
If you have comments on today's show, please email the host directly.
Leave a comment on the website or record a follow-up episode yourself.
Unless otherwise stated, today's show is released under Creative Commons, Attribution, ShareLife, 3.0 license.