Why multiple devices exist in the first place
Three situations cover almost everyone: one person runs two or more storefronts or accounts; a team has someone who shoots and someone who publishes; or there are several phones and one of them is a spare.
Each needs a different pattern. Multiple accounts need device-to-account binding so sessions do not bleed into each other. A divided team needs task ownership so two people do not touch the same batch. A spare device needs to be swappable, so the main phone can go in for repair and work continues immediately.
Decide which one you are before deciding whether devices should be fixed. Mix all three and every batch becomes a fresh planning exercise.
First: one device, one account
This is the foundation of every pattern. If phone A is signed into two accounts and phone B into the same two, a failure tells you nothing about which account or which device caused it.
Fix the mapping: phone A runs account 1 only, phone B runs account 2 only. Every failure then splits cleanly in two — is it this device, or this account?
If you have fewer devices than accounts, fall back to time-slot mapping: phone A runs account 1 in the morning and account 2 in the afternoon, with a gap in between so the session can settle. The rule is one account at a time.
- One device to one account, when you have enough devices
- When you do not, split by time slot and leave slack on both sides of the switch
- Write the mapping into the list, not just into your head
- When someone else takes over, they use the same mapping table
Three patterns, pick one
Split by time: phone A in the morning, phone B in the afternoon. Simplest, and it works when every device can run every account. The downside is queuing when slots get tight.
Split by task: divide the batch into sub-batches and give each device one. Good for high volume because it parallelises. The downside is that a failure sends you hunting for which sub-batch broke, so sub-batches must be named.
Bind by account: one device, one account, no crossing. Hardest to get wrong and easiest to debug; the cost is low utilisation, which wastes capacity when you have many devices and little volume.
Most people end up mixing: bind by account as the base, then split by task within an account when volume is high. As long as the device-to-account layer is fixed, the layers above it can be cut any way you like.
Four checks before you switch devices
Switching devices is the single most failure-prone action, because it changes the session, the connection and the file path at the same time. Run these four checks every time and most "it worked a minute ago" cases disappear.
① Session: is the previous device signed out, or at least out of the foreground, so two devices are not online at once and flagged as abnormal? ② Connection: cable, wireless link and any authorisation prompt — a swapped cable is a common invisible cause. ③ File path: which folder holds the videos on the new device, and do the filenames in the list match exactly? ④ Power and screen: a low battery, a locked screen or an incoming call can all interrupt a run.
These look basic, but more than eight in ten "failed after switching device" cases trace back to one of them. Before studying platform rules, turn these four into a checklist.
Working out which device failed
In a multi-device setup the expensive part is not fixing, it is locating. The same "upload failed" can come from this device's connection, that account's eligibility, or the video itself.
Cross-test to narrow it down: run the same video on another device, under another account. If it succeeds, the problem is this device or this account; if it fails, the problem is the video. One test removes half the possibilities.
That is why the log must have a device column. "Video 12 failed" is useless; "video 12, phone B, account 2, failed at the details step" is not. With those three dimensions, two failures are enough to show a pattern.
A daily routine that works
Start the morning by checking each device: connection, power, session. It takes under three minutes and prevents discovering a dropped device halfway through a batch.
Then start the day's batches from the mapping table, one account on one device at a time, switching only when a run finishes. Do not open three devices on the same batch to save time — that is not parallel processing, that is three variables changing at once.
Before you stop, read the per-video results, pull out the failures, and decide whether to fix them today or tomorrow. If today, retry only those items, never the whole batch.
When to cut the number of devices
More devices is not more speed. Every device needs its connection, session and file sync maintained, and that cost is fixed. Below a certain daily volume, an extra device adds failure points rather than output.
The test: if more than three failures in the last two weeks were caused by switching devices, you have too many. Simplify the mapping to two devices, get it running smoothly, then add more.
The other signal is when you can no longer remember which device ran which batch. That means the device count has outgrown your record-keeping, not your capacity.