- Deleted webui.py as it was replaced by vidai/web.py in the multi-process architecture
- Functionality moved to separate web interface process
- Cleaned up legacy monolithic code that is no longer used

- Add vidai/models.py with abstract base classes for different model types
- Support multiple HuggingFace transformers models (vision-language, text-only)
- Auto-detect model types from model names/paths
- Add model type configuration options (--model-type)
- Update worker_analysis.py to use dynamic model loading instead of hardcoded Qwen
- Maintain backward compatibility with existing model configurations

- Updated all requirements files to use nvidia-ml-py instead of deprecated pynvml
- Added fallback import in webui.py to support both packages
- Maintains backward compatibility while using the actively maintained package
- Updated installation instructions in error messages

- Removed start.sh since process startup is handled by vidai.py
- vidai.py now includes proper backend readiness checking
- Simplified deployment by using single Python launcher

- Update start.sh to wait for Unix socket creation before starting workers
- Remove retry logic from workers since startup script ensures backend is ready
- Workers now connect immediately knowing backend socket exists
- Prevents race conditions between backend startup and worker connections

- Separate communication protocols: TCP for web-backend, Unix sockets for backend-workers
- Remove file-based result passing, implement in-memory result storage in backend
- Web interface polls backend via socket for results instead of reading files
- Workers send results back through Unix socket connection to backend
- Maintain persistent connections for efficient bidirectional communication

- Update workers to use proper socket path from config instead of hardcoded paths
- Ensure workers check communication type and use appropriate connection method
- Fix SocketCommunicator to properly handle Unix socket paths
- Revert database default back to 'unix' for proper Unix socket support

- Fix SocketCommunicator initialization to properly handle TCP vs Unix sockets
- Update backend to use configurable communication type from config
- Change default communication type from 'unix' to 'tcp' for better reliability
- Ensure consistent socket handling across all processes

- Refactor monolithic Flask app into separate processes:
  * Web interface process (vidai/web.py)
  * Backend routing process (vidai/backend.py)
  * Analysis worker processes (vidai/worker_analysis.py)
  * Training worker processes (vidai/worker_training.py)

- Add self-contained inter-process communication using TCP sockets
- Implement configuration system for backend selection (CUDA/ROCm)
- Add GPLv3 licensing and copyright notices
- Create comprehensive documentation and build scripts
- Update main launcher to manage all processes

This architecture provides better scalability, allows independent GPU backend selection, and maintains clean separation of concerns.

- Add socket-based inter-process communication
- Implement backend process for request routing
- Create separate web interface process
- Add CUDA/ROCm worker processes for analysis and training
- Add configuration system for backend selection
- Update build scripts for multi-component executables
- Add startup scripts for process orchestration
- Include GPLv3 license and copyright notices
- Add comprehensive documentation and README
- Create CHANGELOG for version tracking

- Move db_type handling to environment variables to avoid circular dependency
- get_db_config() now uses environment variables for database type
- get_config() handles db_type specially to prevent recursion
- Fixes ImportError when running vidai.py

- Create executable launcher script for non-PyInstaller builds
- Automatically detects and uses appropriate virtual environments
- Launches backend, web interface, and workers with correct CUDA/ROCm environments
- Reads configuration to determine backend selection
- Provides process management and cleanup on exit

- Setup script now creates both venv-cuda and venv-rocm by default
- Build script builds both CUDA and ROCm worker versions
- Start script reads configuration to launch appropriate backend workers
- Added pip3 detection and --break-system-packages support
- Windows batch files updated with pip3 detection
- Runtime can switch between CUDA/ROCm implementations based on config

- Remove invalid local version labels from torch requirements
- Use proper pip syntax: torch>=2.0.0 with --index-url for CUDA/ROCm
- Fix pip installation errors for CUDA and ROCm builds

- Add network configuration settings: web_host, web_port, backend_host, backend_web_port, backend_worker_port
- Update web.py to use configurable host and port for Flask app
- Update backend.py to use configurable ports for socket servers
- Update worker processes to use configurable backend worker port
- Add network configuration section to admin panel
- Update command line arguments to accept network settings
- Maintain backward compatibility with default values

- Add MySQL support as alternative to SQLite with full configuration
- Implement database abstraction layer supporting both SQLite and MySQL
- Add database configuration section to admin panel
- Update requirements files with PyMySQL dependency
- Complete multi-process architecture with web, backend, and worker processes
- Add user registration system with email confirmation
- Implement token-based usage system with payment processing
- Add comprehensive documentation and licensing
- Create professional SaaS-style web interface
- Implement REST API for programmatic access
- Add email notification system and payment processors

🎯 RunPod.io Cloud GPU Integration
• Dynamic pod creation and lifecycle management
• On-demand GPU scaling without local hardware costs
• Seamless integration with existing multi-process architecture

🏗️ Core Components Added:
• Dockerfile.runpod - Optimized GPU pod image for RunPod
• create_pod.sh - Automated build and deployment script
• vidai/runpod.py - Complete RunPod API integration module
• Enhanced backend with pod spawning capabilities
• Web interface RunPod configuration section

🔧 Key Features:
• Automatic pod creation for analysis jobs
• Cost optimization with idle pod cleanup (30min timeout)
• Multiple GPU type support (RTX 3090, A4000, A5000, 4090)
• Secure API key management and pod isolation
• Fallback to local processing when pods unavailable

📊 Architecture Enhancements:
• Pod lifecycle: Create → Start → Run → Process → Terminate
• Intelligent routing between local workers and cloud pods
• Real-time pod health monitoring and status tracking
• Persistent pod state management with cache files

🛡️ Production Features:
• Comprehensive error handling and recovery
• Detailed logging and monitoring capabilities
• Security-hardened pod environments
• Resource limits and cost controls

📚 Documentation:
• docs/runpod-integration.md - Complete integration guide
• Updated README.md with RunPod setup instructions
• test_runpod.py - Integration testing and validation
• Inline code documentation and examples

🚀 Benefits:
• Zero idle GPU costs - pay only for actual processing
• Access to latest GPU hardware without maintenance
• Unlimited scaling potential for high-throughput workloads
• Global pod distribution for low-latency processing

This implementation provides a production-ready cloud GPU scaling solution that maintains the system's self-contained architecture while adding powerful on-demand processing capabilities.

- Add detailed system architecture diagrams to README
- Create visual data flow and usage workflow diagrams
- Enhance docs/architecture.md with process and communication diagrams
- Add cluster architecture visualization with load balancing flows
- Include cross-platform deployment diagrams
- Provide visual representation of inter-process communication
- Document cluster communication protocols with ASCII schemas

- Create build.bat, start.bat, setup.bat, and clean.bat equivalents
- Update compatibility module with Windows-specific functions
- Add platform detection and script execution utilities
- Update README with Windows-specific instructions
- Ensure full Windows compatibility without requiring bash

- Implement cluster master/client architecture with token-based authentication
- Add cluster configuration options (host, port, token, client mode)
- Create cluster communication protocol for distributed workload management
- Implement load balancing with configurable process weights
- Add cluster management web interface for monitoring and control
- Support mixed local/remote worker deployment
- Enable/disable processes across cluster nodes
- Update queue manager for distributed job execution
- Add cluster documentation and configuration examples

- Add estimated_tokens and used_tokens fields to processing_queue table
- Implement token estimation based on request type and content
- Track actual token usage during job processing
- Display estimated and used tokens in web interface queue views
- Update dashboard, queue list, and job details to show token information
- Simulate realistic token usage in queue processing

- Add comm_type configuration option (unix/tcp, default unix)
- Command line argument --comm-type for runtime selection
- Web configuration page includes communication type selection
- SocketCommunicator and SocketServer support both Unix and TCP
- Updated all processes to use configured communication type
- Documentation updated to reflect both socket types
- Unix sockets provide better performance for local communication

- Multi-process architecture: web, backend, analysis/training workers
- SQLite database for persistent configuration and system prompts
- Configurable CUDA/ROCm backends with command line override
- TCP socket-based inter-process communication
- Web interface with comprehensive configuration management
- GPLv3 licensing with copyright notices on all files
- Complete documentation: README, architecture docs, changelog
- Build and deployment scripts for different GPU backends
- Git repository setup with .gitignore for build artifacts