Der Job wartete auf main - der Arbeitsbranch des Forks ist aber livekit
(main ist der ungenutzte Default). livekit ist jetzt zusaetzlich protected,
damit die maskierte GITEA_NPM_TOKEN-Gruppenvariable im Job ankommt.
Versions-Bump fuer den ersten CI-Publish (ersetzt den alten lokalen
.npmrc-Weg, Token dafuer rotiert).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PKhFj1S3UdD6xL2fbWPeYj
Registry-Entscheidung evidenzbasiert: das Package ist pnpm-Dependency von
ThreadNet-Webs apps/web, der Lockfile pinnt die Tarball-URL auf rohana -
Registry bleibt dort. Publish-Auth ueber CI-Variable GITEA_NPM_TOKEN statt
lokaler Klartext-.npmrc.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Build / build_full_element_call (push) Canceled after 0s
Build / build_embedded_element_call (push) Canceled after 0s
Build / build_sdk_element_call (push) Canceled after 0s
Build / Build Storybook (push) Canceled after 0s
Build & publish embedded packages for releases / Versioning (push) Canceled after 0s
Test / Run unit tests (push) Canceled after 0s
Test / Run end-to-end tests (push) Canceled after 0s
Upload translation files to Localazy / upload (push) Canceled after 0s
GitHub Actions Security Analysis with zizmor 🌈 / Run zizmor 🌈 (push) Canceled after 0s
Build / deploy_develop (push) Canceled after 0s
Build / docker_for_develop (push) Canceled after 0s
Build & publish embedded packages for releases / build_element_call (push) Canceled after 0s
Build & publish embedded packages for releases / Publish tarball (push) Canceled after 0s
Build & publish embedded packages for releases / Publish NPM (push) Canceled after 0s
Build & publish embedded packages for releases / Publish Android AAR (push) Canceled after 0s
Build & publish embedded packages for releases / Publish SwiftPM Library (push) Canceled after 0s
Build & publish embedded packages for releases / Update release notes (push) Canceled after 0s
Build Element Call / Build Element Call (push) Canceled after 0s
Live testing confirmed selecting VP9 always falls back to VP8 - SFU's
active codec allow-list never actually included it despite the
server-side config being deployed, root cause not yet identified.
Back to the known-working VP8/H.264/H.265 options.
Build / build_full_element_call (push) Canceled after 0s
Build / build_embedded_element_call (push) Canceled after 0s
Build / build_sdk_element_call (push) Canceled after 0s
Build / Build Storybook (push) Canceled after 0s
Build & publish embedded packages for releases / Versioning (push) Canceled after 0s
Test / Run unit tests (push) Canceled after 0s
Test / Run end-to-end tests (push) Canceled after 0s
Upload translation files to Localazy / upload (push) Canceled after 0s
GitHub Actions Security Analysis with zizmor 🌈 / Run zizmor 🌈 (push) Canceled after 0s
Build / deploy_develop (push) Canceled after 0s
Build / docker_for_develop (push) Canceled after 0s
Build & publish embedded packages for releases / build_element_call (push) Canceled after 0s
Build & publish embedded packages for releases / Publish tarball (push) Canceled after 0s
Build & publish embedded packages for releases / Publish NPM (push) Canceled after 0s
Build & publish embedded packages for releases / Publish Android AAR (push) Canceled after 0s
Build & publish embedded packages for releases / Publish SwiftPM Library (push) Canceled after 0s
Build & publish embedded packages for releases / Update release notes (push) Canceled after 0s
Build Element Call / Build Element Call (push) Canceled after 0s
Live-verified via matrix-rtc-sfu negotiation logs (2026-07-28): a real
VP9 publish attempt got "falling back to alternative video codec" -
enabledPublishCodecs was [VP8, H264, H265], no VP9/AV1. The client's
backupCodec masked this (silent regression to VP8, no visible failure),
but offering VP9/AV1 in the dropdown was misleading - selecting them has
no real effect right now. Trimmed the dropdown to VP8/H264/H265 (added
h265 as a real option - livekit-client's own VideoCodec type already
supports it). Also fixed screenShareCodec's default, which was "vp9"
(meaning every user who enabled the toggle without touching the codec
dropdown was silently requesting an unsupported codec) - now "vp8" to
match camera's default.
Build / build_full_element_call (push) Canceled after 0s
Build / build_embedded_element_call (push) Canceled after 0s
Build / build_sdk_element_call (push) Canceled after 0s
Build / Build Storybook (push) Canceled after 0s
Build & publish embedded packages for releases / Versioning (push) Canceled after 0s
Test / Run unit tests (push) Canceled after 0s
Test / Run end-to-end tests (push) Canceled after 0s
Upload translation files to Localazy / upload (push) Canceled after 0s
GitHub Actions Security Analysis with zizmor 🌈 / Run zizmor 🌈 (push) Canceled after 0s
Build / deploy_develop (push) Canceled after 0s
Build / docker_for_develop (push) Canceled after 0s
Build & publish embedded packages for releases / build_element_call (push) Canceled after 0s
Build & publish embedded packages for releases / Publish tarball (push) Canceled after 0s
Build & publish embedded packages for releases / Publish NPM (push) Canceled after 0s
Build & publish embedded packages for releases / Publish Android AAR (push) Canceled after 0s
Build & publish embedded packages for releases / Publish SwiftPM Library (push) Canceled after 0s
Build & publish embedded packages for releases / Update release notes (push) Canceled after 0s
Build Element Call / Build Element Call (push) Canceled after 0s
The camera/screen share MediaQualitySettings labels (moved to the Video
tab in the previous commit) had zero German translations - the en/app.json
source had all 10 keys, de/app.json had none, so German-locale users
would have just seen the English fallback text. Added proper German
strings, inserted alphabetically matching the file's existing convention.
'Bildschirmfreigabe' matches the term already used elsewhere in this
same locale file for screen sharing.
Build / build_full_element_call (push) Canceled after 0s
Build / build_embedded_element_call (push) Canceled after 0s
Build / build_sdk_element_call (push) Canceled after 0s
Build / Build Storybook (push) Canceled after 0s
Build & publish embedded packages for releases / Versioning (push) Canceled after 0s
Test / Run unit tests (push) Canceled after 0s
Test / Run end-to-end tests (push) Canceled after 0s
Upload translation files to Localazy / upload (push) Canceled after 0s
GitHub Actions Security Analysis with zizmor 🌈 / Run zizmor 🌈 (push) Canceled after 0s
Build / deploy_develop (push) Canceled after 0s
Build / docker_for_develop (push) Canceled after 0s
Build & publish embedded packages for releases / build_element_call (push) Canceled after 0s
Build & publish embedded packages for releases / Publish tarball (push) Canceled after 0s
Build & publish embedded packages for releases / Publish NPM (push) Canceled after 0s
Build & publish embedded packages for releases / Publish Android AAR (push) Canceled after 0s
Build & publish embedded packages for releases / Publish SwiftPM Library (push) Canceled after 0s
Build & publish embedded packages for releases / Update release notes (push) Canceled after 0s
Build Element Call / Build Element Call (push) Canceled after 0s
Previously these were only accessible under the "Developer" settings
tab, gated behind an explicit "Developer mode" toggle in Preferences -
functionally not developer-only at all (just resolution/framerate/
bitrate/codec pickers), just accidentally buried two clicks deep behind
a checkbox most users would never find or think to enable.
Extracted the MediaQualitySettings component out of
DeveloperSettingsTab.tsx into its own file and moved both usages
(camera + screen share) into the existing "Video" settings tab, visible
to all users without any special mode. DeveloperSettingsTab keeps
everything else (audio processing, connection stats, etc.) unchanged.
Verified: full project typecheck clean, production embedded build
succeeds.
Default was only [180p, 360p] simulcast fallback layers - a big
quality cliff straight to blocky 360p on minor network hiccups instead
of gracefully stepping down from the 1440p top layer. Added a 720p
middle rung. Also documented the likely real reason forcing video_codec:
vp9 broke calls (2026-07-28): LiveKit uses SVC for vp9/av1, not classic
simulcast, but buildPublishOptions() always builds simulcast-shaped
layers regardless of codec - needs a code fix before retrying vp9.
Setting video_codec: vp9 resulted in no audio/video being transmitted
in real calls (2026-07-28), despite server-side codec regression
fallback to VP8 appearing to work in LiveKit SFU logs. Root cause not
further isolated beyond this. Leaving video_codec unset (defaults to
vp8) with the same 1440p/60fps/bitrate bump confirmed working.
Sets higher default video quality ceiling (up to 1440p/60fps camera,
1440p/30fps screen share, VP9 preferred codec) via the media_quality
config block introduced in element-hq/element-call#3736. These are
seeded defaults users can still adjust in Settings, not hard limits.
Bumped embedded package to @sorb/threadnet-call-embedded.