Hi All,
As there has been no response to this thread, I am worried that the tone
of this email may have offended some people.
If that is the cane, I would like to unreservedly apologies. It is
definitely not meant as a criticism or attack in any way. When I get a
question I feel the need to give a detailed answer as to why its been
done that way, are the assumptions correct, and if we already tried
something. This should never be done in a way to alienate anyone in the
community.
Everything we do should have a reason, and if its not working we should
change it.
All the issues I pointed out below have been happening since the start
of the project and I as much as anyone else have done them. I'm sure
Dave Morriss would testify to that. The only intention in listing them
was to explain why there can be a delay in posting the shows.
As far as "tracking the queue", goes I am/was the number one offender
there as well.
I'd appreciate it if people would call me out on this stuff when the see
it happening.
--
Regards,
Ken Fallon (PA7KEN,G5KEN)
https://kenfallon.com
https://hackerpublicradio.org/hosts/ken_fallon
On 2026-01-26 11:45, Ken Fallon via Hpr wrote:
I would like to take the time to thank Kevie and Dave for moving the
conversation to the mail list.
The responses bring up several points that I would like to address.
RESERVE QUEUE
I'm glad to have an opportunity to discuss how the reserve queue is going.
The rational of using the reserve queue is not new, and was discussed
[by Dave Morriss on Monday, 2022-06-13, hpr3616 :: Filling free Slots
from the Reserve
Queue](https://hackerpublicradio.org/eps/hpr3616/index.html).
I go into more detail as to the mechanics behind it in show [hpr4195
:: Hacking HPR
Hosts](https://hackerpublicradio.org/eps/hpr4195/index.html)
TL;DR is that we use it as a mechanism to control the unstable nature
of submissions, versus the stable nature of postings.
> In response to another of Ahuka's fantastic YouTube Subscriptions
episodes
> being released from the Reserve Queue, Kevie said on Telegram, "Whilst I
> enjoy these shows, it's a shame that we are seeing another one being
> released"
Here Kevie and others before him sees shows coming from the Reserve
Queue as a failure.
This is not the case.
We needed extra shows, so we took them from the reserve queue.
It is the system working *exactly* as it is supposed to.
In response Dave says.
> I think it's often the fact that there are empty slots
> in the next day or two that spurs hosts into action.
This statement is predicated on the assumption that hosts monitor the
queue and act once it is empty.
This is not the case, as we have had 51 times where the queue was so
low that we have needed to issue a "call for shows".
2013 ( 1) *
2014 (12) ************
2015 ( 2) **
2016 ( 6) ******
2017 ( 2) **
2018 ( 3) ***
2019 ( 3) ***
2020 ( 2) **
2021 ( 5) *****
2022 (10) **********
2023 ( 4) ****
2024 ( 0)
2025 ( 0)
Who reading this, can tell me now without checking when the next free
slot is ?
Not many, given that the calendar page has only been accessed by less
than 200 unique addresses this month, and many of those are suspicious
same range IP assignments.
My feeling is that the most common use case for opening the page is
when you have already recorded a show, and are looking for the next
free slot.
There are of course those people engaged in the unhealthy practice of
"tracking the queue". At any given time their may be one or two hosts
who feel the responsibility to rush in shows to fill empty slots. This
is not good for HPR as Listeners complain of too many shows from a
particular host, and/or that the quality of the rushed in shows was
poor. Worse is that is is not good for the hosts in question, as it
creates never ending unnecessary stress on what should be an enjoyable
hobby project. Over the years I have had to advise several hosts to
stop looking at the queue as it can become addictive. If any host has
submitted a show in a given year, all calls to action no longer apply
to you.
Looking at the chart above, you may ask if the reserve queue was so
brilliant, then why did the problem persist after June 2022.
If you have had to deal with [Network
congestion](https://en.wikipedia.org/wiki/Network_congestion#Congestion_control),
you will know that at some point you will need to signal back to the
source to either slow down or speed up. In our case we signaled back
to the hosts to speed up, by sending a "call for shows" to the mail list.
A mail list outage in July 2023 made me realize that a "call for
shows" only reaches (currently 214) people, which is a small subset of
the HPR Listeners, and a tiny subset of the subscribed audience. We
were missing a large number of existing and more importantly potential
hosts.
From then on I added the warning "You are listening to a show from the
Reserve Queue. We are airing it now because we had free slots that
were not filled. This is a community project that needs listeners to
contribute shows in order to survive. Please consider recording a show
for Hacker Public Radio."
I'm happy to say that at least five new hosts have reported that they
joined HPR, specifically because they heard the show from the reserve
queue.
Therefore I believe we should keep the urgency where it belongs, out
in the open, spurring people who have never contributed to do so.
If the project cannot continue without intense intervention from a
small subset of hosts, then we should wind it up as it's no longer a
functioning community podcast.
CHOICE OF SCHEDULING
> I wonder if scheduling could be opt-in?
> For example, what if you could contribute an episode and leave it to
fate to
> find a time for it to run BUT when you have a specific date in mind
(May 4th
> for that clever Star Wars episode, and so on) then you have the
option to
> define a specific date.
This is not the first time that we discussed this, and so we support
it already.
The very first option on the upload page is "Add to the Reserve Queue
? Post your show to the reserve queue if you don't care when it will
be released."
Only after that are hosts given the option to pick a slot.
We do require that hosts post their first show to the main queue so
they can get issued with a host_id in the db, but other than that what
you suggest is an option today.
On a side note we also support the option for people to subscribe to
shows when they are posted without having to wait for them to be released.
https://hackerpublicradio.org/rss-future.php
SEVEN DAY POSTING
> Personally, I think that shows from the Reserve Queue are being released
> too early. Reserve Queue episodes go in to fill a gap one week before
> release, which means that another one will go in the queue for next
> Thursday if someone doesn't submit episode 4564 by tomorrow.
You have a point.
During the weekend I fill any free slots that were not filled in the
next week.
This means that in practice there may not be a free slot available in
the next seven days.
The question is what is a reasonable time to "call it", and post a
reserve show in a free slot.
In my experience (excluding the queue watchers) it's very unlikely
that someone will rush in, and fill one free slot let alone multiple.
Over ⅓ of the reserve shows posted have been in weeks where there were
multiple free slots.
We need to have such a large delay, due to the nature of HPR, versus
other podcasts that have control of their entire workflow end to end.
Some examples that resulted in posting delays from the last few months
include:
- missing audio
- slots kept open without posting
- invalid link to the audio
- no permission to link to the audio
- link is a zip/tar file requiring manual posting
- audio for the wrong episode
- audio with missing sections
- audio with copyrighted content
- audio but no shownotes
- audio that breaks ffmpeg requiring manual editing
- audio that breaks sox requiring manual editing
- audio so inaudible it requires fixing by auphonic,
- audio that is actually an image
- image that is actually audio
- shownotes in html that is markdown
- shownotes in html that is raw html code
- shownotes in *insert format of choice*
- shownotes that contain utf8 characters not supported by mysql
- shownotes that refer to a site with no shownotes
- shownotes that refer to a site with shownotes not licensed cc-by-sa
- shownotes with broken links
- shownotes saying "there are no shownotes"
- shownotes with misspellings
- shownotes that break the images
- shownotes that refer to images but contain none
- shownotes that are just images
- broken libraries for audio
- broken libraries for transcripts
- broken libraries for images
- broken libraries for subtitles
- broken libraries for metadata
- broken libraries for pandoc
- Internet Archive unavailable due to DDOS
- Internet Archive bugs in their API
- Anhonest Host servers migration
- Rsync.net hitting size limits
- ccdn nodes hitting size limits
- Numerous bugs in the processing script.
Not to mention shows where we need to involve the Auditors.
Each and every one of these causes delays.
While some of these I can fix myself, some we just have to wait for
the service to be up/or come up with a work around.
By far the biggest delay is getting in touch with hosts. If I have a
question tonight, I can expect an answer tomorrow, then at least a day
to wait for the fix, and only then can it be resolved. In some cases
the back and forth can extend to weeks.
Waiting to the last minute to post the show means there is not time to
resolve any given issue when they arise. The situation is actually
made worse when someone has just picked the slot, as then we need to
get the auditors and/or the list involved to release it. That can also
take days to come to a consensus, where urgent action may need to be
taken immediately.
Posting a reserve show so close to the deadline is also problematic as
if there is an issue with it, the host needs to be available to deal
with an episode they authored a year ago.
Before we spend a lot of time on this, can I ask is this a real issue
that people have faced ?
The reason I ask is that we come up against this in normal operation
all the time during any week where there is **not** a reserve show posted.
Has anyone every had a show that they wanted to post on a slot that
was occupied by a reserve show ?
--
Regards,
Ken Fallon (PA7KEN,G5KEN)
https://kenfallon.com
https://hackerpublicradio.org/hosts/ken_fallon
On 2026-01-25 16:55, Mark Rice via Hpr wrote:
The opt-in idea might work. Also, it might help, as Dave implied, release
shows from Reserve 2-3 days before we run out.
I have to agree that it gives a sense of urgency to add shows.
On Fri, Jan 23, 2026 at 12:00:01PM
+0000,[email protected] wrote:
Send Hpr mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.hackerpublicradio.com/mailman/listinfo/hpr
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Hpr digest..."
Today's Topics:
1. Re: The Reserve Queue (Klaatu)
----------------------------------------------------------------------
Message: 1
Date: Fri, 23 Jan 2026 12:13:33 +1300
From: Klaatu<[email protected]>
To:[email protected]
Subject: Re: [Hpr] The Reserve Queue
Message-ID:<[email protected]>
Content-Type: text/plain; charset="utf-8"
I think you're making an interesteng point, Dave.
I wonder if scheduling could be opt-in?
For example, what if you could contribute an episode and leave it to fate to
find a time for it to run BUT when you have a specific date in mind (May 4th
for that clever Star Wars episode, and so on) then you have the option to
define a specific date.
In other words, everything goes to Reserve by default and posts on a first-in
first-out (FIFO) basis, unless the contributor chooses to override Reserve and
grab an available date.
Or maybe the psychology of seeing available days prompts more contributions,
and a big bucket of Reserve Shows just wouldn't have the same effect? I
understand that part of the structure of contribution is about "tricking" our
brains into feeling urgency about contributing, and I respect that (and
benefit from it, probably!)
-klaatu
On Thursday, January 22, 2026 12:25:55 PM NZDT Dave Lee via Hpr wrote:
In response to another of Ahuka's fantastic YouTube Subscriptions episodes
being released from the Reserve Queue, Kevie said on Telegram, "Whilst I
enjoy these shows, it's a shame that we are seeing another one being
released"
Personally, I think that shows from the Reserve Queue are being released
too early. Reserve Queue episodes go in to fill a gap one week before
release, which means that another one will go in the queue for next
Thursday if someone doesn't submit episode 4564 by tomorrow.
I wonder if the role of the Reserve Queue has evolved into something that
removes the criticality of submission because - for as long as there are
episodes in the Reserve Queue - there will never be a gap in the next 5
weekdays. Of course, once the Reserve Queue starts to empty then there'll
be major panic, but I think it's often the fact that there are empty slots
in the next day or two that spurs hosts into action.
It's all about optics. If it looks like there are episodes posted, where's
the urgency?
Thoughts?
Cheers,
Dave (thelovebug, co-host of the HPR Beer Garden)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part.
URL:<https://lists.hackerpublicradio.com/pipermail/hpr/attachments/20260123/bfde278d/attachment-0001.sig>
------------------------------
Subject: Digest Footer
_______________________________________________
Hpr mailing list
[email protected]
https://lists.hackerpublicradio.com/mailman/listinfo/hpr
------------------------------
End of Hpr Digest, Vol 206, Issue 6
***********************************
_______________________________________________
Hpr mailing list
[email protected]
https://lists.hackerpublicradio.com/mailman/listinfo/hpr
_______________________________________________
Hpr mailing list
[email protected]
https://lists.hackerpublicradio.com/mailman/listinfo/hpr
_______________________________________________
Hpr mailing list
[email protected]
https://lists.hackerpublicradio.com/mailman/listinfo/hpr
