Version: 3.4dev-20260820_025922
Commit: a452e80
Commit message: 🪄 Teach the Floo Network to Handle Social Links Without Freezing Time

MB672 continues the URL-handling hardening work with one simple goal: make social and music links richer without freezing the IRC event loop, while preserving Mediabot’s existing visual identity and behavior wherever it already worked well.

No database schema change was required.

---

🎵 Spotify — richer metadata, no Chromium tax

Spotify links were already recognized correctly, but the old path could spend several seconds in Chromium without gaining useful metadata.

MB672 now uses Spotify’s lightweight embedded structured data and moves runtime fetching through Mediabot::AsyncWorker.

For track links, Mediabot can now display:

• track title
• artist(s)
• release year
• human-readable duration

Example:

[Spotify] Bien cordialement - by The Toxic Avenger, Simone - 2022 - 7m 03s

The existing [Spotify] badge, colors and IRC formatting remain unchanged.

---

🍎 Apple Music — real artist, album and duration

Apple Music had two problems:

1. localized page labels could be mistaken for artist names — for example the Swedish word Låt;
2. track duration was missing.

For track URLs carrying an Apple song ID, MB672 now uses Apple’s structured lookup response and extracts:

• track title
• real artist
• album
• release year
• duration

The response is decoded directly from the returned JSON bytes, avoiding a UTF-8 pre-decoding edge case observed on real Apple responses.

Examples validated live:

[AppleMusic] Call Me - by Shinedown - album The Sound of Madness (Bonus Track Version) - 2008 - 3m 42s

[AppleMusic] Starrider - by Foreigner - album Foreigner (Deluxe Version) - 1977 - 4m 02s

Apple Music network work now runs asynchronously, while historical page/Chromium fallbacks remain available where appropriate.

The [AppleMusic] badge and its colors are unchanged.

---

🧹 URL anti-repeat cache — no more burned links

A real IRC test exposed a subtle cache bug.

Previously, posting a supported URL while its chanset was disabled could still arm the five-minute anti-repeat cache. Enabling the chanset immediately afterwards would then make the same URL appear to do nothing.

MB672 moves the cache gate so that an URL is cached only after the matching feature has accepted it.

The normal behavior is preserved:

• feature disabled → URL is not consumed by the cache
• feature enabled → URL is cached normally
• immediate repeat in the same channel → still suppressed
• same URL in another channel → still handled independently

This behavior was validated live by disabling and re-enabling AppleMusic around the same URL.

---

📘 Facebook Reels — remove the 22-second dead end

Facebook was the clearest runtime problem found during this pass.

For some public Reels, the initial HTTP request returned only Facebook’s generic shell. Mediabot then launched Chromium with a long timeout, only for Chromium to hit its alarm and provide no additional metadata.

A measured probe showed:

HTTP       : ~0.4–0.7 s
Chromium   : ~22 s, ALARM
Final data : still only "Facebook reel"

Further probes of Facebook’s public mobile, basic, watch and deprecated oEmbed surfaces confirmed that some Reels simply do not expose richer public metadata without an authenticated Meta API path.

MB672 therefore makes a deliberately conservative optimization:

• Reel with useful HTTP metadata → rich behavior preserved
• Reel with only the generic Facebook shell → skip the known-dead Chromium path
• non-Reel Facebook URL → historical Chromium fallback preserved

Real IRC validation:

Before:
07:52:52 URL
07:53:03 [Facebook] Facebook reel
≈ 11 s observed end-to-end

After:
08:10:59 URL
08:11:00 [Facebook] Facebook reel
≈ 1 s observed end-to-end

Rich Facebook results were also verified after the change:

[Facebook] ❤️❤️❤️❤️ | Poussière de fée

and:

[Facebook] it's Friday then, there's Saturday Sunday 😂😂 Tag a friend who's ready for the weekend! | We Rave You

Those rich cases answered in roughly one to two seconds during live testing.

The [Facebook] badge and visual charter remain unchanged.

---

🐦 X / Twitter — tested, deliberately left alone

Several real x.com and historical twitter.com URLs were tested.

Mediabot already returned rich results with author, handle, text and engagement counts, without any observed event-loop stall.

Example:

[X] Basic Apple Guy (@BasicAppleGuy) on X: "The new Liquid Glass Traffic Lights in macOS. 🔴🟡🟢" (1.2k likes, 16 RTs)

No application change was made for X/Twitter in MB672.

When something already works well, the safest optimization is sometimes not touching it.

---

▶️ YouTube and 🌐 generic URLs — intentionally untouched

YouTube’s URL handling is mature and has been exercised for years, so MB672 deliberately leaves it alone.

Generic URL handling was also checked with a real web page and produced the expected clean title:

URL tameteo.com Te[u]K: Carte des températures : Meteored

No unnecessary changes were introduced there either.

---

🧪 Regression coverage

MB672 adds dedicated regression tests for:

• Spotify asynchronous rich metadata
• Apple Music structured lookup and async behavior
• chanset-aware URL anti-repeat caching
• Facebook Reel fast fallback

Historical tests that were coupled to old internal implementation details were updated to assert the current functional contracts instead.

Final validation:

Focused Facebook + URL:
PASSED : 442/442

Fast suite:
PASSED : 5299/5299  (171s)

Full suite:
PASSED : 14058/14058  (769s)

All suites finished with RC=0.

---

🏰 Result

MB672 makes Mediabot’s URL pipeline noticeably more resilient without redesigning it:

• richer Spotify output
• richer and more reliable Apple Music output
• asynchronous network handling where it mattered
• correct chanset/cache interaction
• dramatically faster fallback for metadata-poor Facebook Reels
• no visual regression to existing badges
• no unnecessary change to X/Twitter, YouTube or generic URLs
• no database migration

The Floo Network still looks the same.

It just stops making everyone wait in the fireplace. 🔥