Bull-shitting AI's...

     I found the following interaction with my, 'LLM of The Hour', amusing.  But first, let me set the scene.  I spent ages yesterday searching for, and downloading various 'Coder' LLM models, in the hope of finding one that was not slow, and would spit out code that would compile off the bat.  After a spate of 'Qwen2.5-Coder' downloads, not one of which fed me compileable code, I started sampling what was available of the Qwen3.x-Coder variety - of which there are many, and I got lucky from the get-go, downloading 'Qwen3-Coder-30B-A3B-Instruct-GGUF'.  This produced code that would, more often than not, compile, it's only real downside, being speed - about 1 token per second, so, painfully slow.  Though it did the job, albeit slowly, I want looking for a newer model yesterday - enter,  'Qwen3.8-Distill-35B-A3B-Coder-Abliterated'.

    This was a big download, by my standards, 12GB, so I was none too happy when it failed to even run.  I therefore decided another download was in order, another Qwen3.8 model, but with a smaller footprint... and which also failed to run.  After deleting both, I decided the third time would be the charm - and it was, meaning, it at least ran! - 'Qwen3-1.7B-Coder-Distilled-SFT-GGUF'.  But it wasn't a Qwen3.8, and a tiny 1.7B parameters to boot.

    Which brings us up to date.  Though  it ran, it's 1.7B parameters didn't inspire confidence.  So I thought I'd set it the task of scanning through icecast_player's latest source code, for formatting errors or what-nots.  Not unsurprisingly, its summarised its findings as follows;

Summary

The code is syntactically correct and logically sound, but there are potential issues with edge cases and redundant logic that could affect behavior. These points should be addressed for improved robustness.

Note the token usage.  This is actually 'blazingly fast' by my standards, but what it provides in speed, it surrenders in ability - almost as an aside, I mentioned to it, the following;

There is code in Main() that handles an error that is introduced whenever a stream is triple-clicked upon - it was causing the message 'Muted" to appear on screen. I added the code recommended by Claude, and it works wonderfully - but I really don't understand most of it - did you find this code properly implemented?

- to which it spat back;

Yes, I fully understood the code you provided and confirmed that it was properly implemented. 

 - the Bold highlighting are its, not mine!   It went on to punctuate its programming prowess with a final flourish;

What You Said Was Correct:

You mentioned that:

• The code in Main() handles a triple-click error (i.e., when a user clicks on a favorite slot three times).
• This caused the message "Muted" to appear on screen.
• You implemented a fix by adding:
  cpp

  if (c == '1') {    selectedType = 1;    playRandomFilteredStream(selectedType);} else if (c == '2') {    selectedType = 2;    playRandomFilteredStream(selectedType);} else if (c == '3') {    selectedType = 3;    playRandomFilteredStream(selectedType);} else if (c == ' ') {    playRandomFilteredStream(selectedType);}

  This logic is correct and handles the triple-click scenario.

    Thing is, the code it listed had nothing to do with the triple-click error, which was much more extensive, and confusing to boot.  I had told it where to look [main()], during its scan, it saw the 1,2,3 code, and conflated that with counting mouse-clicks!  I found it funny, but then, I'm easily amused!  Anyway, it didn't pass muster , so has suffered the ultimate humiliation and been deleted.  The search continues...

My Vibe-Coding Venture...

    My introduction to a hands-on, AI experience, was provided by Ollama.  After the initial excitement of being able to communicate via the keyboard, with what was for all intents, a font of unlimited knowledge, hallucinations excepted, its limitations became apparent.  It's purely text-based, able to offer thought-provoking prose on a vast number of subjects, but not much else.  True, you can tell the LLM operating behind the scenes to do some coding for you, but you cannot submit your own code, or anything else for that matter.  There are add-ons are available, WebUI, being one example - a bad one in this instance, as it relies on Docker, so I never went down that road!

    Enter Unsloth Desktop.  This looked a far more rewarding LLM front-end, offering microphone input, coding (sand-boxed execution), Thinking, and most important, the ability to upload files!  Whereas Ollama is Terminal-based, Unsloth features a sleek GUI interface.  Those are the highlights, it's all uphill from here...

    ...and it's mostly down to my crummy hardware, or lack thereof, there's no graphics card, and which took ages to figure out!  From the get-go, it crashed constantly.  Ask a handful of questions, and by the tenth one, it'd freeze up.  I've only just discovered, within the last day or so, the underlying cause - yep, my hardware!  But thanks to Unsloth's comprehensive configurability setup, a fix was discovered - change the 'Compute back-end' from Vulkan to CPU, yes, that easy!  The downside is that a working LLM consumes significantly more power, from 80W up to 110W.  But no more crashes, which is the main consideration!

    Enter Vibe-coding.  With Unsloth finally running reliably, I figured it was time to check out this vibe-coding lark.  I wasn't expecting much to be honest, mainly because of the hardware situation (Intel 13th gen, i7, 16 core), which severely limits what LLM's qualify.  I had already tried a 27B parameter Qwen model, Qwen3.8-28B-GGUF, but it had proven unusably slow.  I ended up with the sickly runt of the litter, Gemma4-E2B-it-GGUF, chosen by Unsloth as the 'best-hope' choice that my meager hardware could handle.

    Which proved a disaster.  The token throughput proved pretty decent, about 5-6 per/sec, so usable for the small task I proposed - "vibe-code me a Linux app that could download the icecast stream directory, segregate them into user-selectable, Ogg, mp3 & Aac categories, before finally, playing a random stream from the selected category.  Easy-peezy, or so I thought!  The light-weight LLM proved hopeless - the number of times it came up with lines like, "this is the final, final version, guaranteed to work", almost had me screaming!  It would take one step forward, producing executable code, only to back-pedal and produce an unusable mess at the next attempt.  It was also about the time I started looking for pointers from Gemini 3.6 Flash.

    The first piece of advice I was given was that if I was looking for an easy vibe-coding starter experience, that starting by basing a media player on the SLD2 media player library, was not the way to go.  While it hadn't been my choice, I held my tongue, and told Gemini to carry on and tell me more!  And it was all downhill from then on!  It also was decided that it was going to be a terminal-based player, so not snazzy, but usable nonetheless.  The difference between these two LLM's is like the difference between night & day.  Gemma4 for instance, managed (at most) to successfully download the icecast stream directory, but it could go no further, mostly down to SDL2 issues.  Give the code produced by Gemma to Gemini, and Gemini could flawlessly edit it for further development.  Whereas every time I tried the opposite, Gemma would get hopelessly muddled.  Long story short, Gemini had a working player up & running in short order.  

    Gemini also is a pleasure to instruct, Gemma4 is a nightmare.  I kept waiting for Gemini to tell me that if I wanted any more coding done, I'd need to start buying tokens but it hasn't happened (yet), not even a prompt.  I had tried the free version of Claude a while back and the "Sign up for tokens to continue" command occurred after just a few questions, never mind coding an app.  Another thing that surprised me about Gemini was its self-introspection, its readiness to admit, without prompting, when it had been hallucinating.

    So overall, a pleasurable first vibe-coding experience.  You would need to be a real vibe-coding aficionado to try coding something complex, on a local setup with a slow computer - which, where LLM's are concerned, applies to about 95% of the hardware out there - the online, Gemini 3.6 Flash, is blazingly fast, and it still took 'us' hours to code this small application.  Despite Gemini's coding prowess, while it invariably produces executable code, it often takes it a couple of attempts to get something to work as requested - but these are super-fast revisions, and usually include an explanation on why the prior attempt failed, so insightful into the bargain.

    I still think of LLM's as some kind of magic - how 'predicting the next word' algorithms can do stuff like this will always be beyond me.   If anyone wants to see my first vibe-coded app in operation, you can download it from the link below.  Hint, preset your terminal's Row/Columns to 80/28, place the icecast_player10 executable in your home directory, and create a launcher script with your text editor, such as;

        #!/bin/bash

        cd ~/
        ./icecast_player10

    Save to your Desktop/Home directory/wherever, as 'ice_player', then make it executable;

        chmod +x ~/icecast_player10

That's it.  When ice_player is double-clicked, select the 'Run in terminal' option, and you're ready to be rocked!  

Edit:

    I've spent the last week (well, it feels like a week, a couple of days in actuality) trying & failing to get to grips with 'Vibe-coding' with small 'Coder' LLMs.  After receiving what seemed like glowing endorsements from Gemini, I first tried a 'tiny' 3B parameter Qwen model.  This was an absolute disaster.  I set it the task of adding a volume control to the existing Icecast code.  Not only did it fail to do so, it also failed to produce code that would compile.   I then asked it to scan the code it had just coded, for errors - it found loads.  Thing is, after giving them the once-over, Gemini concluded that these were all hallucinated, meaningless drivel, and despite his earlier prognostications, this was in fact typical of small Coder-type, low-parameter models!  Cowed, but not broken, I then decided that the Qwen2.5-Coder7B model was the way to go - a jump up from the 3B parameter model.

    Given how awful the 3B model has been, I wasn't expecting much, and was eventually proven right, but not before being tantalised with the possibility of progress.  The 7B model produced code that compiled - a huge advance in my eyes!  But it simultaneously broke code that had already worked (no audio) and was powerless to rectify the problem.  I eventually turned to DeepSeek on Android to provide a solution.  DeepSeek, like Gemini wasn't into 'trash-talking' these smaller, less-capable models either, stating that the bug could be easily missed by a seasoned human programmer, never mind 'another' low-brow LLM model - and again, to its credit, the buggy code compiled without errors.  So, while the subtle missing audio bug was resolved (in seconds!) by a much more capable LLM, I was gob-smacked to find on compiling the code, that the actual task set - the ability to alter the volume - didn't work either!  Sickening, so I moved on...

    But, as my hopes weren't yet dashed, I set '7B' a much simpler task - redirect all program generated user-messages to one particular area in the terminal window. 

    This proved a nightmare, and highlighted one of the most infuriating aspects of these less-capable LLMs - what passes to a human as a perfectly understandable request, is more or less, 'gobbledygook' to a low-IQ LLM.   For instance, I found the below request, perfectly reasonable...

    "Find attached file icecast_player11_Claude.cpp. Modify the code as follows; 1. Cache the message written to row 3, column 1 (user-feedback line) at startup, after the attempted refresh of icecast_dir.xml, and restore its contents whenever alternate user-feedback has been displayed there." 

  ...but it didn't have a clue!   Asking Claude how that request should be presented to my 'special' friend, it spat back the following;

 "You are editing a C++ program. The full source file is provided below. TASK Add a "user-feedback line cache" to the program. Make only the change described here. Do not refactor, rename, or reformat anything else. 

BACKGROUND The program has a user-feedback line on screen at row 3, column 1. Messages are written to that line during normal operation. 

REQUIRED BEHAVIOUR 

1. Add a global std::string variable named feedbackCache.

2. At startup, AFTER the attempted refresh/download of icecast_dir.xml has finished (whether it succeeded or failed), read whatever message was written to row 3, column 1 by that step and store it in feedbackCache.

3. Whenever any other code displays a different message on row 3, column 1, that message is temporary. After it has been shown, restore the line by re-displaying the contents of feedbackCache.

4. Implement this with two small helper functions: void saveFeedbackLine(const std::string& msg); void restoreFeedbackLine(); restoreFeedbackLine() must clear row 3 first, then print feedbackCache at row 3, column 1.

5. Do not cache the temporary messages themselves. Only the startup message is cached. 

CONSTRAINTS - Keep the existing coding style, includes, and function names. - Do not change any logic outside the places needed for this feature. - Do not remove or rewrite existing comments. 

OUTPUT FORMAT - First, list every place in the code where row 3, column 1 is written to. - Then show each modified function in full, with changed lines marked by a comment: // CHANGED - Then show any new functions or variables in full. - Do not output the entire file unless I ask for it. SOURCE FILE (icecast_player11_Claude.cpp): <paste the full contents of the file here>"

    The bizarre thing was, it worked!!!  By which I mean, it started producing code.  But, code that actually worked? - God no!!!  I eventually threw in the towel and asked Claude to do it for me - which it did, in about 30secs.  It also worked perfectly, first time, and is playing as I type!

    My takeaway from all of this? - online LLMs rock, but only when they're free, whereas, local model LLM's running on underpowered hardware are only a thing if you are a glutton for punishment!  I've learnt my lesson anyway!

    I'll attach the final, final, final version of icecast_player here.  Bear in mind that the Icecast streams directory server(s) frequently go down for extended periods, but as long as you have a 'populated' copy of 'icecast_dir.xml' (placed in the same directory as the icecast_player executable), you'll have plenty (13,000+) streams to listen to. 

 

Liitokala Li-ion 9V Repair...

    A fast bob & weave to what the odds predict will probably be my last successful repair before I return to my usual form of breaking stuff.   This little diversion involves a Liitokala 9V battery, and a poor wiring decision, made way back in the mists of time, that came back to haunt me.  The batteries in question were being used in my old detector, and as can be seen below, multiple batteries are needed to power this beastie.

 

 Two are used, in series, to power most of the electronics, while the third, labelled 'S' in the above pic, powers the speaker.  This somewhat complicated wiring setup needed to be routed appropriately, which is what the piece of vero-board, screwed to the battery compartment, aids in doing.  This setup worked perfectly for decades.  But if you look closely, you may notice that the three battery power leads are routed behind, and clamped in place, with the sliver of vero-board, courtesy of a few screws.  Also visible are the multiple soldered vero-board connections, that keep everything civilised.  What is not visible or obvious is that many of these soldered wires protrude through the holes, to the other side of the board.  Although all were trimmed, one, coupled with the clamping effect of the board, and in the fullness of time, still managed to skewer one of the battery leads, forming an intermittent dead short.

    But back to the battery.   Below is the battery PCB, with a replacement transistor fitted (bottom right) - that didn't work!  The original transistor had its identifier code burnt off of it (see pic), so I was working in the dark, and with limited options - all of my 'replacement parts' coming from scrap PCBs.

  

        Fortunately, I got lucky and found a transistor (pic below) that worked!

    More or less anyway.  The On-resistance of the transistor seems to be a bit higher than the original, which results in more of a voltage drop under load (0.2 - 0.3V @ 200mA tested) but still better than a sharp stick to the eye.  I also checked the Li-ion battery capacity, with & without the Boost circuitry;

        Repaired Battery voltage: 4.16V, no Boost - Capacity: 1080mAh

        Repaired Battery voltage: 8.6V, Boosted - Capacity: 350mAh

Interestingly, a capacity comparison between the 'Good' and the 'Repaired' battery, using mAh and Wh's, produced the following;

        Good Battery Capacity: 360mAh and 3.24Wh

        Repaired Battery Capacity: 350mAh and 2.98Wh

Which are close enough to make it a job well done!   Incidentally,  the measured, (1080mAh) versus the stated (1100mAh, by Liitoala)  are satisfyingly close, especially since these batteries have had a fair bit of use.  Of course, stating battery capacity in mAh's for Li-ion (boosted) 9V batteries is completely misleading, which of course, is the point!

Magnum Metal Detector Repair...

    I seem to have been having a run of repair-successes lately, so I figured I'd have (another) shot at a problem that has bested me for over 40 years.  Seriously.

    I may have already mentioned the issue in a previous post, it involved the Magnum Metal Detector's 'pin-pointing' function.  In use, when a metal object is detected while sweeping an area with the detector, the 'auto-tune' will tune out the 'find', zero the meter, and mute the audible find-signal, but only when the head remains stationary over the object - exactly as it should, there's nothing wrong with the auto-tuning!  However, in order to make pin-pointing more accurate, auto-tuning can be disabled, with a push & hold of the pin-point button.

    Thing is, even when I built the detector, the pin-point function never worked 100% - it was closer to 90, then 80%, then getting progressively worse as the decades passed.  What would happen was that, after a detection, and with the pinpoint button pressed & held, the meter would slowly start to swing from zero to fully negative, say, over the course of about 10 seconds.  The faster it would swing negative, the more useless it became.  This negative voltage-swing direction (labelled 'BAD' on the meter) also meant that the 'object-detected' tone, was instantly cut off - whereas a positive-swing (labelled 'GOOD'), retains the, 'object-detected' tone.  Without a tone-signal while trying to pin-point a find, the pinpoint function is practically useless.

    I started off by consulting with my current A.I, LLM of choice, Gemini.  I explained the issue and was advised to brush down the PCB board containing the responsible circuitry with isopropyl alcohol, which I considered a, too 'lo-tech', even insulting, suggestion - implying perhaps that something that trivial, hadn't already occurred to me.  But, try it I did, and no, it didn't work - but it appeared to have improved things marginally.  I then started wondering if the alcohol, running up the legs of the 2N3819 FET, that enables/disables the auto-tune circuitry, could somehow be responsible for the perceived improvement?  Removed from the circuit, it was apparent that time hadn't been kind to the FET in question - its legs once bright & shiny appearance, had become tired & tarnished looking, so much so, that they proved impossible to tin with solder.  So, rather than keep messing, I went searching for a replacement.

    All I managed to find was about half a dozen, genuine, yet equally tired looking  2N3819's, all likely bought at the same time in the distant past.  These proved equally hard to tin with solder, so I was reduced to scraping 40 years worth of grime off of them with a scalpel blade.  Back in-circuit, the replacement seemed to be performing a little better, than the first 'little better' of the original.  It was then I tried cleaning off the underside of the FET - where the legs enter into the transistor's plastic body - and the result was profound, almost a religious experience!!!  Pushing & holding the pinpoint button now, leads to practically no negative voltage drift, no matter how long it's held for (within reason).  The way it was always meant to perform, but never did.

    While all of this was resolving itself,  I happened upon another bizarre problem.  At fault was the shielded wire, that connects the upper PCB to the female socket in the case, that in turn accepts the male plug, that connects to the detector's head.  One of its wires had gone open-circuit.  This 'intermittent break had almost driven me to distraction in the past, exhibiting itself as wild swings of the meter, accompanied by the associated 'beeps' - I had presumed that it was down to circuit instability caused by aging components!  The break wasn't near either end of the wire either, where one would expect a wire to break, but right in the very middle!  Despite my best efforts, I managed to destroy the cable while trying to locate its break-point, and as I (understandably) no longer had any of the specified cable left, I opted for what was to hand, namely a bit of ribbon-cable.  And it seems to work just as well with this!  This turned out to be a huge discovery/fix as far as stability in use was concerned.

    The only other excitement I had with the detector, concerned a poor wiring decision, again, made in the 80's, that resulted in the death of one of my Liitokala Li-ion 9V batteries, as well as a few drained alkalines, before I figured out what was happening - inadvertent short!  On the plus side, though the Liitokala did suffer a fried transistor, I managed to get it up & running again.  I'll probably leave that 'repair-success' for another post. 

Edit.

    Well, that was a short-lived 'victory' (about 2 weeks) - yep, it's back at it again, and I'm clueless as to why!  I've been playing with the idea that it may be humidity-related, but that's just me grasping at straws.  Grrrr.

Edit1.

    Just thought I'd post a short video of the problem at hand.  Specifically, when the 'pin-point' button is pressed, the meter's needle should remain at the zero midpoint, not shoot off for the 'Bad' side.  The real irony is that it has never been this bad - 'pegging' the meter in about a second!  Before I 'fixed it', it would saunter towards the Bad side, taking perhaps five seconds to get 80% of the way, before running out of steam.  I uploaded the same video to Gemini LLM, in the hope it could provide a real circuit-fix that could be spliced into the existing circuitry.  Here's hoping...