exostring/redairsoft_vk_gt_max_sender
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Never route videos through sendRichMessage - mobile black-screens them

Browse Source 
Per Telegram's rich-messages spec (Bot API 10.1, released ~3 months before
this), our <video src="tg://video?id=..."> block syntax is exactly correct -
no documented issue with it. But isolated testing (posting the same
already-uploaded file both ways) proved the plain send_video call renders
fine on Telegram mobile in fullscreen, while the identical video referenced
from a sendRichMessage <video> block black-screens there every time. Neither
the faststart remux, the negative-DTS fix, nor the width/height fix changed
this - it's specifically the rich-message video renderer on mobile, not our
file.

sendRichMessage was only ever used for posts whose caption doesn't fit
Telegram's normal 1024-char limit; send_media_post already handles that
overflow correctly via follow-up text messages, so this isn't a regression
for long captions - it now always takes that path when a video is involved.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This commit is contained in:
exostring
2026-09-09 20:17:11 +05:00
parent 56f3cfaac2
commit d1a442ca7a
1 changed files with 9 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files
src/tg_poster.py
+9 -1
View File
@@ -481,7 +481,15 @@ class TelegramPoster:
normal_limit = self.caption_limit if valid_media else self.message_limit normal_limit = self.caption_limit if valid_media else self.message_limit
fits_normal_limit = len(formatted_text) <= normal_limit fits_normal_limit = len(formatted_text) <= normal_limit
if valid_media and file_ids and not fits_normal_limit: # Videos embedded as a <video> block in sendRichMessage (Bot API 10.1, a few
# months old at time of writing) reliably black-screen on Telegram mobile in
# fullscreen - confirmed against the actual failing post: the same file plays
# fine via the standard send_video call, so this isn't a problem with our
# encoding, it's the mobile client's rich-message video renderer. Route videos
# through the standard path unconditionally until that's fixed upstream.
has_video = any(m.media_type == "video" for m in valid_media)
if valid_media and file_ids and not fits_normal_limit and not has_video:
rich_msg = self.build_rich_message(formatted_text, valid_media, file_ids) rich_msg = self.build_rich_message(formatted_text, valid_media, file_ids)
if rich_msg: if rich_msg:
try: try: