javis_bot

tkrmagid/javis_bot

Fork 0

Commit Graph

Author	SHA1	Message	Date
javis-bot	bbc2fa3f7a	refactor(stream-test): real-wheel into view, no synthetic-click fallback Address review accuracy: humanClick used DOM scrollIntoViewIfNeeded and fell back to Playwright locator.click() when an element had no box - neither is real input. Now it brings elements into view with a real wheel scroll and throws if there is no on-screen box (no synthetic click). Header comment and README corrected: xdotool injects synthetic X input (not a physical HID device), and all actions are real input while the CDP/DOM API is used only to read state.	2026-06-10 14:15:26 +09:00
javis-bot	2cdd159fc1	feat(stream-test): drive the whole browse scenario with real input Make every action real keyboard/mouse via xdotool, not just the visible browsing: address-bar navigation (Ctrl+L + char-by-char typing), the YouTube settings gear -> 화질 -> 1080p menu (real clicks, verified hd1080), the autoplay toggle, the play button, and fullscreen via the real 'f' key (F11 isn't honored by this WM; 'f' yields true 1080p fullscreen without pausing). CDP/DOM API is now used only to read state for verification.	2026-06-10 14:11:58 +09:00
javis-bot	1e30a49562	fix: cap selfbot stream -maxrate at lib's 10 Mbps ceiling; add stream-test tooling - selfbot.ts: the @dank074 lib advertises a hardcoded max_bitrate of 10 Mbps to Discord (BaseMediaConnection: `max_bitrate: 10000 * 1000`). Our encoder used -maxrate = 1.5x target (12 Mbps at 8 Mbps target), so high-motion bursts exceeded the negotiated ceiling and WebRTC dropped packets (viewer stutter). Cap -maxrate at 10 Mbps. - Add bot/scripts/stream-test/: env-driven stream-hold.ts (persistent Go-Live holder), human.mjs (real xdotool mouse/keyboard + char-by-char typing), and scenario.mjs (YouTube/Naver browse). Channel/guild/video are env-parametrised. - .env.example: document DISCORD_VOICE_CHANNEL_ID for the stream-test scripts.	2026-06-10 12:50:24 +09:00

Author

SHA1

Message

Date

javis-bot

bbc2fa3f7a

refactor(stream-test): real-wheel into view, no synthetic-click fallback

Address review accuracy: humanClick used DOM scrollIntoViewIfNeeded and fell
back to Playwright locator.click() when an element had no box - neither is real
input. Now it brings elements into view with a real wheel scroll and throws if
there is no on-screen box (no synthetic click). Header comment and README
corrected: xdotool injects synthetic X input (not a physical HID device), and
all actions are real input while the CDP/DOM API is used only to read state.

2026-06-10 14:15:26 +09:00

javis-bot

2cdd159fc1

feat(stream-test): drive the whole browse scenario with real input

Make every action real keyboard/mouse via xdotool, not just the visible
browsing: address-bar navigation (Ctrl+L + char-by-char typing), the YouTube
settings gear -> 화질 -> 1080p menu (real clicks, verified hd1080), the autoplay
toggle, the play button, and fullscreen via the real 'f' key (F11 isn't honored
by this WM; 'f' yields true 1080p fullscreen without pausing). CDP/DOM API is
now used only to read state for verification.

2026-06-10 14:11:58 +09:00

javis-bot

1e30a49562

fix: cap selfbot stream -maxrate at lib's 10 Mbps ceiling; add stream-test tooling

- selfbot.ts: the @dank074 lib advertises a hardcoded max_bitrate of 10 Mbps to
  Discord (BaseMediaConnection: `max_bitrate: 10000 * 1000`). Our encoder used
  -maxrate = 1.5x target (12 Mbps at 8 Mbps target), so high-motion bursts
  exceeded the negotiated ceiling and WebRTC dropped packets (viewer stutter).
  Cap -maxrate at 10 Mbps.
- Add bot/scripts/stream-test/: env-driven stream-hold.ts (persistent Go-Live
  holder), human.mjs (real xdotool mouse/keyboard + char-by-char typing), and
  scenario.mjs (YouTube/Naver browse). Channel/guild/video are env-parametrised.
- .env.example: document DISCORD_VOICE_CHANNEL_ID for the stream-test scripts.

2026-06-10 12:50:24 +09:00

3 Commits