Settings, workers and timeouts

Two settings on this screen matter and the rest are for slow machines. The two are the LDPlayer path and the worker count — and the worker count is the single biggest lever on whether your fleet is stable.

LDPlayer

The folder your LDPlayer install lives in — the one containing ldconsole.exe, typically C:\LDPlayer\LDPlayer9 or C:\LDPlayer\LDPlayer14. In the desktop app you can browse for it rather than typing it.

Both LDPlayer 9 and 14 are supported; the app works out which you have from the path.

Everything the bot does to an emulator goes through LDPlayer's own tooling rather than by clicking on your desktop, so emulator windows don't need to be visible or focused, and you can keep using the machine while the bot runs.

The worker count

How many accounts run at the same time — not how many accounts you can have. You can keep as many accounts and instances as your disk holds; this decides how many are awake at once.

There is no correct number anybody can give you. It depends on your CPU, RAM, disk speed and whatever else the machine is doing. Find it by testing: start low, watch a full cycle finish, raise it a step, watch again. When boots start timing out or cycles get noticeably slower, you've gone one step past your limit — come back down.

Every concurrent account is a full Android virtual machine. The usual failure mode for a new setup is running more at once than the PC can actually boot. Fewer accounts that finish reliably beats more that thrash.

If you use account tabs, this total is what the tabs divide between them.

Fast Boot and Parallel Boot are the two switches beside the number.

Advanced timeouts

| Setting | What it bounds | Default | |---|---|---| | Start Instance Timeout | Waiting for LDPlayer to bring an instance up | 120 s | | Android Booting Timeout | Waiting for Android inside it to finish booting | 120 s | | Game Process Timeout | Waiting for the game to start after launch | 90 s | | Game Ready Timeout | Waiting for the game to reach a usable screen | 240 s | | Booting Delay | A pause built into the boot sequence | 2 s | | Max Recovery Retries | Recoveries allowed before an account is parked | 3 tries |

All of these apply on the next bot start, not immediately. Save Settings writes them; a run already going keeps the values it started with.

Raise them if a slow machine is being cut off mid-boot. Raising them does not make anything faster — it only stops the bot giving up on something that was going to work anyway.

Troubleshooting

Instances keep timing out. Lower the worker count first — that's the common cause by a wide margin. Only if a single instance times out with nothing else running is it worth raising the timeouts.

I raised the timeouts and nothing improved. Then the timeouts weren't the problem. A machine that can't boot an instance in the default budget is usually short of RAM or running too many at once.

No instances show on the Accounts screen. The LDPlayer path is wrong, or LDPlayer has moved. Update it here.

I changed the worker count mid-run. Saved, and applied at the next Start. The running session keeps the split it began with.

I use tabs and lowered the total. Main keeps one worker, the tabs are served left to right, and the last ones get fewer than they asked for. The tab strip shows the squeeze in red.