Added user-configurable minimum refresh interval for inventory reloads, allowing users to control how frequently the maintenance service triggers updates (default: 30 minutes, range: 1-1440 minutes).
- Add minimum_refresh_interval_minutes to settings system with default of 30 minutes
- Update maintenance service to use configurable interval instead of hardcoded 1-minute value
- Add GUI input field in General Settings with auto-save functionality
- Include field in API settings endpoint and settings manager
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
This commit introduces a manual mode for channel selection that allows users to lock onto a specific game, along with significant UI/UX improvements:
Manual Mode Features:
- Locks channel selection to a specific game when user manually selects a different game
- Automatically exits manual mode when all drops for the game are completed
- Shows visual indicators (🎯 badge) in status bar and drop display
- Allows manual exit via "Return to Auto Mode" button
- Prioritizes manual game in wanted_games list during auto-selection
UI/UX Improvements:
- Batch update system for channels and campaigns prevents flickering during refresh
- Channels list now updates atomically instead of clearing and re-adding
- Campaign loading emits all campaigns at once for smooth initial load
- Drop progress persists on initial_state load for reconnecting clients
- Game icons (box art) now displayed in channel list
- Campaign links added to inventory items
Bug Fixes:
- Fixed logging level to respect INFO by default (was hardcoded to DEBUG)
- Fixed channel cleanup to not call channel.remove() (handled by batch_update)
- Fixed drop display not persisting during channel switch
- Fixed stop_watching() clearing drop timer prematurely
- Fixed status display typo ("fames_to_watch" → "games_to_watch")
Backend Changes:
- Added manual mode tracking (_manual_target_channel, _manual_target_game)
- Added enter_manual_mode(), exit_manual_mode(), is_manual_mode() methods
- Added get_manual_mode_info() for API serialization
- Added batch_update() to ChannelListManager for atomic updates
- Added start_batch()/finalize_batch() to InventoryManager
- Added /api/mode/exit-manual endpoint
- Game model now stores box_art_url from GraphQL response
- Manual mode info included in /api/status and initial_state
Frontend Changes:
- Added manual mode badge and controls in UI
- Added channels_batch_update and inventory_batch_update socket events
- Added manual_mode_update socket event
- Countdown timer now properly tracked and cleared
- Drop display shows manual mode status with game name
- Exit manual mode button added to drop display area
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
- Comment out push and pull_request triggers
- Keep workflow_dispatch for manual runs only
- Prevents automatic builds on every push
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
- Change "Support the Original Author" section to "Support This Fork"
- Feature buymeacoffee.com/rangermix as primary support link
- Keep acknowledgment of original author with their support links
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
- Fix CI workflow to reference src/version.py instead of version.py
- Update Python import paths for version extraction in AppImage job
- Fix Dockerfile to use requirements.txt and copy src/ directory
- Remove deprecated --web flag from Docker CMD
- Remove obsolete version: '3.8' from docker-compose.yml
- Add Docker build job to CI workflow with multi-arch support (amd64, arm64)
- Push Docker images to GitHub Container Registry (ghcr.io)
- Add OCI image labels with build metadata to Dockerfile
- Update README with pre-built Docker image instructions
- Update funding information
All changes ensure compatibility with the refactored src/ package structure
and enable automated Docker image publishing via GitHub Actions.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
- Add note at top indicating this is a fork of DevilXD/TwitchDropsMiner
- Add disclaimer about AI-assisted development (Claude Code)
- Update git clone URL to rangermix/TwitchDropsMiner
- Add dedicated Acknowledgments section with credits to original author
- Update Support section to encourage supporting original author
- Rename Credits to Translation Credits for clarity
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Replace the legacy desktop/Tkinter client and packaging artifacts with a Docker-first, web-hosted approach.
- Add Docker quickstart and run-from-source instructions to the README to simplify deployment.
- Simplify launcher to invoke the new web backend module instead of the old desktop entrypoint.
- Update dependencies for a web UI stack (FastAPI, Uvicorn, python-socketio, Jinja2, etc.) and remove desktop/tray-specific packages.
- Remove legacy GUI, packaging and platform-specific helper code, along with obsolete build/pack scripts and AppImage assets to declutter the repo.
- Tidy project ignore rules to add runtime logs and editor metadata.
Rationale: streamline deployment, favor a browser-accessible interface, and reduce maintenance overhead from multiple platform-specific GUI/packaging implementations.
Now the target CPU architecture should be set by the 'ARCH' environment
variable before invoking appimage-builder.
This makes it easier to build the AppImage for other CPU architectures.
This environment variable was necessary back then to work around a bug
in the libgtk3 version we include in the AppImage.
However, since commit 3897a8bccf
("ci/linux: build AppImage on Ubuntu 22.04 (Python 3.10)"), that's not
needed anymore, because Ubuntu 22.04 has a newer version of libgtk3,
which fixes the problem.
I made sure to verify the app runs as expected on Wayland sessions of
two major desktop environments:
- GNOME: 42.9 (Ubuntu 22.04.05) and 48.3 (Arch Linux)
- KDE Plasma: 5.27.5 (Debian 12) and 6.4.3 (Arch Linux)
An up to date version of libXft is still needed because Ubuntu 22.04
still has 2.3.4, which can cause the app not to launch if an emoji font
is installed on the host.
Unfortunately, sourcing the Python venv Bash script to activate the
virtual environment doesn't work while we're building the AppImage, so
this just manually invokes Pip from within the venv to install updated
versions of meson and ninja (for building PyGObject next), and then we
prepend the venv's "bin" directory to the 'PATH' environment variable
to make meson and ninja discoverable on the next "pip install" step.
This also removes "certifi" from being manually installed, because
"truststore" has been usable since commit
3897a8bccf ("ci/linux: build AppImage on
Ubuntu 22.04 (Python 3.10)").
appimage-builder is a tool that is not officially part of the AppImage
ecosystem, and lately its maintainer hasn't been able to keep up with
the latest AppImage ideas, most notably:
- The move to a new statically-linked runtime: Before this, all AppImages
using the old runtime, would depend on libfuse2 to be installed on the
host system just to be able to run out of the box. This wasn't much of
a problem back then, because libfuse2 was ubiquitous. However, nowadays,
some have distros don't even have it in their official repositories.
- The removal of the xz compression algorithm (used by default), and the
addition of Zstd.
Luckily, the problems above have been fixed in the git version of
appimage-builder, but a stable release is yet to be made, so we'll have
to use the git version, because other AppImage-making tools are not as
nice and convenient as appimage-builder.
This manually downloads the old AppImage runtime (now marked as
obsolete), to prevent appimage-builder v1.1.0 from failing to make the
AppImage.
The download URL appimage-builder v1.1.0 uses for the AppImage runtime
is hardcoded into the tool, and unfortunately it's been recently
removed, so this is merely a workaround, until hopefully a future
appimage-builder release fixes this.
See: https://redirect.github.com/AppImageCrafters/appimage-builder/issues/375
