From Fresh Debian 13 to Mediabot 3.1

A lot of work has gone into mediabot_v3 recently, and one of the most useful parts of it was not glamorous at all:

a real install test from scratch on a fresh Debian 13 system.

That kind of test is brutally honest. It does not care that the bot “works on my server”. It does not care that some dependency was already present, or that a local database had already been patched six months ago, or that an old config file happened to hide a broken code path.

It just tells the truth.

And that truth was useful.

Why this mattered

mediabot_v3 has been running, evolving, and surviving for a long time, but the goal now is bigger than “it works here”.

The goal is a real release path.

That means:

• clean installation
• clean startup
• predictable runtime behavior
• no silent schema mismatches
• no hidden dependency traps
• no features that only work after three manual hacks and a lucky moon phase

So the fresh Debian 13 test became a very good filter: anything that failed there deserved attention.

What was improved before and during the Debian 13 test

A lot of earlier work had already prepared the ground.

URL title handling was hardened

Several handlers were cleaned up and stabilized:

• Instagram
• Spotify
• Apple Music
• generic URL titles

That included:

• better UTF-8 handling
• safer parsing
• filtering of useless placeholder titles
• Chromium fallback for JavaScript-heavy pages
• cleanup of dead helper code
• less fragile URL matching

This made the bot more reliable when dealing with modern websites that no longer expose useful metadata in a simple static page.

Restart, jump, and rehash were cleaned up

The bot lifecycle also received serious attention:

• server selection logic was clarified
• jump became more predictable
• restart behavior was hardened
• rehash became a real runtime refresh instead of a cosmetic reload

That matters a lot for a future release, because runtime administration is one of the first places where fragile software exposes itself.

Nicklist handling became much more robust

Nicklist handling got its own serious cleanup:

• periodic per-channel refresh timers
• proper NAMES buffering
• clean finalization on RPL_ENDOFNAMES
• no more dangerous duplication/flood behavior
• proper reaction to nick changes

This directly improved commands like nicklist and rnick, and made internal channel state much healthier.

What the fresh Debian 13 install exposed

The clean install test was very useful because it exposed the kind of issues that a long-lived dev environment often hides.

SQL install mismatch

The database creation failed because the schema tried to add a foreign key on TIMERS.id_channel even though that column does not exist in the deployed schema.

That was fixed by aligning the install SQL with reality instead of pretending the future schema was already there.

Perl dependency problems

The bot also failed on a fresh system because some modules were either:

• still referenced even though no longer used
• or not reliably installed by the CPAN helper scripts

Examples included:

• removing an unnecessary Twitter::API dependency
• fixing the CPAN install helper logic
• improving the way Perl module installation failures are handled
• preserving a dedicated fallback path for Hailo

CPAN install logic was too fragile

The install scripts were also exposing a subtle shell bug: the old loop structure could fail inside a subshell while the main script kept going as if everything was fine.

That is the sort of issue that can make an installation look “successful” even when it is not.

That behavior was corrected so installation failures now behave honestly.

Live test framework issues

The live test framework also needed attention:

• SQL quoting needed correction
• the test authentication setup needed cleanup
• helper visibility issues were exposed by a real fresh install
• test schema assumptions had to be brought back in line with the current codebase

Again, that is exactly why fresh-system testing matters.

Why this is good news

At first glance, finding all these issues may sound discouraging.

It is actually the opposite.

This is what progress looks like when a project starts moving from “long-running beta” toward “real release candidate”.

The important thing is not pretending those issues do not exist.

The important thing is:

• finding them
• fixing them cleanly
• testing again
• and reducing the number of surprises one by one

That is what happened here.

What this says about Mediabot 3.1

The project is not just collecting features anymore.

It is being tightened:

• install path
• runtime behavior
• schema coherence
• dependency handling
• admin commands
• channel state tracking
• test framework reliability

That is the kind of work that makes a release credible.

And that is why the Debian 13 fresh install test matters so much: it is not just a technical exercise, it is part of deciding whether mediabot_v3 is finally ready to stop hiding behind the word “beta”.

What comes next

There is still work to do:

• finish validating the live test framework
• complete the install tests
• do a final review of packaging and release expectations
• make sure what works on the development machine also works on a truly fresh system

But the direction is now much clearer.

The project feels closer to a real release than it has in a long time.

And if the remaining install and runtime checks go the way they should, the next step will not just be another random dev snapshot.

It will be the road toward Mediabot 3.1.