# Senior C#/.NET Developer Needed, Production-Grade Multi-LDPlayer Automation Control Center

## Project Description I'm seeking an experienced C#/.NET Windows desktop developer to build a professional, production-grade automation control center for authorized account-recovery/testing workflows. This is not a simple script project. I need a maintainable, scalable, secure Windows application with proper architecture, testing, diagnostics, persistent task management, and a professional dashboard. The application must be capable of coordinating 1–10 LDPlayer instances, with the exact number selected dynamically from the dashboard. ## 1. Dynamic LDPlayer Selection & Startup The dashboard must allow the operator to select the exact number of LDPlayer instances to run. Example: LDPlayer Instances: [ 5 ▼ ] Supported range: 1–10 After clicking START, the application must: 1. Detect the configured LDPlayer installation. 2. Discover available emulator instances. 3. Launch only the number selected by the operator. 4. Wait until each emulator is fully ready. 5. Verify emulator health. 6. Create one dedicated worker for each active emulator. 7. Begin processing the task queue. The application must never launch more instances than the selected limit. The selected worker count should be configurable without changing source code. ## 2. LDPlayer Management Use appropriate LDPlayer management mechanisms such as ldconsole.exe and ADB, where applicable. Features: - Auto-detect LDPlayer installation - Manual executable-path configuration - Discover emulator instances - Display instance ID/name - Start - Stop - Restart - Health monitoring - Crash detection - Unresponsive-instance detection - Automatic recovery - Per-instance locking - Prevent two workers from controlling the same instance The software must not rely on hard-coded machine-specific paths. ## 3. TXT Task Queue The operator will import a .txt file containing one authorized task/number per line. Example: Task/Number 001 Task/Number 002 Task/Number 003 Task/Number 004 Task/Number 005 Processing pipeline: Import → Validate → Normalize → Deduplicate → Persistent Queue → Worker Assignment The queue must maintain task order while allowing multiple workers to process different queue items concurrently. Each task must have a unique internal ID. The same task must never be assigned to two workers simultaneously. Dashboard statistics: - Total - Valid - Invalid - Duplicate - Pending - Running - Completed - Failed - Retry - Manual Action Required Persist all task states using SQLite. If the application crashes or closes unexpectedly, unfinished tasks must be recoverable after restart without duplicate execution. ## 4. Multi-Worker Engine Implement a proper bounded worker-pool architecture. Example: Worker 01 → LDPlayer 01 Worker 02 → LDPlayer 02 Worker 03 → LDPlayer 03 ... Worker 10 → LDPlayer 10 Requirements: - Thread-safe queue - Configurable concurrency - Per-instance locking - No duplicate task assignment - Pause/resume - Cancellation - Graceful shutdown - Worker health monitoring - Automatic worker recovery - Persistent worker/task state One failed emulator or worker must never crash the entire application. ## 5. Browser-Based Workflow Inside each assigned LDPlayer instance: 1. Wait for Android readiness. 2. Verify the configured browser exists. 3. Launch the browser. 4. Navigate to the configured authorized account-recovery workflow. 5. Retrieve the next task from the queue. 6. Enter the task data into the appropriate workflow field. 7. Continue through the normal authorized recovery process. 8. Detect the current workflow state. 9. Determine the result/state. 10. Record the result. 11. Release the worker. 12. Automatically obtain the next queued task. The workflow must use reliable UI/state detection rather than depending primarily on fixed coordinates or arbitrary delays. Browser path and configuration must be configurable. ## 6. Workflow Engine Build a reusable state-machine workflow engine. Each workflow step must support: - UI/state detection - Timeout - Retry - Cancellation - Error handling - Screenshot-on-failure - Structured logging - Recovery actions Example: Initialize → Emulator Ready → Browser Ready → Workflow Started → Task Entered → State Detected → Result Detected → Completed Unexpected states must be handled gracefully rather than causing the entire worker to fail. ## 7. CAPTCHA Will let you KNOW on chatbox ## 8. Professional Dashboard Create a polished commercial-style Windows dashboard. Main statistics: TOTAL | RUNNING | PENDING | SUCCESS | FAILED | CAPTCHA | RETRY Each LDPlayer card must display: - Instance ID/name - Worker status - Current task - Current workflow step - Runtime - CPU usage - RAM usage - Retry count - Browser status - Error state - CAPTCHA/manual-action state Dashboard controls: - START - PAUSE ALL - RESUME ALL - STOP ALL - RESTART INSTANCE - RETRY FAILED - IMPORT TXT - EXPORT RESULTS Additional UI: - Dark/light theme - Search - Filtering - Sorting - Live activity feed - Live logs - Charts - Notifications - Responsive layout - Professional error dialogs ## 9. Error Recovery Handle: - LDPlayer crash - Android boot failure - Browser crash - Application crash - Unexpected UI state - UI timeout - Network error - Workflow failure - Worker exception Recovery flow: Detect → Diagnose → Screenshot → Log → Retry → Recover → Continue Configurable: - Maximum retries - Timeout - Retry delay - Backoff strategy - Screenshot-on-error A recoverable failure must not unnecessarily terminate the entire queue. ## 10. Diagnostics For unexpected failures optionally capture: - Screenshot - Task ID - Emulator ID - Worker ID - Workflow step - Error code - Error message - Timestamp - Attempt number Diagnostics must be accessible directly from the dashboard. ## 11. Database Use: SQLite + Entity Framework Core Recommended entities: - Tasks - TaskAttempts - EmulatorInstances - Workers - WorkflowRuns - WorkflowSteps - Errors - Statistics - Settings Database requirements: - Persistent task state - Crash recovery - Transaction-safe task assig