What an automation script does is simple once you say it plainly: a person does it once, and the script does it a hundred times. Getting a hundred devices to do it at the same time is cluster control’s job. This piece is about batch-publishing to YouTube, one script running many accounts.
Someone makes home-scene videos, eight minutes on average. He moved a script from TikTok over to YouTube batch publishing, and the first run went wrong: twenty devices uploaded at once, the script kept the old habit of “wait ten seconds after tapping publish, then the next step,” and ten seconds later every device was still on the upload progress bar while the script had already moved on. Only three devices in that batch actually published. Ten seconds was nowhere near enough.
Three technical differences between YouTube and short video
There are three differences, and each one changes how the script is written. First, file size. Short video is a few megabytes to a few dozen. A few hundred megabytes is common on YouTube, so upload time moves from seconds to minutes. Second, the number of fields. Short video usually needs a title and some copy. YouTube needs a title, description, tags, visibility, and a playlist, and some items also need a made-for-kids declaration. Each field is another operation. Third, the processing stage. After the file is uploaded, the platform still transcodes. The local progress bar may already be gone while the item is still invisible to the public. For how to run YouTube itself as a matrix, see batch-publishing videos to YouTube.
Hard-code the actions, keep parameters outside, and check after the run
Hard-code the fixed actions and leave no optional gaps: open the app, enter the publish flow, select the file, fill the fields in order, tap publish, confirm success. That sequence is the same for every item. If an action is sometimes needed and sometimes skipped, pull it out as a parameter. Keep it out of the fixed flow.
Parameters are the values that differ per item. At minimum: video file name, title, description, tags, and visibility. If items go into different playlists, the playlist name too. Once parameters live outside the script, the script only handles how to operate, and the parameter table handles what to publish. Changing the content leaves the code alone. One row per device is a good shape for the table, looked up by device alias, and the script reads its own row at start. Ten to twenty accounts on one table is common. Above that, upload bandwidth is the limit. Too many in the same window compete for bandwidth, and the failure rate rises with them.
Titles and descriptions are much longer than short video. Descriptions often include links, timestamps, and hashtags. Write that content into the parameter table ahead of time. The script only pastes. Descriptions are often split into paragraphs, and plain text storage cannot keep the line breaks. A common handling is a fixed symbol in place of the break, which the script swaps back to a newline after pasting. Miss that step and the description collapses into one block. Tags have a count limit, and anything past it gets truncated. Prepare the table to that limit.
Large-file uploads should skip a fixed wait. Too short, and the script moves on before the upload finishes. Too long, and it sits idle for several minutes. Polling fits better: after the upload starts, look at the screen every ten to twenty seconds, see whether the progress bar is still there, or whether the page still shows words like “uploading,” and continue once that is gone. Leave the timeout at fifteen minutes per video, and widen it for especially large files. After a timeout, write the device into the failure list first. Skip an immediate retry. Twenty devices uploading at once will compete for bandwidth. Split them into two or three batches, with ten-plus minutes between batches.
After the run, look at the log first, then the accounts. In the log, look at three places: whether the task started at the set time, whether each step returned a normal value, and whether the upload-complete step actually ran. The first two find which step it stuck on. The third finds a log that says complete while the video is still private. If the log says everything finished and the account shows nothing, transcoding is usually still going, or the platform is still processing. Look again after half an hour.
One more class only shows up in spot checks: the script thought the upload was done, the screen was still on the processing stage, the log says success, and the item is unpublished. Opening three channels a day is enough.
A rerun only covers the devices that failed. Pick the failed devices out of the log, create a separate task, and limit the device scope to those few. Delete the temporary task when it finishes. If the same device fails repeatedly, pull it out of that day’s batch first and check the network exit and the device state. A mismatch between devices and accounts makes this problem larger. For how to organize that, see how to build an ios phone matrix. If one of twenty is broken, finish the work of the other nineteen first. Central control groups can circle only the failed group and run again. If the script kept no execution log, there is nothing to build a failure list from.
About EasyClick: A mobile automation script development platform covering three phone ecosystems: Android without root, iOS without jailbreak, and HarmonyOS. It also offers Apple script writing, Apple cluster control, Android cluster control, remote cloud control, and AI phone cluster control. → Explore all products
Ready to build it for real?
Every approach in this article can be built with EasyClick capabilities on iEasyClick — full documentation, developer tools and automation products, free to try.