Fix 21125

[antobinary]

What does this PR do?

Fixes recording playback links ignoring /etc/bigbluebutton/recording/recording.yml overrides (playback_host / playback_protocol), reported for bbb-playback-video in bigbluebutton#21125 but actually affecting several formats, in three parts:

• Formats bypassing the override: the screenshare (process + publish), notes (process + publish) and podcast (process + publish) scripts loaded bigbluebutton.yml directly, so the override file was never consulted. They now load props via BigBlueButton.read_props, the same override-merging loader the presentation and video formats already use.
• Stale links on publish: the video and screenshare publish scripts copied the process-time metadata.xml verbatim, so a playback link baked in at process time was never refreshed — changing the override afterwards (and republishing) had no effect, forcing admins to hand-edit metadata files. The publish scripts now regenerate <playback><link> from current props at publish time, matching the presentation format.
• Stale config in long-lived workers (reworked from Reload recording overrides per read so bbb-playback-video metadata links use current playback host/protocol bigbluebutton/bigbluebutton#25042, which targeted v3.0.x-develop): read_props cached its result in a module ivar, so the resque workers kept serving stale config until restarted. It now re-reads both files on every call, uses YAML.safe_load (with aliases: true), tolerates an empty override file (previously a TypeError crash), and takes the override path as a parameter for testability. A minitest covers merge precedence, per-call reload, and the empty/missing override cases.

Docs: configuration-files.md gains the video.yml override row, notes on the recording.yml row, and a playback_host/playback_protocol example including how to correct links of already-published recordings (bbb-record --rebuild).

Closes Issue(s)

Closes bigbluebutton#21125

Motivation

Deployments that terminate TLS elsewhere or serve playback from a different hostname configure playback_host/playback_protocol in recording.yml, and integrations like Greenlight consume the link from metadata.xml. When formats bypass the override — or workers cache it — published links point at the wrong protocol/domain and every affected recording needs manual correction.

How to test

1. Create /etc/bigbluebutton/recording/recording.yml with a distinctive playback_host (e.g. playback.example.com) and playback_protocol: https. Do not restart the recording workers.
2. Record a meeting and let the video (or screenshare/notes/podcast) format process and publish it.
3. Check metadata.xml in the published directory: <link> must use the override host/protocol.
4. Republish test (video/screenshare): change playback_host in recording.yml, remove the published dir and the status/published/<id>-video.done file, re-run the publish script only — the published link must reflect the new value without reprocessing.
5. Unit test: cd record-and-playback/core && bundle exec ruby -Ilib test/recordandplayback/test_read_props.rb.

Verified on a 4.0 (v4.0.x-develop) server: the previous direct-YAML load returns the non-override host while read_props returns the override; the publish-time refresh rewrites a stale process-time link to the current override URL for both video and screenshare link formats; and the new minitest passes (4 runs, 8 assertions) under the server's Ruby 3.2 bundle. All modified scripts pass ruby -c.

More

• Supersedes Reload recording overrides per read so bbb-playback-video metadata links use current playback host/protocol bigbluebutton/bigbluebutton#25042 (same author intent, rewritten and retargeted at v4.0.x-develop — can be closed if this merges).
• Out of scope: a few core utility scripts (events_archiver.rb, rap-process-worker.rb, caption utilities, post_events examples) still read bigbluebutton.yml directly; none of them build playback links.
• Added/updated documentation

🤖 Generated with Claude Code

[github-actions]

🚨 Automated tests failed

• Github workflow run