Initial commit: HPR Knowledge Base MCP Server

- MCP server with stdio transport for local use
- Search episodes, transcripts, hosts, and series
- 4,511 episodes with metadata and transcripts
- Data loader with in-memory JSON storage

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>

hpr_transcripts/hpr1181.txt

@@ -0,0 +1,88 @@
+Episode: 1181
+Title: HPR1181: Mumble Audio Issues
+Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr1181/hpr1181.mp3
+Transcribed: 2025-10-17 21:06:58
+
+---
+
+Greetings, Delan here again.
+After getting feedback on the last mumble episode, I thought it might be worthwhile to take
+a few minutes to talk about some of the specific audio issues people encountered and what
+can be done about them.
+There seem to be four main issues that people typically experience, and we're going to
+be working in the audio input setting section with advanced options toggled on.
+The checkbox for the advanced options is located in the lower left corner of the configured
+screen.
+Going through the audio wizard does many of these things automatically, but if you're
+going to try and fine tune your audio, I think it's simpler to do it this way.
+The first and most common issue is static or peeking, particularly when speaking loudly,
+and it sounds something like this.
+Okay, with luck, this should be badly overdriven.
+The first step in addressing this is to decrease your amplification in your mumble audio
+settings.
+If you have decreased the amplification within mumble to 1.0, it's lowest setting, but
+you're still experiencing peeking, then you'll need to adjust your microphone input level
+in your sound card mixer settings.
+The second problem is quiet audio, which I suggest handling in the opposite direction.
+First, adjust your mixer settings and raise your mic level as high as you're comfortable
+with, and then try the amplification settings within mumble.
+The third is distorted or warbling audio, which might sound something like this.
+And this should be what it sounds like when noise suppression is too high.
+This is generally caused by the noise suppression settings.
+Noise suppression attempts to act as a filter to remove background noise, but when it is set
+too high, it can distort your audio and make it sound almost watery for lack of a better
+term.
+Mumble defaults to negative 30 decibels, but I find that negative 15 to negative 20 tends
+to offer a better balance between distortion and background filtering.
+Results can vary pretty wildly here, and it all depends on the noise level in your environment
+and the microphone you're using.
+The fourth is choppy audio, like this.
+This is typically a result of a poor internet connection rather than audio settings.
+The first thing to try is to turn off the quality of service settings in mumble, which
+are located in the network section.
+It's not likely that this will help.
+It seems to be more affixed for when your client is being repeatedly dropped by the server,
+but turning it off will help eliminate one possible source of trouble.
+Just try adjusting your audio per packet in quality settings, found in the advanced audio
+input section.
+I recommend increasing your audio per packet settings, and then decreasing your quality
+settings.
+But be aware that once you drop below about 45 kilobits per second, you'll be using
+speaks rather than kelt as your audio codec.
+Mumble will tell you which codec you're trying to use under the audio per packet slider,
+so it will let you know once you've crossed that threshold.
+I should also note here that mumble 1.2.3 is starting to ship without speaks support
+in some distros, and once 1.2.4 drops, the preferred codec will be opus.
+If you run into an issue where people can't hear one another, this is almost certainly
+the cause.
+The answer for the time being is to try to get everyone on kelt.
+Yes, this is a bit of a pain in the ass.
+As a year ago, speaks was the codec all installations had in common.
+And yes, we're probably going to go through this rigmarole again once 1.2.4 comes out,
+at least until everyone is fully on board with opus.
+And in the last episode I did about mumble, I mentioned that you can turn on loopback either
+locally or from the server in order to hear your own audio.
+This works well, but it requires you to listen to your voice as you're speaking, which
+can be a little confusing.
+However, there is another option which might work better for you.
+Evebot was written to capture audio from one channel and then transmitted into another
+channel after a delay, mainly used during game tournaments to match team communications
+with the delayed video feed.
+However, you can also use it as a delayed loopback for an audio testing channel.
+When you give the bot the command to connect, tell it to use the same channel in the eavesdrop
+and relay options.
+It's smart enough to avoid going into a mimic spawning loop.
+I like to set the delay to 10 seconds, as a shorter delay doesn't give me enough time
+to say enough to get a decent idea of what the audio is actually sounding like.
+You can find Evebot at Freemaster, f-r-y-m-a-s-t-e-r dot 1-2-7-001 dot org slash mumble.
+You have been listening to Hacker Public Radio, or Tacker Public Radio does our.
+We are a community podcast network that releases shows every weekday on day through Friday.
+Today's show, like all our shows, was contributed by a HPR listener like yourself.
+If you ever consider recording a podcast, then visit our website to find out how easy
+it really is.
+Hacker Public Radio was founded by the Digital Dog Pound and the Infonomicom Computer Club.
+HPR is funded by the binary revolution at binref.com, all binref projects are proudly sponsored
+by Lunar Pages.
+For shared hosting to custom private clouds, go to LunarPages.com for all your hosting needs.
+Unless otherwise stasis, today's show is released under a creative commons, attribution,
+share a line, free those own license.