Hi all,
Just to be clear I am not offended (I have thicker skin than that), however I
subscribe to the digest version so I have only just received all of these
combined.
My comment about it being a shame to hear another show was purely because I
felt like there had a been a lot pulled in recent weeks, not in any way a
failure, I was just wondering if the algorithm to pull shows could be reduced
or was a this an essential minimum.
I do think that things should be discussed and reasons given, which I am always
happy to hear feedback; we don't have to agree with each other 100% of the time
and we will often disagree bit that doesn't mean that we need to fall out. I'm
actually quite happy with Ken's frank discussion and explanation, I for one am
not offended.
Again, thanks to all who contribute and may the feedback continue as I feel
that open-ness is important.
Have a good day everyone,
Kevie
On 27 January 2026 17:15:23 GMT, [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 (Ken Fallon)
>
>
>----------------------------------------------------------------------
>
>Message: 1
>Date: Tue, 27 Jan 2026 18:15:20 +0100
>From: Ken Fallon <[email protected]>
>To: [email protected]
>Subject: Re: [Hpr] The Reserve Queue
>Message-ID: <[email protected]>
>Content-Type: text/plain; charset="utf-8"; Format="flowed"
>
>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
>-------------- next part --------------
>An HTML attachment was scrubbed...
>URL:
><https://lists.hackerpublicradio.com/pipermail/hpr/attachments/20260127/6f0a0fe8/attachment.htm>
>
>------------------------------
>
>Subject: Digest Footer
>
>_______________________________________________
>Hpr mailing list
>[email protected]
>https://lists.hackerpublicradio.com/mailman/listinfo/hpr
>
>
>------------------------------
>
>End of Hpr Digest, Vol 206, Issue 10
>************************************
--
Sent from my Android device with K-9 Mail. Support open source software.
_______________________________________________
Hpr mailing list
[email protected]
https://lists.hackerpublicradio.com/mailman/listinfo/hpr
