GeiserX/Telegram-Archive v9.2.0

on GitHub

Real-time capture is the default, animated and video stickers play, locations show their map picture, and files whose download stopped short are found and fetched again. Migration 039 runs on start and re-types old stickers; it touches nothing else. An install that set neither ENABLE_LISTENER nor SCHEDULE now runs the listener and one full pass a day. Update both images together: the viewer reads a listener heartbeat only the 9.2.0 backup writes. Run telegram-archive check-media once after upgrading. See Upgrading to 9.2.0.

Added

• Locations show their map, as in the Telegram apps. A location, a venue and a live location now show the small map picture Telegram's own servers render for the point, with the pin drawn over the centre and the sender's picture in the pin for a live location. The title, the address or coordinates and the copy button stay under it, and a click still opens OpenStreetMap. The backup asks Telegram for the picture once, when it first stores the location, and again when it reads a live location at a new position, and keeps it as that message's media file (map_<16 hex>.jpg or .png in the chat's media folder), so the viewer serves it from the archive and no map server or other third party ever sees the point. The listener does the same with LISTEN_NEW_MESSAGES_MEDIA=true, so a new location shows its map at once. Pictures follow DOWNLOAD_MEDIA and SKIP_MEDIA_CHAT_IDS. A login without downloads, a location Telegram serves no picture for, and a picture that fails to load show the card as before. A later read of the message no longer resets the stored file of a location row. backfill-details --apply fetches the pictures of locations archived before this release, at most 500 per run, and reports them as saved, not served, with no point and deferred; it reads no message only to defer its picture, never asks again for a picture Telegram did not serve, and never clears a picture's path. No migration runs and no setting is added. See Locations and contacts.
• Animated and video stickers play in the chat. An animated sticker (.tgs) and a video sticker (.webm) loop while they are on screen and stop when you scroll away, as in the Telegram apps, where the viewer showed the text "Animated sticker". Every sticker sits in the same box, at most 200 px wide and 192 px tall. At most four animated stickers play at once, the newest to come into view first. A click, a tap, a hover or Enter plays one that holds still. Under reduced motion they hold their first frame and a click plays one once. The player is lottie-web 5.13.0, vendored and loaded only when the first animated sticker comes near the screen. The viewer serves .tgs files inline as application/x-tgsticker; ?download=1 still downloads them, and a login or share link without downloads still sees the Hidden placeholder. Safari and browsers on iPhone and iPad show the text "Video sticker" instead, since they cannot draw the clear background, and that text downloads the file for a login that may download. Lottie data is cleaned before it plays: an animated sticker cannot load fonts, pictures or scripts, which Telegram never puts in one. See Media.

Changed

• The real-time listener is on by default, and the full pass runs once a day. ENABLE_LISTENER, LISTEN_NEW_MESSAGES_MEDIA and LISTEN_REACTIONS now default to true, so new messages, their media, edits, chat actions and reactions are saved as they happen. LISTEN_DELETIONS stays false. SCHEDULE defaults to 0 3 * * * with the listener on and keeps 0 */6 * * * with it off, where the pass is the only capture; an empty value now uses the default too. The stock compose file leaves SCHEDULE to that default and .env.example no longer sets it. Hourly and other frequent full passes are deprecated with the listener on: they still work, and startup logs a note when SCHEDULE runs more than 4 passes a day. Startup logs one Capture mode: line in place of Real-time listener: ENABLED. The ENABLE_LISTENER enabled and LISTEN_* lines, and the EVENT_WEBHOOK lines, are now logged only by schedule and the standalone listener, the processes that run a listener; the viewer, the one-shot backup and the other commands no longer print them. An install that copied the old .env.example or compose file keeps ENABLE_LISTENER=false and the 6-hour schedule. See Upgrading to 9.2.0 and Schedule and backup tuning.
• A listener that restarts after a disconnect catches up on what it missed. The listener now attaches its handlers before the shared connection is revived, then asks Telegram for the updates it missed, the request the official apps send on every new session. Updates from an outage longer than the Telegram library's own reconnect budget were dropped before, because the library replayed them while no handler was attached. A process restart still replays nothing; the startup backup covers new messages. See Catching up after a disconnect.
• telegram-archive status reports a listener that is not running. With ENABLE_LISTENER on, the command exits 1 and names the account when fewer listeners run than accounts are configured. A running listener now stamps a heartbeat in the database every 30 seconds, and a listener counts as running only while that stamp is under three minutes old, in the command, the viewer's Live line and Archive status alike. Before, a container that was killed, ran out of memory or lost power left the listener marked as running until a clean start cleared it. Archive status names such a listener with "A listener is not running". With a daily pass, the schedule check alone would take about two days to notice a stopped backup. See status.
• The sidebar says Live while the full pass runs. With a listener active the status line under the archive's name reads Live with the start of the last full pass, for example Live · full pass today at 03:00, and stays Live during a full pass; the tooltip says when one is running. Last backup did not finish still shows first for the master login. See Chat list.
• The listener downloads at most 3 media files at once per account. Every live update runs on its own, so a catch-up that replayed an outage started a download for every replayed photo or file together on the one Telegram connection, and they ran into rate limits together. The message is still saved at once; only its file waits for a free slot.
• A backup without a viewer logs one warning for live updates, not one per message. On SQLite the listener pushes each live update to the viewer over HTTP. When the viewer is not running, the first failed push logs a warning and the next ones are logged at debug level until a push succeeds.

Fixed

• A video or audio file whose download stopped early is found, refused and downloaded again. A release from late 2025 stored some short downloads as complete files: an MP4 with no index, which no player opens and the transcription drain failed three times. check-media now counts such a file as cut short (no moov box, or a box that runs past the end, at a size that is a multiple of 128 KiB), a dry run exits 1 on it, and --repair marks it to download again. The backup and the listener refuse a download shorter than the size Telegram declares for a document or a photo, and replace an existing short file only when its bytes are the start of the new download, so every link to it reads the complete file. When they are not, the short file stays and the complete download is kept beside it. A transcription failure about the earlier bytes no longer counts toward the three. The viewer shows a file marked to download again as not downloaded yet instead of missing from the archive disk, without loading its old bytes, and each message's media in /api/chats/{ref}/messages gains downloaded. See A file cut short.
• Video stickers were archived as videos. Telegram lists a video sticker's video details before its sticker details, and the backup stopped at the first. Both the scheduled backup and the listener now archive it as a sticker, the way the Telegram apps decide it. Migration 039 files the video stickers and animated stickers older releases stored as video or document as stickers. See Upgrading to 9.2.
• Files with stickers drawn on them were archived as stickers. A video, GIF or picture someone decorated with stickers carries a mark Telegram names "has stickers", which the backup took for a sticker. It is now archived as the video, GIF or file it is. A row already archived this way is corrected when a backup reads its message again.

📋 Full changelog: docs/CHANGELOG.md