Commit History
12 days ago
-
Classify RTMPS filter timeouts as output failures Running
Verified signatureKeep YouTube output timeouts on the ingest-recovery path instead of switching a healthy TikTok FLV source to HLS.facb3d2
17 days ago
-
v2.45: port dual ingest and probed canvas fixes
Arena.ai Agent88a11cc
18 days ago
-
v2.42 start supervisor: recover a stuck YouTube start by restarting the sender (fresh dual ingest) after 150s unconfirmed, max 3 attempts
Verified signaturee96d7f0 -
v2.42 start supervisor: recover a stuck YouTube start by restarting the sender (fresh dual ingest) after 150s unconfirmed, max 3 attempts
Verified signature3caae3e
19 days ago
-
v2.41 dual simultaneous YouTube ingest (primary+backup tee fan-out)
Verified signatureafc0acb -
relay-v2.40-avfill-splice: apply On-validated A/V fill splice fix fleet-wide
Verified signatureOperator-approved fleet rollout of the On trial: sequence headers stamped 0 no longer consume the splice bias, bridge operations are serialized, fill writes are deadline-bounded, and the watchdog no longer shields a stalled/inflated fill.93faff2
23 days ago
-
restore: fleet-standard relay-v2.37-fill-span (identical to other 4 Spaces; guestwatch experiment removed)
Verified signature812e0d6 -
guestwatch v2.45: phone bridge receiver
Verified signature190142f -
guestwatch v2.44: anonymous-only (account safety)
Verified signature76fc558 -
guestwatch v2.43: authed host-room seat scan
Verified signaturef55ba47 -
remove browser eye (operator request); relay-v2.42-guestwatch-pro
Verified signaturef8d328a -
guestwatch v5: browser eye (relay-v2.41-guestwatch-browser)
Verified signature6a91d9f -
guestwatch v4: professional signed eyes (relay-v2.39-guestwatch-pro)
Verified signaturee3ee752 -
guestwatch v3: host-side link_mic scan + sticky guest
Verified signature870936d
24 days ago
-
guestwatch v2: authenticated second eye for guest anchor
Verified signature5038ebd
25 days ago
-
guestwatch: add missing test file referenced by Dockerfile COPY
Verified signature9552c1a -
guestwatch: ship guest_probe.py in image (Dockerfile COPY list)
Verified signature510b7b0 -
guestwatch diag: cycle visibility
Verified signature4a89200 -
v2.38-guestwatch-dev: guest (LinkMic) detector + recorder (GUEST_WATCH gate, detection-only)
Verified signatureb01425e
26 days ago
-
v2.37-fill-span: bound watchdog fill exemption + pump renewal by whole fill episode (fill_until)
Verified signature3bb3c7d -
Renew stdin write deadline while gap-filling (v2.36-fill-renewal)
Verified signature0903cad -
Post-fill/reattach seam credit for write deadline (v2.35-seam-credit)
Verified signaturef7ce307 -
Keyframe-gated resume + fill-credit write deadline (v2.34-keyframe-gate)
Verified signature8f3ab83 -
Persistent room format lock + fill/swap-aware write deadline (v2.33-format-lock-fillguard)
Verified signatured0d9c7c
27 days ago
-
Exact copy of Reoo88/On @ 826bfe0 (relay-v2.32-gap-filler)
Verified signaturef847423
30 days ago
-
نتيجة تنبيه بدء البثّ تُظهر الوجهات التي وصلت ومعرّف كل رسالة
arenad15ab1d -
تنبيه بدء البثّ المباشر إلى تيليغرام + حذف الحسابين غير الموجودين
arena- telegram_api: notify_live_start()/notify_targets()/live_start_text() — رسالة باسم المذيع والتاريخ والوقت إلى القناة والحساب الشخصي، مرة لكل بثّ (منع التكرار بـroom_id في السجلّ الدائم)، وأي فشل يُسجَّل ولا يرمي استثناءً. - app.py: خطّاف في حلقة المراقبة قبل أول اتصال بالمصدر + POST /api/telegram/notify-test. - index.html: زرّ تجربة التنبيه وسطر حالة 🔔 في لوحة تيليغرام. - Dockerfile/variables.env: LIVE_NOTIFY=on, LIVE_NOTIFY_TARGETS=both, LIVE_NOTIFY_TEXT. - اختبارات §18 (33) ⇒ 159/159.eef656f -
Re-split when a keyframe cut leaves a part over the ceiling
Reooiq96Live test showed why this matters: ffmpeg -f segment cuts at keyframes, so a 9.75MB file split with a 4MB target produced an 8.0MB part (2x the target). Sparse keyframes on a 2000MB ceiling would waste a multi-GB upload before Telegram rejected it. After splitting, every part is measured; if any exceeds the ceiling the parts are deleted and the file is re-split once at half the target. Only if a part is still over does it retire FAILED, with a note naming the cause, and the original file stays on disk. Section 17 (7 checks) drives an uneven first split and asserts the re-split, the successful album, and full cleanup. 126/126 + 9/9.13a0927 -
Split over-limit broadcasts and send them as ONE album
Reooiq96A broadcast longer than the upload ceiling used to retire FAILED and stay on disk. Now it is split without re-encoding (ffmpeg -c copy -f segment, cut at keyframes, so the original quality is preserved bit for bit) into parts of at most ARCHIVE_PART_MB (default: 95% of the current ceiling, i.e. 1900MB local / 47MB public), and the parts are delivered as a single sendMediaGroup album. Order matters: parts are uploaded to the BACKUP chat first, which satisfies the mandatory-backup rule and yields file_ids, then the channel album is composed from those file_ids with no second upload of the data. Album max is 100 items (~190GB locally). Local deletion (original AND every part) still happens only after both deliveries. Resume safety: part_file_ids are persisted after each part, so a failed album step never re-uploads anything. Verified against the real Bot API before coding: sendVideo with a file:// path pushed a 56.7MB part in 2.7s through the local server, and the album key must be 'me…fee6c6c -
Local mode: send the file as a file:// URI, not a bare path
Reooiq96Found live: with TELEGRAM_API_ID/HASH set the local Bot API server rejected every upload with Bad Request: invalid file HTTP URL specified: URL host is empty because it parsed the bare absolute path as an HTTP URL. This broke ALL archiving once local mode was active, not just large files. file_uri() now resolves the path and uses Path.as_uri(), which also percent-encodes spaces and Arabic filenames. Section 15 (11 checks) pins the wire format: field starts with file://, equals the absolute URI, no multipart in local mode, request goes to :8081. 96/96 + 9/9 green.20d4d65 -
Retry read-only Telegram calls on transport errors
Reooiq96api.telegram.org intermittently drops connections from the Space: six queue cycles in a row failed at getChat during a live test, delaying an archive by 90s. getChat/getMe now retry twice (1.5s, 3s) on transport errors only. Sends keep a single attempt on purpose: a duplicate sendMessage would post twice to the channel if the request landed but the reply was lost. Section 14 (4 checks) covers both halves. 84/84 + 9/9 green.189b53a -
Surface why the local Bot API server is not ready
Reooiq96local_ready() already required ok:true, so wrong TELEGRAM_API_ID/API_HASH fell back to the public 50MB API silently. The probe now keeps Telegram's own reason (e.g. 'Unauthorized: invalid api-id/api-hash'), exposes it as snapshot 'local_error' on both /api/telegram and /api/archive, shows it in the dashboard, and names the missing variables when they are unset. Verified the v10.3 binary runs and binds :8081 locally, answering 401 for dummy credentials. Tests: section 13 (9 checks) covers wrong creds, unset creds, and that the cap stays 50MB rather than claiming 2000MB. 80/80 + 9/9 green.3787e28 -
Show the real cause when channel adoption fails
Reooiq96_process() reported str(APIError), which is only 'networkOrInvalidResponse (status=None)'. The underlying exception text lives in e.detail; append it so a transient getChat failure is explainable from the dashboard instead of opaque.2d2b6e5 -
Rename deploy_hode_arch.py -> deploy_space.py and deploy its own directory
Reooiq96SRC was a stale absolute path (/home/user/hode_arch) from the previous project; it now resolves to the folder the script lives in, so it always deploys this codebase. verify_tokens.py checked: no YouTube/Google references remain.5dcb9bc -
Fix real Telegram uploads: curl_cffi needs multipart=, not files=
Reooiq96curl_cffi raises NotImplementedError for files=, so every real sendVideo failed with a generic networkOrInvalidResponse while all 57 tests passed (the fake bot never touches the transport). Now send_file builds a CurlMime form and lets libcurl stream the file from disk via local_path, with a single in-memory retry for network mounts. Adds section 12 (14 regression checks) that intercepts curl_cffi.requests.post and asserts multipart= is used and files= never is. Verified against the real Bot API: a 9.75MB MP4 uploaded in 4.2s, and the same file re-sent by file_id in 0.6s with no second upload. 71/71 tests pass.87ad6ea -
Make Telegram transport failures diagnosable + in-memory retry
Reooiq96- send_file/call now carry the real exception text in APIError.detail instead of hiding it behind 'from None'; the retry note shows it in the dashboard. - /data is a network (FUSE/S3) mount: if streaming multipart reads fail, retry once with the file contents in memory (files <=64MB, i.e. the public 50MB cap). - snapshot() uses an 8s getMe timeout so the Telegram panel never hangs 30s cold.22d89cb -
Restore README YAML front matter (sdk: docker, app_port: 7860)
Reooiq96The V15 docs rewrite accidentally dropped the metadata block, which left the Space with sdk=null and stage=CONFIG_ERROR.7b6ed27 -
V15: replace YouTube archiving with Telegram
Reooiq96- Removed youtube_api.py, youtube_core.py, youtube_archive.py and their tests - Added telegram_api.py (Bot API transport, local-server discovery, chat identity) - Added telegram_archive.py (same queue/join-window/retry engine, Telegram transport) - Primary destination: TELEGRAM_CHAT_ID; backup copy sent by file_id (no second upload) - Local telegram-bot-api (--local) support raises the file cap 50MB -> 2000MB - entrypoint.sh starts the local server when TELEGRAM_API_ID/HASH are present - Dashboard, README, VARIABLES.md, variables.env and deploy script updated - Recorder untouched: TikTok FLV -> mkvmerge -> ffmpeg -c copy -> MP4 - Tests: 57 archive + 9 dashboard regressions passing096481b
-
Update index.js
Verified signature8854f46 -
Update index.js
Verified signaturecc2ba3c -
Update index.js
Verified signature101925f -
Update index.js
Verified signature608dba2 -
Update index.js
Verified signature93e2add -
Update index.js
Verified signature2c9ab39 -
Update index.js
Verified signatureba969cb -
Update index.js
Verified signatureb329e5b -
Update index.js
Verified signature06e191f -
Update index.js
Verified signature9a54bf1 -
Update index.js
Verified signaturec533816 -
Update index.js
Verified signature558e97d