Round videos are circles, and media brought in from a Telegram Desktop export works like every other file.
Added
- Round videos are recognised and shown as circles. Telegram's circular video messages were archived as ordinary videos, because neither the scheduled backup nor the live listener ever looked at the flag that marks one. They are now typed
video_note, and the viewer plays them in place as a circle that autoplays while it is on screen, the way every official client does. Click one to toggle its sound. Archives built from a Telegram Desktop export already held round videos under this type and showed them as a grey file row; those are fixed by the same change, with no re-import needed. reclassify-round-videoscorrects archives captured before this release. Round videos already in an archive are still typed as ordinary videos, and roundness is not recoverable from the stored file. The command asks Telegram which messages are round (a server-side filtered search, so a chat with none costs a single request) and corrects those rows in place. Nothing is downloaded, re-keyed or deleted. Run it with the viewer idle: a tab left open holds the old media URLs and will say "Media not found" for a re-typed video until it is reloaded.- One media classifier instead of two. The backup and the listener each carried their own copy of the rules that decide what a piece of media is, which is how round videos ended up unimplemented in both at once. There is now one, and a test fails if it is ever forked again.
Fixed
- A media row is identified by its message, not by a string that spells its type.
Media.idwas minted on every capture from the chat, message and type, so it cached a judgement and was then used as the row's identity. When the judgement changed the backup stopped talking about the row it already had: it inserted a second row, and left the first marked not-downloaded with its retry counter untouched, so that row was re-requested from Telegram on every cycle and could never reach the attempt cap. The id is now an opaque token a row keeps for life, and only the type is corrected. - A corrupted imported file is no longer deleted without a replacement. With
VERIFY_MEDIA=true, verification moved a suspect file aside, asked the backup to fetch a replacement, and got back a record claiming success that had never looked at the disk. It then deleted the file it had moved aside. For media imported from a Telegram Desktop export, which Telegram cannot re-serve, that was the only copy. Reuse is now decided by the file actually being there. - Imported media plays again in the viewer. A file ingested from a Telegram Desktop HTML/JSON export was on disk, marked downloaded, and still showed as "Media not found" in the message list, in the gallery and on the download button. The viewer worked out a file's URL by slicing the chat id off the front of its database key. That fits the key the API sweep writes and not the one the importer writes. It now builds the URL from the message and type the row actually carries, and looks the row up by those columns, so the spelling of the key stops mattering. Two smaller symptoms of the same cause go with it: the gallery's "load more" stopped dead at the first imported item, and imported round videos appeared under no gallery tab at all. Reported by @WalterLederer in #423, with the debug trace and the row dump that made it a short hunt.
VERIFY_MEDIA=trueno longer re-downloads an entire imported archive. The importer stores a file's location relative to the media root. Verification read it as a plain path, which resolved against the working directory instead, so every imported file looked missing and was fetched again. On a 1 TB import that meant a 1 TB download and a doubled disk footprint. The same mismatch made the delete path skip the file while still removing its database row, orphaning bytes nothing ever reclaimed, and it could blank the recorded location of a file that was sitting on disk the whole time. All of these now resolve against the media root, and a path that would climb out of the archive resolves to nothing. (#310)- A media URL no longer carries a chat id back to the browser. A row the viewer could not build a key for kept its raw storage key, which contains the chat id, and the gallery sent it back as a pagination cursor. (#423)
scripts/restore_chat.pyfinds imported attachments. It reported them as missing, because it joined their location to the backup root rather than the media root.
Note
This release rewrites nothing. No database rows change, no files move, no media ids change. An archive already damaged by the re-download bug above keeps its duplicate rows and duplicate files. This stops more being made. The viewer half takes effect as soon as you pull the viewer image, with no backup run needed.
📋 Full changelog: docs/CHANGELOG.md