Classic vertical flowchart

CM Upload System

A clearer top-to-bottom step flow showing exactly how CM content becomes Telegram-stored files and then gets sent to users later by saved file IDs.

Step-by-step process flow

One box per step, top to bottom, connected clearly so the whole upload and delivery process is easy to follow.

Step

Fetch movie and TV data from CM

The system reads titles, episodes, and raw source links from CM, while keeping auth valid with JWT refresh handling.

CM sourceMovies + TVJWT auth

Movie metadataTitle, year, poster, and source candidates.

Episode metadataShow, season, episode, and source candidates.

Auth refreshRefresh near expiry so imports keep working.

Step

Normalize the content and source links

The importer cleans the data, infers quality when needed, and preserves all fallback links instead of keeping only one source.

NormalizeQuality detectFallback links

Quality inferenceDetect 4K, 1080p, 720p, and other variants from hints.

Fallback preservationKeep alternates for failover and retry logic.

Coded namingPrepare safe storage names like CM_M000321_1080P.

Step

Insert records into the SQLite upload database

The cleaned content becomes structured DB rows. One upload target becomes one queue row, and all source alternatives are linked to it.

SQLiteupload_variantsQueue state

titles / episodesNormalized content entities.

source_linksAll CM fallback links with source details.

upload_variantsMain work queue for upload targets.

Step

Assign queue jobs to the upload workers

Workers on 3 VPSes claim upload jobs. Each VPS uses one premium Telegram account so retries, failures, and FloodWait behavior stay isolated.

3 VPSWorker claimAccount isolation

Main VPSMain worker and source-of-truth DB host.

Worker ADedicated account-specific upload worker.

Worker BSecond account-specific upload worker.

Step

Choose direct upload or processing path

The worker decides whether a file can go straight to Telegram or must be downloaded and processed first for remuxing, probing, or splitting.

Direct streamRemuxSplit large files

Direct pathSafe MP4 under 4GB with no extra work needed.

Processing pathFor MKV cleanup, ffmpeg work, or unstable sources.

Split pathFor 4K or oversized files that exceed Telegram limits.

Step

Upload the finished file into private Telegram storage

The file is stored in private Telegram channels using coded names only. Content is distributed across many channels rather than one big channel.

Private channelsShardsCoded storage

No real titlesStorage channels should not expose public-facing names.

Sharded channelsSpread risk across multiple movie and TV channels.

Multipart supportStore large uploads as ordered parts if needed.

Step

Save the Telegram file mapping into the database

After upload, the system writes back the final Telegram message ID, file ID, part mapping, and channel/account location for later delivery.

telegram_objectsfile_idFinal output

telegram_file_idMain key the bot will use later.

Storage mappingTrack account, channel, and message location.

Part mappingTrack part_no and part_count for split files.

Step

User browses the mini app or website

Users interact with a proper movie service interface instead of the storage channels. They search, browse, and choose what they want.

Mini appWebsiteCatalog UI

SearchFind the right movie or episode fast.

BrowseUse posters, metadata, and filters.

Select qualityPick an available uploaded variant.

Step

API resolves the request to a stored Telegram object

The API finds the selected content row, chooses the correct uploaded variant, and resolves it to the Telegram file object saved earlier.

API lookupVariant resolveDB mapping

Title resolveMap user request to the correct content entry.

Variant resolveChoose the uploaded quality version the user selected.

Object resolveRead stored telegram_file_id rows.

Step

Telegram bot sends the file instantly

The bot sends the movie or episode using the saved Telegram file ID, so no re-download and no re-upload are needed during delivery.

Telegram botInstant sendNo re-upload

Fast deliveryTelegram already knows the file object.

Source independenceCM does not need to still be alive later.

Real product layerThis is the actual user-facing movie service experience.

Database focus

The key idea is simple: queue uploads first, then save the Telegram file IDs for fast later delivery.

Main tables

Table	Purpose
`titles` / `episodes`	Stores normalized CM content metadata
`source_links`	Stores all fallback CM source links
`upload_variants`	Main queue, one row per target upload
`variant_sources`	Maps upload variants to retry-order fallback links
`telegram_objects`	Stores final Telegram file IDs and multipart mapping
`upload_attempts`	Stores retry, failure, remux, split, and success history

Why this matters

Reliable uploads
SQLite queue state keeps workers coordinated and restart-safe.
Source failover
Fallback links prevent one dead source from killing a title.
Fast delivery later
Saved file IDs let the bot send instantly without re-uploading.
Large-file support
Multipart mapping keeps oversized uploads usable.

Deployment layout

The upload system should follow the same reliability model as your Drive pipeline, one premium account per VPS.

VPS	Worker	Telegram account	Role
Main VPS	cm-ember	Ember premium	Main worker, DB host, future dashboard
Worker A	cm-rora	Rora premium	Assigned upload worker
Worker B	cm-lukas	Lukas premium	Assigned upload worker

Public endpoint

This diagram site is hosted at system.dekku.dev.