Files

564 lines
17 KiB
Plaintext
Raw Permalink Normal View History

Episode: 3132
Title: HPR3132: Keeping track of where I am
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr3132/hpr3132.mp3
Transcribed: 2025-10-24 17:31:45
---
This is Hacker Public Radio Episode 3132 for Tuesday 4 August 2020. Today's show is entitled,
Keeping Track Of Where I Am A Seer It Is Hosted by MrX
and is about 23 minutes long
and carries an explicit flag. The summary is,
How I Keep Track Of Where I Am.
This episode of HPR is brought to you by An Honest Host.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 Honest Host.com.
Hello and welcome Hacker Public Radio audience. My name is MrX
and welcome to this podcast.
As usual I'd like to start by thanking the people HPR for making this service available to us all.
There's truly an invaluable service in this year into troops.
HPR is a community-led podcast provided by the community for the community.
That means you can get you a bit too.
Why not pick up a microphone, maybe your mobile phone, your PC, anything you can record with and send a show.
And I've gone to a great deal of effort to streamline the process. It's really quite easy.
If I can do it, so can you.
When I give it a go I'm sure you must have something with all for the interesting to hear.
So, this episode is how I keep track of where I am.
So, how do I do that?
Well, first of all, I get my Android tablet and I open it up and I go to Google Maps.
No, no, no, not that kind of thing.
What I really mean is, where I am in my podcast, podcast listening.
How do I keep track of where I am within the podcast list that I'm listening to?
I've got a queue of episodes I'm listening to and I want to know where the hey comma.
When I last left off sort of thing, you know.
And when I was actually thinking about this, I had to relook back.
I mean, I almost ever produced this podcast because I discovered really that I'd covered a lot of this in my, in a previous episode,
you know, describing how I was in the podcast part 2, HBR 2889.
I'm quite conscious that I've got tendency to repeat myself in real life.
I think this is because I have such a rubberish memory.
But anyway, despite this, I decided to continue with the episode.
I might be going to the, how I went about doing it in a bit more detail.
It's kind of evolved over time sort of thing.
And I don't use it a heck of a lot, but it's something I've kind of developed anyway.
I haven't used some time to time.
So as I previously mentioned, I use cordless headphones to listen to my podcast and audio book,
audio books, whatever.
And the headphones come with a bass transmitter, which was originally plugged into my old compact home server.
So the server was generally turned on when I came home from work and turned off before going to bed each night.
Each night I had to remember which track I was listening to.
I've heard about in the track I was.
I often forgot I had to try and find the place again.
This quickly became quite tiresome.
My first solution was to use some Bash Confuge agree bookry to create a list of files,
which I placed in each podcast folder.
And that way I could just open up and look to see all right.
That's where I'm on this particular show, you know.
In the process of doing this, I learned a wee bit about Bash commands and whatnot.
So I had a look at some of these lists because they're still existing to folders today.
And, you know, use something like, pardon me, that's my four-legged companion,
who's something loyally by my side, not so loyally.
So the command of a user would be something like ID3 V2, dash L, so that lists the ID3 tag information.
Start at MP3.
Pick that to grep.
Look for the string TIT2, title 2.
Pick that to cut.
Cut between column 44 and the end.
And redirect that to the readme file to readme.txt file,
which I generated in each podcast folder.
I actually used a double arrow to append it to the readme.txt file.
And then, of course, as things got on, I used grep or e-grep with regular expressions,
yeah, to try and filter out what I was wanting to send to the readme.txt.
You wanting out?
You better not cry if I let you out.
All right, here you go.
Bye-bye.
I bet you will.
Oh, all right.
It was a...
Hmm.
So, for example, I've got a privy.pim.
I've got an example of this sort of...
...file it to create.
So, first line in that says hpr006.
Because that's going back a long way.
Don't MP3.
Got that to go back that far.
And then a dash and a dustman.
And then after that, I've got the word to complete.
So, I'll just listen to that one.
Next one is hpr0010.
I don't know what happened to 789.
The next group process, part one.
That was complete as well.
So, I think if it wasn't complete, I would sort of say, you know,
five minutes, 23 seconds or whatever.
So, the downside of this was that at the end of each night,
I had to remember to update my file lists,
recording where I had listened to,
and what position I was in within the track.
From time to time, I had to update this list
by pending the latest episodes sitting on my server
using the previous ID3 V2 command.
I just mentioned that, yeah.
As you can imagine, this took up a ferment of time
and became very tiresome.
I would sometimes forget to do it.
This would cause me a headache.
Next time, I started listening to my podcast.
My next solution involved creating a bass grip
that attempted to persuade my music player, Mark,
to find the track I was previously listening to.
The script sometimes worked, but it was a bit flaky
and didn't always work.
I recall it sort of...
I think I had recorded the track it was listening to previously.
And then, step through each track at a time
until the current track was matching
the track I recorded previously.
But it was very, very clunky and often didn't work.
So that was awfully, awfully great.
So my final solution is in multiple parts.
It's a kind of clutch that works for me.
Whether anyone will find it useful
or do something similar, I don't know.
So the first part consists of a bass grip
and a log file.
It was a handy way of checking the last podcast episode
and last position.
This information is recorded to the log file
when the front end of Mark is exited
by hitting the Q command.
Of course, this doesn't work if Mark P closes
for any other reason.
I, if I forgot to hit Q or my Pi crashed,
which it never does, by the way.
But anyway, that's by the by.
So the script...
I've got scripts folder in my home folder,
home directory,
and the script is called podcast.
So I was a quick lash up script
created in 2012, no less.
I created to keep track of last position
of the listened podcast.
So from the...
I've got comments within the script
that from the script and it says,
script displays the last four lines
of log file, log file, podcast.text.
The four lines consist of a dashed line separator,
the last recorded track title,
the last recorded file name,
and that last recorded position.
The script then pauses
and displays a message saying,
there's any key to continue,
that runs mock P.
So that's...
Basically, it does a lot,
and then runs mock P.
And when the front end up,
at once I've finished playing mock P
and listening to all my shows and whatnot,
where I'm going to do that day,
when I hit Q to exit mock P,
the script gets a current track file name.
If the result is empty,
I know file name,
saying mock was not playing anything.
If not empty,
it depends a dashed line separator
to the log file.
The current track title,
the current file name,
the current track position,
all to the log file.
It then displays,
it then displays the last four lines
of the log file at exit's script.
So in essence,
I get a reminder of the track composition
I'm listening to every time I start
and stop the front end of mock.
The log file is located at,
just for just sake,
homepy scripts,
podcast.text,
or TXT.
Just for general interest,
podcast.txt,
as of the 4th of October 2019,
is 168 kilobytes in size,
and currently has
4904 lines.
As each entry has four lines,
this means it currently contains
1226 entries,
fast knitting, I'm sure.
The second script,
how are we doing for time?
11 minutes.
The second script I use
runs as a cron job every night
at 1101pm.
1101pm.
The script keeps track
of all the files copied
to the MP3 directory of my Raspberry Pi.
This is where I put my podcast
that I want to listen to.
I can then rep the log file to see
the latest version
of a particular show
that's been copied to my MP3 directory,
and some time to time I delete the episodes
I have listened to before copying new ones in.
So this script
is stored in scripts.
A tilde, I should say,
in my home directory,
scripts,
update podcast episode log,
and the comments from a script
are
wrote at the time.
Created to keep track
of the latest podcast episode I've listened to,
it does this by logging the contents
of the MP3 directory
on the Raspberry Pi.
The script checks the log file exists,
then checks a podcast
and then uses the find command
to list the files named
MP3 directory,
and sends the listing to a log file.
A date stamp is added
at the beginning of the listing.
So that was
version 1 was created
in the 11th of July 2015.
By the way, I will include all these scripts
with a show
in case you're interested.
The log file
is created at home Pi file
with the latest podcast
episode log.
As of the 4th of October 2019,
the log file
is an impressive
698 kilobytes.
It contains a whopping
28,150 lines.
The first entry was dated
to 15th July 2013.
So of course, you know,
I can go,
it's probably a very
wasteful way of doing things
from day to day.
That folder will not change.
So it's basically
writing the same information day
after day,
appending it to a text file,
a log file.
But still, at least that way,
I can still find out
what the last episode
of a particular
show that I'm listing to
was. So I can say,
what was the last
to finish off? And I deleted that
with all the files by mistake
for that show.
What was the last one I listened to?
I don't know where the heck I'm
with that show.
I can grip it and say, oh yeah,
it was episode 23 or something.
So that's a general idea
of that particular script.
Well, you know,
it's,
what did I say? What size did I say was
688 kilobytes.
Oh, you know, you could make that
so much more, yeah,
loads of duplicates and stuff in the file.
And I should maybe do log rotation,
and all that sort of stuff.
Well, it's 688 kilobytes
these days, you know.
We're also wasteful nowadays.
So that's my excuse anyway.
It works.
And I just, um,
God, that's what size it
lined up eventually.
But that was since 2013, remember.
The third script,
um, what it does,
uh, subscripts also runs as a
growing job, uh, every night
at 11 o'clock.
Um, and it's in Home Pie
scripts,
update, broadcast,
position, log.
And below the comments,
take it directly from the script.
Created to log current
position of current podcast.
The script checks, the log
then checks that mock
P is installed on the system.
And then writes a time stamp
and track position information
to a log file,
uh, using mock with the dash Q
flag, uh, to get the current
track position track title
and final name.
Version 1 was created in July 2015.
Um, yeah, you can use a Q command
and that way you can
tell it out mock
or spout information,
depending on how, how you
what you actually have.
I can't remember exactly how you use it.
Is it a percent?
And then, uh, you can look at the
modern page and mock to see how you use
a Q dash, uh, dash,
capital Q command.
Uh, the log file is located at Home Pie, uh,
files, logs,
podcast, position,
log.
So it's 140 kilobytes
currently has 1495 lines.
The first entry was dated to
15th of July 2013.
So an example, um,
log out, we have got
1509062301.
So, uh,
I know Dave like it.
I know Ken likes us this year,
month, day, hour, minute.
And then a pipe symbol
and then the track position
which gives you, uh,
minute and second.
So I'm one minute 12 seconds
on this, for example.
The other, the other pipes,
pipe symbol to separate the fields.
And this time, the third entry
is ID3 track type,
ID3 track title.
So in this case,
Steve Morris, uh,
HPR1811
Life and Times of a Geek
Part II hacker public radio.
And finally,
the last field,
separated by a pipe, uh,
the vertical bar, I should say,
is the final name.
And that's HPR1811.mp3.
Um, so yes, uh,
so that, that,
that means I can look at the, uh,
at that log and see
basically where I'm,
because every night at 11 o'clock
it records that.
So, you know, if my pipe was to crash
or something was to happen,
the very, you know,
by the end of that day,
that tends to be, by that point,
I won't have listened to anymore.
So it'll be pretty much bang up today,
or at the very most, only one day out.
So it's quite easy to,
to work out where,
where I am basically.
Um, so that's, that's the idea that script.
Um, the fourth script
is a previous script,
but it uses, uh,
it's used to update the current
audio book position to log file.
Like the previous script,
it runs as a cron job every night.
And that's HomePieScripts
update audio book position log.
And, uh,
the final script,
uh, the fifth part is, uh,
HomePieScript Logs.
It was created to easily view,
uh, the,
podcast and audio, audio book logs.
The script first checks
that the log files exist.
Then displays the last three lines
of my podcast and audio books logs.
So I can quickly see
the most recent episode positions
that were stored by the cron job
is around 11 p.m.
Uh, the logs are stored
at HomePieFilesLogs.
The version was created
in July 2015.
Version 2 was in August 2015.
Uh, this added the option
to search for a string
in my episode position logs.
Uh, it's easily found out
what the latest episode they listened to
of particular book or podcast.
The output is pepped
too less as
you can see.
If more than one argument is given
then this plays an error
and a usage message.
Version 3 of the script,
uh, another retweet
in July 2017.
Um, so if a single argument is
given the numbers to do
to search for a string,
then it now jumps
to the end of the list
rather than the beginning.
The default option for
less is to jump
to the beginning of the, uh,
file.
Uh, I've discovered
that you can make it jump
to the end of the file
by using the plus G
plus capital G flag.
Um, so that's, that's quite handy.
Um, I mean,
if I'm not, if I'm not searching
for a string and I'm not,
in other words, if I'm not using any, um,
arguments with the script,
then it just uses, uh,
tail
to display the last few lines.
So I don't know to worry about that.
But it's when you're using less,
it doesn't say defaults to the top,
the top of the file is supposed to
end. So I hope that makes sense.
Um, so yeah, there's a script
that displays the contents
of the following logpiles,
homepy, files, logs,
podcastprison.log
and homepy files logs
audiobookposition.log
Phew.
Does that all make sense?
I don't know.
Um, I don't very often need to use
this facility because, uh,
or these facilities, because my pie
is, I've seen before, pretty, pretty damn stable
and, uh, you know, it doesn't crash.
Um,
but, um,
I've seen me going and holding,
and I'm shutting it down or
it has been, uh, I remember,
on one hand, many times, I've actually
needed to use this, uh,
but it is a handy way to, um,
to get back to where I was, you know,
and not to look at a, uh,
a playlist on, on, on what can I think?
God, where the heck was on, uh,
where these 50 shows that,
in a playlist, what episode was on?
And now that I've found the episode,
where on earth was out, within the episode.
It does greatly, um,
simplify things.
I don't know how, how,
the rest you keep track of these sort of things,
maybe you use your phone or,
I think a bit of most people these days
just use a phone, uh, to, uh,
to the podcast.
I don't have a smart phone and,
I don't fancy carrying a big,
tablet type thing on the back,
my back pocket or whatever.
Anyway, I guess I could use a name, uh,
my Sansa Clipper or whatever.
Uh, when I'm, uh,
outside obviously.
But this is very convenient when, uh,
in the house. Um, so yeah,
I've been interested to hear how,
uh, other listeners said,
do this sort of thing. Um,
so anyway, I, I think that's just
about all I've got to say on the subject.
I hope I haven't bored you all to tears.
I haven't spoken too quickly.
Uh, but, uh, there we go.
So, thanks very much for the last thing.
And, uh,
only just remind, it just remains for me to say,
if you want to contact me,
I can be contacted at MrX
at HPR
at googlemail.com.
That's MRX
80
HPR
the At symbol
googlemail.com.
So until next time,
thank you and goodbye.
You've been listening to HECA Public Radio
at HECA Public Radio.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.
HECA Public Radio was founded
by the digital dog pound
computer club,
and it's part of the binary revolution
at binwreff.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 on the
Creative Commons,
Attribution, share a life,
3.0 license.