Re: [Hpr] LinuxInlaws and HPR
I have a few questions about the syndication policy. Hopefully I am not over complicating the issue. Question 1 - What would it take to get the Linux Inlaws into compliance with the HPR syndication policy? The biggest issue I see is the separate Linux inlaws feed with unpublished HPR episodes. What if they replaced their feed (https://linuxinlaws.eu/inlaws_rss.xml) with the HPR Series feed? Question 2 - Is a HPR host having a separate website to promote their HPR episodes OK? Question 3 - Many HPR episodes are audio versions of a web page previously published by the host. Does an audio version of an existing web page (Verbatim or summarized) meet the requirement of "material created exclusively for HPR"? On Wed, Aug 17, 2022 at 6:56 AM Ken Fallon wrote: > Hi All, > > With permission, I am posting the email and my response to the Linux > Inlaws. > > Your comments are welcome > > Ken. > > On 16 Aug 2022, at 20:55, Ken Fallon > wrote: > > Hi Lads, > > As I think you are aware a discussion was carried out on the mail list[1] > following my request to clarify the nature of HPR. The community is of the > opinion that we are not a podcast hosting platform, and do not "host" > podcasts. All our series are considered to be episodes that are part of the > HPR podcast. This puts your show at odds with our rule: "only releasing > material created exclusively for HPR.[2]". As we have applied this rule a > lot in the past, we cannot make an exception here. So if you wish to > continue to post to HPR, then you need to ensure that your content is > produced exclusively for HPR. > > If you decide not to follow this path, then your future episodes will need > to be hosted elsewhere. As your content is Creative Commons, then the > Internet Archive would seem to be the logical place to host the shows. We > are obviously willing to assist with the transition. We can also add your > show to https://freeculturepodcasts.org/, which by default gets you > exposure at any of the Fests that our contributors attend. We can also send > out notices to the other people we know who maintain FLOSS podcast lists. > Given a lot of people are subscribing to your series RSS feed > (?series=111), we can hard code a redirect to > https://linuxinlaws.eu/inlaws_rss.xml, and that way you don't lose any > dedicated subscribers. We will also be sure to remind people to add your > feed in the upcoming community news. > > I know this is not great news for you, and I am not enjoying being the > messenger. > OK well tell me what you decide and as always you can bypass us and bring > this up on the mailing list[1], or you can contact the smaller group of > Auditors (audit...@hackerpublicradio.org) to discuss it with them in > private. > > [1] > http://hackerpublicradio.org/pipermail/hpr_hackerpublicradio.org/2022-August/015343.html > [2] https://hackerpublicradio.org/stuff_you_need_to_know.php#syndication > > > On 2022-08-17 11:15, Linuxinlaws wrote: > > Hi Ken, > > We certainly followed the discussion on the mailing list - with growing > disbelief tbh - and as yet have not commented. As LinuxInlaws we applaud > the democratic approach by listening to the community. At the same time we > have to ask ourselves, can a handful of people commenting on a mailing be > considered the whole community? As you well know, the silent majority tend > not to comment on mailing lists. > > That being said, we also need to look at the actual arguments being made > “HPR is not a podcasting platform and doesn’t allow syndication”. We fully > agree and comply with this, as far as the LinuxInlaws are concerned, we are > a series on HPR - just like many others. To argue the case: > All our content is exclusively produced for and released on HPR > Yes, we have a website but the same can be said for many serial content > producers on HPR. Our website is supporting only and does not host and > recordings. > Our set-up and the way we publish material has been the same from the > start so why the sudden change of direction for HPR. > > We feel rather singled-out in this discussion and consider us no different > to other series producers on HPR. > > More than happy to discuss. We greatly appreciate HPR and would prefer to > remain a part of it. > > Martin and Chris. > > > My response to the points are as follows: > > *> "At the same time we have to ask ourselves, can a handful of people > commenting on a mailing be considered the whole community?"* > How we operate as a community is described here > https://hackerpublicradio.org/about.php#governance. These emails are also > brought to the attention of the entire community every first Monday of the > month in the Community News show. There the community in it's entirety can > and do provide comments. Any proposals on improvements are welcome. > > *> "Yes, we have a website but the same can be said for many serial > content producers on HPR."* > Please give me an example of a show or series on HPR that has it's own > i
Re: [Hpr] Source Code for the HPR website.
Is it possible to publish a mysqldump of the current database? On Tue, Jun 28, 2022 at 2:44 AM Ken Fallon wrote: > On 2022-06-28 05:23, dnt via Hpr wrote: > > Is there some reason a proper database just for storage would really be > better? > Yes to build and maintain the relationships between hosts, series to the > shows. The full rss feed already contains everything that a database > would provide, but a a database makes it a lot easier to manipulate. > > In any case, I'd like to be in the loop. Should some sort of website > > working group be created to have these discussions without filling up > > this mailing list? > > Good point. We'll move the discussion out after the community news, > where the wider community can have their say. > > -- > Regards, > > Ken Fallon (PA7KEN,G5KEN) > https://kenfallon.com > https://hackerpublicradio.org/hosts/ken_fallon > > > ___ > Hpr mailing list > Hpr@hackerpublicradio.org > http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org > ___ Hpr mailing list Hpr@hackerpublicradio.org http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org
Re: [Hpr] Source Code for the HPR website.
Sorry if I missed this in a previous message. Where is the DB published? On Sun, Jun 26, 2022 at 10:21 AM Ken Fallon wrote: > We are publishing the data in the form of a SQL db and static HTML, and > I'm very happy for there to be multiple ways to produce the web mirror. > > [DB + Static HTML Pages] → some tech → Working site on your domain. > > If there are multiple approaches then all the better. Anyone can start a > proof of concept for their tech of your choice and record a show about it. > > Ken. > > On 2022-06-26 17:05, Mike Ray wrote: > > > > > > I suggest that if something new is going to be developed then it > > should be in Perl, using either Dancer or Mojolicious as the framework. > > > > This I suggest since Dave is a Perl enthusiast, and I am currently > > professionally engaged in Perl development of a system comprised of > > both CGI, and psgi components. > > > > It could even be containerised and then easily movable from host to > > host. Using a container with nginx and uwsgi serving up the pages. And > > another container with MySQL in it. > > > > Whatever it is, it should not be PHP. And the pages should use > > templates so as to separate back-end from front-end design work. > > > > At a pinch, my second suggestion would be Python and either Django or > > Flask. > > > > But there is likely to be less of a legacy of Python skills in the > > current HPR 'staff'. > > > > Don't take this to be me volunteering to give much time, as my time is > > currently over-subscribed. But this might reduce later in the year as > > some heavy research I am engaged upon comes to an end. > > > > I will, of course, be hauling HPR over the a11y coals if I detect any > > hint of a problem :-) > > > > How many great shows could we get out of a complete rewrite of the > > whole enchilada? > > > > Oh, and keep the bleeping Javascript to a minimum. > > > > > > > > > > > > > > > > > > > > > > > > On 26/06/2022 15:26, Ken Fallon wrote: > >> On 2022-06-25 22:32, Klaatu wrote: > >>> I think what you are saying is that HPR requires a full rewrite. > >>> > >>> I think what you are proposing is that we forget that the existing code > >>> exists, because it's not worth "saving", and instead develop new > >>> open source > >>> code to replace it. > >>> > >>> If that's correct, then I agree. Let's not dwell on broken code that > >>> nobody > >>> loves, but move forward with new open source code that actually > >>> meets the > >>> site's requirements (and ideally makes the admins' lives easier). > >>> > >>> -klaatu > >>> > >> Yes got it in one. > >> > > > > > > -- > Regards, > > Ken Fallon (PA7KEN,G5KEN) > https://kenfallon.com > https://hackerpublicradio.org/hosts/ken_fallon > > > ___ > Hpr mailing list > Hpr@hackerpublicradio.org > http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org > ___ Hpr mailing list Hpr@hackerpublicradio.org http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org
Re: [Hpr] Any interest in a collaborative show on shell snippets?
I was not bothered at all by the sound quality. This was a great idea that turned into a great show. On Fri, Jun 24, 2022 at 6:41 AM Carl Chave wrote: > HPR, > > The sound quality of my segments in today's show is embarrassing, my > apologies to all listeners. I will try to improve it before submitting > anything else. > > Cheers, > Carl > > ___ > Hpr mailing list > Hpr@hackerpublicradio.org > http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org > ___ Hpr mailing list Hpr@hackerpublicradio.org http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org
Re: [Hpr] Policy change: Show complaints procedure
+1 Approve On Fri, Jun 10, 2022 at 2:30 AM Ken Fallon wrote: > Hi All, > > This policy change relates to shows that have been published but which may > contain problem content. > > For more information listen to today's show, where I suggest that we > continue to post the shows as normal, if we get a complaint then the > Janitors will contact the host as normal. Should the host be unavailable, > uncooperative, or disagree, then the Janitors can either move the show to > the backup queue, or hide it depending on the severity of the complaint. In > all cases we'll keep the special advisory committee aka the auditor team of > volunteers in the loop to make sure all is above board. The community can > then decide on the best course of action. > https://hackerpublicradio.org/eps.php?id=3615 > > I would like to propose the following changes to our policies. > > Both relate to > https://hackerpublicradio.org/stuff_you_need_to_know.php#not_moderated > > Currently: "We do not vet, edit, moderate or in any way censor any of the > audio you submit, we trust you to do that." > > Proposed: "We do not vet, edit, moderate or in any way censor any of the > audio you submit, we trust you not to upload anything that will harm HPR." > > Add the line: "Any material that is reported as harming HPR may be > unlisted until such a time as the situation can be resolved." > > -- > Regards, > > Ken Fallon > (PA7KEN,G5KEN)https://kenfallon.comhttps://hackerpublicradio.org/hosts/ken_fallon > > ___ > Hpr mailing list > Hpr@hackerpublicradio.org > http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org > ___ Hpr mailing list Hpr@hackerpublicradio.org http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org
Re: [Hpr] Permission to move out a show
I have no problem with the HPR Admins moving shows On Mon, Mar 21, 2022 at 3:43 AM Ken Fallon wrote: > Hi All, > > One of the shows in the queue has some issues. I spoke to the host about > it and it is not clear if they want to remove it or replace it. I think > they are off line for a bit as they haven't replied. > > Can I move the show out past the Community News so that the current slot > can be freed up ? Hopefully that will give time for the host to reply. > > -- > Regards, > > Ken Fallon (PA7KEN,G5KEN) > https://kenfallon.com > https://hackerpublicradio.org/hosts/ken_fallon > > > ___ > Hpr mailing list > Hpr@hackerpublicradio.org > http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org > ___ Hpr mailing list Hpr@hackerpublicradio.org http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org
Re: [Hpr] Possible cause and solution to subscriber attrition(trying again without encryption)
I think http://hackerpublicradio.org/eps.php?id=3454 is a great compromise. The intro is short, identifiable, and and easy listen. On Wed, Oct 20, 2021 at 4:40 PM Ken Fallon wrote: > On 2021-10-18 20:33:48, Mike Ray wrote: > > > > The length of the intro annoys me. TTS, followed by ad for AHH, followed > > by horrible and raucous music. > > > > There is a much softer version of the music which IMHO should be used. > > > > > > TL;DR http://hackerpublicradio.org/eps.php?id=3454 > > Re: Hosts uploading intro and outro > > From a show processing point of view, we have never been able to > automate the posting process due to the fact that some people do and > some people don't add the intro and outro. Even if they are flagged > correctly in the upload form I sometimes forget and end up having to > reprocess files because they have two intros or none. > > For this reason I would suggest that hosts do not add the intro or outro. > > Re: Non musical feed > > While it's possible to do, I am *not* in favour of having a new feed > without music. We accept any audio format, "FLAC is best, we accept the > rest". That needs to stay. From a practical point of view a raw feed > would not be useful as the audio format and encoding would change from > day to day. We deal with that through our conversion scripts so you > don't have to. > > We already have different feeds for the Internet Archive, and the HPR > website AnHonestHost.com. Adding another feed would just complicate > matters and will increase processing time considerably. > > But > > I think we can simplify all into one. > > If we take a look at the possible makeup of a show we have 7 possible > sections. See. > http://hackerpublicradio.org/media/theme-music/ > > 1. Show Synopsis > This is the text to speech. I was in favour of it but everyone hates it. > It should go. > > 2. Thanking our Hosting provider > IA don't know we do this, and Josh never asked us to do this. In > speaking with him, unfortunately the mentions don't convert to clients. > So with his permission, I'd like to move that to the start of the > community news so that it's handled as a personal thank you from the > Janitors. > > 3. HPR Introduction Music > There are a lot of themes available, all long > http://hackerpublicradio.org/media/theme-music/ > > I do believe we need to add a theme to maintain the "HPR Brand", > otherwise we risk been considered an amalgamation feed. > > There is no need for it to be as long or as *LOUD* as it is > > 4. The Show > Left in obviously > > 5. HPR Outro Music > Again we can cover this information on the community news, and in the > metadata of the show. > So we can drop it entirely > > 6. Epilogue > Sorry Pokey they need to go. > > 7. Promos > We never did any but if there are, we can do them as part of the > community news as well. > > - > > So in summary, I'd suggest dropping everything but a very short intro > and move the rest to the community news. > > As a proof of concept I just posted a show (we are very low on shows at > the moment - hint hint) and I used the first six seconds of > intro-ak-Maestraccio-cc-by-4.0.mp3 as the entire branding. > > The script to process reduced in size by 50%, as did the time to process > the files. I also suspect that automation of normalisation will be > easier as well. > > So your feedback is appreciated > http://hackerpublicradio.org/eps.php?id=3454 > > -- > Regards, > > Ken Fallon (PA7KEN,G5KEN) > http://kenfallon.com > http://hackerpublicradio.org/correspondents.php?hostid=30 > > > ___ > Hpr mailing list > Hpr@hackerpublicradio.org > http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org > ___ Hpr mailing list Hpr@hackerpublicradio.org http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org
Re: [Hpr] Possible cause and solution to subscriber attrition(trying again without encryption)
I would subscribe to a feed that did not have the intro music. I like the branding, but I know there have been several comments about improving the music. The best solution may be to offer a feed with only the contributor's voice. On Sun, Oct 17, 2021 at 7:16 PM Thaj Sara wrote: > Ok I'm going to be the pedantic audio nerd here. Using decibels to > measure this sort of thing can quickly lead to issues. The above example > kind of proves that. Without going into a REALLY long rant about audio > measurements and acoustics, the industry standard for measuring finalized > audio levels like this are LUFs (Loudness Unit Full Scale). The level that > is standard for podcasts is -16 LUFS. On Tenacity/Audacity this can be > achieved using the "Loudness Normalization" effect. I usually do some work > on audio prior to using that plugin to even out the levels. This would > ensure that the intro, body and outro of the show are all at the same > loudness. Yes Ken, I know I owe you a show... > > I agree with Klaatu. I usually bake in the intro and outro but would be > more than willing to not if it makes another feed easier to produce. > > > On Sat, Oct 16, 2021 at 5:40 PM anarchore via Hpr < > hpr@hackerpublicradio.org> wrote: > >> Hi; >> >> There was a community news show about a month ago during which the >> producers remarked that there was a plateau in subscribers. >> >> I have a suggestion that may improve this attrition rate... I and I'm >> sure a lot of others listen to podcasts to wind down while going to sleep. >> >> The intro song is loud, low bitrate sounding trumpet chiptune fanfare, >> which is fine. The thing is, the shows are often recorded at a low volume >> level so the volume must be adjusted upward to hear them... then after >> being soothed by a soft spoken hacker voice, the blaring, loud chiptunes >> are blasted again at the end of the show. >> >> This has woken me up from sleep many times. I can only imagine the >> consternation from headphone users. >> >> I'm sure this has led to many rage-unsubscriptions by those less level >> headed than I. >> >> There is a much more mellow sounding intro that is the same tune at a >> lower volume, that is used sometimes. If there must be an outro song, >> this should be it, and the loud blaring fanfare tune should be only used at >> the beginning. >> >> -- >> Sent with Tutanota, the secure & ad-free mailbox. >> ___ >> Hpr mailing list >> Hpr@hackerpublicradio.org >> http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org >> > ___ > Hpr mailing list > Hpr@hackerpublicradio.org > http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org > ___ Hpr mailing list Hpr@hackerpublicradio.org http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org
Re: [Hpr] problems with https://freeculturepodcasts.org/
It is not just you. curl -v https://freeculturepodcasts.org/ returns a redirect back to itself. On Thu, Aug 5, 2021 at 9:42 AM Roan Horning wrote: > Hi, > > Was clicking on the affiliate link at the bottom of the HPR page for > Free Culture Podcasts and get the following message: > > This page isn’t working > freeculturepodcasts.org redirected you too many times. > > Try clearing your cookies. > > ERR_TOO_MANY_REDIRECTS > > Is anyone else experiencing this issue? I have tried it in Firefox > and Chromium on Linux and the latest MS Edge on Windows 10 and receive > the same error. Don't know if it is an issue with my network or the > site itself. > > Thanks, > > Roan > > ___ > Hpr mailing list > Hpr@hackerpublicradio.org > http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org > ___ Hpr mailing list Hpr@hackerpublicradio.org http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org
Re: [Hpr] Error feedback from show notes
If the contributor agrees, could show processing fixes being published with the episode? It would be helpful to future hosts to see common issues. On Sun, Jul 5, 2020 at 6:04 AM Ken Fallon wrote: > Hi All, > > Most of the shows we process require us to make some level of > modifications to get them posted. This ranges from fixing tags to a > complete rewrite of the shownotes, or verifying whether intros were > actually added or not. > > Each modification that we make means that it requires more human > intervention and prevents us from being able to completely automate the > upload process. In addition there is a non trivial amount of time needed > to fix these issues. This can range from a few minutes to an hour or > more per show, and with 260 shows a year this mounts up. > > We normally don't contact hosts about these issues as it is usually > quicker to fix the issues than composing emails, and waiting for the > reply that may never come. For the most part our experience has been > that hosts are more than willing to fix these issues if they are aware > of them. > > As part of the ongoing steps toward automation, would hosts be open to > the idea of getting a processing report once we have posted the show? > This would list all the issues the test tools found and the steps that > we needed to take to rectify them. > > -- > Regards, > > Ken Fallon > http://kenfallon.com > http://hackerpublicradio.org/correspondents.php?hostid=30 > > ___ > Hpr mailing list > Hpr@hackerpublicradio.org > http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org > ___ Hpr mailing list Hpr@hackerpublicradio.org http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org
Re: [Hpr] Static Site Generators - NOT a flat file CMS
It is a little heavy but pandoc can convert markdown (or just about any other format) into html while inserting header/footer text form a file. I use something like this: cat file.md | pandoc -M title:"Documents" -H ../markdown.header -f gfm -t html -o ~/Documents/docs.html >From the pandoc users guide: -H FILE, --include-in-header=FILE|URL Include contents of FILE, verbatim, at the end of the header. This can be used, for example, to include special CSS or JavaScript in HTML documents. -A FILE, --include-after-body=FILE|URL Include contents of FILE, verbatim, at the end of the document body (before the tag in HTML -B FILE, --include-before-body=FILE|URL Include contents of FILE, verbatim, at the beginning of the document body (e.g. after the tag in HTML On Wed, Apr 3, 2019 at 1:38 PM Ken Fallon wrote: > Hi All, > > Do any of you have a recommendation for a Static Site Generators that > just publishes html files. > > For example takes a page, adds a header and footer from somewhere and > publishes the combined page. > > > -- > Regards, > > Ken Fallon > http://kenfallon.com > http://hackerpublicradio.org/correspondents.php?hostid=30 > > ___ > Hpr mailing list > Hpr@hackerpublicradio.org > http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org > ___ Hpr mailing list Hpr@hackerpublicradio.org http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org
Re: [Hpr] Changes to the Comment system
I have be getting a lot of older comments in the RSS feed. It is not a bother, but I wanted to make sure this change is the reason older comments are showing up. On Fri, Sep 1, 2017 at 3:59 AM, Ken Fallon wrote: > Hi All, > > Dave and I will be working on the comment system over the coming weeks. > > The current comment system has many failings from an administration > point of view, but none were so bad as to make us replace it. Recently > however it showed it's age when it fails to render correctly in https. > As a workaround we turned off https on the site. > > Next month Google Chrome is going to display a warning for non https > sites, so we will be at a disadvantage if we do not switch to an > encrypted site. > > We cannot update the script as there is no update available from the > vendor, and their own site is also showing error messages. > > This means we are going to migrate all the comments to a new system. All > existing comments will remain. When posting comments we will be > requiring you to answer some questions as an anti spam measure. For > example: > - What is the H in HPR for ? > - Who is the host of this show ? > - How many days are there to the next free slot ? > > We'll keep you posted. > > -- > Regards, > > Ken Fallon > http://kenfallon.com > http://hackerpublicradio.org/correspondents.php?hostid=30 > > > ___ > Hpr mailing list > Hpr@hackerpublicradio.org > http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org > > ___ Hpr mailing list Hpr@hackerpublicradio.org http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org
[Hpr] Spaceman
I appreciate that HPR does not censor submissions. HPR is for adults who have the ability to decide what they will listen to. I dont mind occasional foul language, and I think it is OK for spaceman to submit episodes that many consider offensive. Because of his language and tone, I have decided exercise my Sansa's skip button, and not listen to any further episodes by spaceman. Thank you HPR volunteers. Please don't change anything. ___ Hpr mailing list Hpr@hackerpublicradio.org http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org
Re: [Hpr] Issues with GMail marking all HackerPublicRadio.org emails as SPAM
MXToolBox is a pretty good place to check the reputation of a mail server. hackerpublicradio.org is not on a blacklist, but if possible, it may help to fix some of the warnings listed on http://mxtoolbox.com/domain/hackerpublicradio.org/ On Mon, May 25, 2015 at 3:13 PM, Dave Morriss wrote: > I'm a bit out of touch with this stuff, but I'm wondering if there's > something wrong with the DKIM setup. (My credentials are that I used to > manage the team that ran the mail system for the university I worked at; > not sure if any of their expertise rubbed off) > > I subscribed one of my Gmail accounts to the HPR list and saw this in > the header of one of the messages I received: > > dkim=temperror (no key for signature) header.i=@ > > I also receive digests to another account (I was testing a > digest-replying add-on for Thunderbird, honest). In the last digest > message I see the following in the header: > > X-Zen-Spam-Report: * -0.0 ZEN_HELO_PASS Passed HELO Reverse DNS Test > * -0.0 ZEN_PTR_PASS Passed Mail Relay Reverse DNS Test > * 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily > * valid > * 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid > * 0.0 RCVD_NOT_IN_IPREPDNS Sender not listed at > * http://www.chaosreigns.com/iprep/ > * 0.8 KAM_ASCII_DIVIDERS Spam that uses ascii formatting tricks > * -0.5 ZEN_PTR_PASS_GOOD Passed Mail Relay Reverse DNS Test - Good Rep > * 1.0 PDS_MARKETER_DKIMFAIL From ML but security fails > * 0.6 AWL AWL: Adjusted score from AWL reputation of From: address > > I don't know if this has anything to do with why Gmail is marking > messages as spam. Shame Google don't give such excellent reports as my > ISP, Zen :-) > > You'd have thought that in the possible reasons for spam-marking a > message this one would be trivial. > > Dave > > > ___ > Hpr mailing list > Hpr@hackerpublicradio.org > http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org > ___ Hpr mailing list Hpr@hackerpublicradio.org http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org
Re: [Hpr] Fwd: Constructive criticism
I'm with Morgellon. My Fast Forward and skip buttons works just fine. And its worth repeating, Please Ken, don't let one comment stress you out. On Wed, Nov 26, 2014 at 7:15 AM, Joshua Burton wrote: > I honestly don't understand what the problem is. It's a podcast, *just > fast forward*. I do it with plenty of stuff I listen to. Sorry if I > sound like a jerk, but I really don't see an issue with the intro length. > > Please Ken, don't let one comment stress you out. > > (I'm working on several shows to atone for my by attitude on this thread.) > > On Wed, Nov 26, 2014 at 7:26 AM, Ken Fallon wrote: > >> I'm finding it very hard to get a handle on the feedback from this >> thread. Although I suspect that may be a problem on my side. >> >> Can we take the text-to-speech engine and voice out of the discussion >> please as that's a technical and license issue. It *will* improve over >> time and suggestions on that topic can be directed to >> ad...@hackerpublicradio.org. >> >> Discussions on whether to include text-to-speech synopsis can and should >> be sent to the mail list. >> >> With that all said can someone please tell me what is considered "to >> long" ? >> >> I include the calculations below but the the length before the episode >> proper is 1 minute 22.47 seconds for those served from >> hackerpublicradio.org and 1 minute 16.44 seconds for those served from >> archive.org. That's an increase of 43.42 and 37.39 seconds respectively. >> For your information the outro is 1 minute. >> >> If we take out the date and the contact information, then the synopsis >> is reduced to 16.54 seconds (in this case), which reduces the total to 1 >> minute 13.23 seconds and 1 minute 7.19 seconds. >> >> Then if we move the sponsor mention to the end of the show, as it was >> before, it reduces to 55.59 seconds. >> >> After that we could (probably - no idea how to do it automatically) >> reduce it to 39.05 seconds by having the synopsis overlay the intro >> music. However that means that every show will get the intro added by >> the server. That could be a problem for some hosts as many like to add >> it themselves. On the other hand it would free you to include (or not) >> any theme music you desire, even building your own "brand". >> >> -- >> Regards, >> >> Ken Fallon >> http://kenfallon.com >> http://hackerpublicradio.org/correspondents.php?hostid=30 >> >> >> $ wget --quiet http://hackerpublicradio.org/say.php?id=1648 -O - | grep >> 'HPR_summary: ' | sed 's/HPR_summary: //' | espeak -w /tmp/x.wav; >> ffprobe -i /tmp/x.wav 2>&1 | grep Duration >> Duration: 00:00:25.78, bitrate: 352 kb/s >> >> $ ffprobe -i intro.flac 2>&1 | grep Duration >> Duration: 00:00:39.05, bitrate: 700 kb/s >> >> $ ffprobe -i sponsor-anhonesthost.com-hpr15.flac 2>&1 | grep Duration >> Duration: 00:00:17.64, bitrate: 827 kb/s >> >> $ ffprobe -i sponsor-archive.org.flac 2>&1 | grep Duration >> Duration: 00:00:11.60, bitrate: 815 kb/s >> >> $ ffprobe -i outro.flac 2>&1 | grep Duration >> Duration: 00:01:00.87, bitrate: 726 kb/s >> >> $ echo "It's Wednesday 26th of November 2014. This is H P R episode 1648 >> entitled \"Bash parameter manipulation\" and is part of the series >> \"Bash Scripting\". It is hosted by Dave Morriss and is about 41 >> minutes long. Feedback can be sent to dave dot morriss at gmail dot com >> or by leaving a comment on this episode. The summary is : \"A summary >> and aide memoire of Bash parameter expansion methods\"" | espeak -w >> /tmp/x.wav; ffprobe -i /tmp/x.wav 2>&1 | grep Duration >> Duration: 00:00:25.78, bitrate: 352 kb/s >> >> $ echo "This is H P R episode 1648 entitled \"Bash parameter >> manipulation\" and is part of the series \"Bash Scripting\". It is >> hosted by Dave Morriss and is about 41 minutes long. The summary is : >> \"A summary and aide memoire of Bash parameter expansion methods\"" | >> espeak -w /tmp/x.wav; ffprobe -i /tmp/x.wav 2>&1 | grep Duration >> Duration: 00:00:16.54, bitrate: 352 kb/s >> >> -- >> AnHonest Host >> 25.78 Current synopsis >> 39.05 intro >> 17.64 sponsor AnHonest Host >> 82.47 Total >> >> Archive.org >> 25.78 Current synopsis >> 39.05 intro >> 11.6sponsor Archive.org >> 76.43 Total >> -- >> AnHonest Host >> 16.54 synopsis >> 39.05 intro >> 17.64 sponsor AnHonest Host >> 73.23 Total >> >> Archive.org >> 16.54 synopsis >> 39.05 intro >> 11.6sponsor Archive.org >> 67.19 Total >> -- >> AnHonest Host >> 16.54 synopsis >> 39.05 intro >> 0 sponsor AnHonest Host >> 55.59 Total >> >> Archive.org >> 16.54 synopsis >> 39.05 intro >> 0 sponsor >> 55.59 Total >> -- >> AnHonest Host >> 0 synopsis >> 39.05 Intro + Current synopsis >> 0 sponsor AnHonest Host >> 39.05 Total >> >> Archive.org >> 0 synopsis >> 39.05 Intro + Current synopsis >> 0 sponsor Archiv
