Viren070/AIOStreams
1
0
Fork 0
mirror of https://github.com/Viren070/AIOStreams.git synced 2025-12-01 23:14:04 +01:00
Code Issues Packages Projects Releases Wiki Activity
Page: Migrate to V2
Pages
API Documentation Configuration Custom Formatter Deployment Development Groups Home Migrate to V2 Stream Expression Language Templates Usenet
Clone
5
Migrate to V2
Viren070 edited this page 2025-06-16 14:47:40 +01:00
Unescape Escape
Table of Contents
This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

Migrating AIOStreams from v1 to v2

Welcome to AIOStreams v2! This guide will walk you through transitioning your existing v1 setup to the new and significantly improved v2. Due to major architectural changes, including a new database system for managing configurations, some manual steps are necessary.

🚨 IMPORTANT PRELIMINARY NOTES:

  • Backup Your Sanity (Take Notes!): v1 configurations are not directly importable into v2's database. If you have a complex v1 setup, please take screenshots or detailed notes of:
    • Your configured addons.
    • Filter priorities and settings.
    • Any custom formatters or other specific configurations. This will be invaluable for recreating your setup in the v2 UI.
  • Embrace the Fresh Start: v2 is a complete rewrite. This is a perfect opportunity to build a fresh, more powerful, and streamlined configuration.
  • Cloudflare Worker Discontinuation: As highlighted in the v2 announcement, direct Cloudflare Worker support has been dropped. If you were using this deployment method, you'll need to switch to a Docker-based deployment (self-hosted or via a managed service like ElfHosted).

Key Migration Areas

The migration process will focus on these main areas:

  1. Deployment Configuration Updates
  2. Environment Variable Updates
  3. Custom Formatter Syntax Revisions

Let's break each one down.

1. Deployment Configuration Updates

AIOStreams v2 introduces critical changes to how it's deployed and managed, primarily because it now relies on a persistent database to store your configurations.

👉 Action Required: Update your deployment configuration.

Two key things have changed:

  1. YOU NEED TO ADD A VOLUME MOUNT. AIOStreams v2 requires a persistent volume to store its database (e.g., db.sqlite if using SQLite) and other configuration data. Without this, your configurations will be lost when the AIOStreams instance restarts. The default volume within the container that needs to be mounted is /app/data
  2. The previous v1 health check endpoint (/health) is no longer valid. Using the old health check will cause your container or service to report as unhealthy.

If you are using Docker (e.g., with Docker Compose):

This is how you would typically adjust your compose.yaml.

V1 compose.yaml (Example):

Your v1 compose.yaml might have looked something like this:

# Example v1 compose.yaml (Illustrative)
services:
  aiostreams:
    image: ghcr.io/viren070/aiostreams:latest # Or specific v1 tag
    container_name: aiostreams
    restart: unless-stopped
    ports:
      - "3000:3000"
    env_file:
      - .env
    healthcheck:
      test: wget -qO- http://localhost:3000/health # V1 health check
      interval: 1m
      timeout: 10s
      retries: 5
      start_period: 10s
    # No persistent volume was typically required for core config in v1

V2 compose.yaml (Example with necessary changes):

Your new v2 compose.yaml should be updated as follows:

# Example v2 compose.yaml
services:
  aiostreams:
    image: ghcr.io/viren070/aiostreams:latest # Ensure this points to a v2 compatible tag
    container_name: aiostreams
    restart: unless-stopped
    ports:
      - "3000:3000" # Or your preferred host port
    env_file:
      - .env # Ensure your .env file is updated per Section 2
    volumes: # <<< THIS IS THE CRUCIAL VOLUME MOUNT
      - ./data:/app/data # Mounts a local './data' directory to '/app/data' inside the container
# Health check is now built-in. Remove your old healthcheck or update if customizing.
# The default internal healthcheck is robust. If you must override, use:
#    healthcheck:
#      test: wget -qO- http://localhost:3000/api/v1/status # New v2 health/status endpoint
#      interval: 1m
#      timeout: 10s
#      retries: 5
#      start_period: 10s

Key Changes & What To Do (Illustrated by Docker Compose example):

  • Image Tag:
    • Ensure your image source (e.g., ghcr.io/viren070/aiostreams:latest) points to a v2-compatible version.
  • Volume Mount (ESSENTIAL):
    • In the Docker Compose example, the line - ./data:/app/data maps a directory named data (created in the same location as your compose.yaml on your host machine) to the /app/data directory inside the AIOStreams container.
    • This /app/data internal directory is where AIOStreams v2 expects to store its SQLite database (db.sqlite) and other persistent data.
    • Action: Regardless of your deployment method (Docker, Kubernetes, etc.), you MUST configure a persistent volume that maps to the container's /app/data directory (or the path specified by the DATABASE_URI if you change it for SQLite). Ensure the AIOStreams process has write permissions to this volume.
  • Health Check Endpoint:
    • The v1 health check endpoint (/health) is no longer valid.
    • Action:
      • Recommended: If your deployment system uses health checks, remove any configuration pointing to the old /health endpoint. AIOStreams v2 includes a more robust health check built into the Docker image itself, which many orchestrators can use by default.
      • Alternative (if you must customize or your system requires an explicit endpoint): Update any health check configurations to use the new v2 status endpoint: http://<your-aiostreams-host>:<port>/api/v1/status.
  • Environment Variables:
    • These have changed significantly and are covered in the next section.

General Migration Steps for Deployment Configuration:

  1. Stop your v1 AIOStreams instance.
  2. Modify your deployment configuration (e.g., compose.yaml, Kubernetes deployment files, systemd service files, etc.) to:
    • ADD THE REQUIRED PERSISTENT VOLUME MOUNT targeting /app/data inside the container.
    • Remove or update any health check configurations.
  3. Ensure your environment variables are updated as per Section 2 below.
  4. Deploy/start your v2 AIOStreams instance using the new configuration and image.

2. Environment Variable Updates

Many environment variables have been renamed, removed, or have new behaviors in v2.

👉 Action Required: Carefully review and update your environment variable configurations.

Here’s a summary of notable changes:

  • SECRET_KEY

    • Change: Stricter requirements and is now required.
    • Behavior: Previously, 32-character keys of any kind were allowed for backward compatibility. V2 now requires a 64-character hexadecimal key.
    • Action: If you had a custom SECRET_KEY, generate a new 64-character hex key. If this variable is not set correctly, AIOStreams will fail to start.

  • ADDON_PASSWORD (Formerly API_KEY)

    • Change: Renamed.
    • Action: Update API_KEY to ADDON_PASSWORD in your .env file or environment configuration. This password protects your AIOStreams instance.

  • CUSTOM_HTML (Formerly BRANDING)

    • Change: Previously a build-time variable, CUSTOM_HTML is now a runtime variable.
    • Action: You can now set this via your .env file. Any HTML provided will be displayed at the top of the "About" menu in the AIOStreams configuration page.

  • DETERMINISTIC_ADDON_ID

    • Change: Removed.
    • Behavior: The v2 behavior of adjusting the addon ID for different configurations (to ensure uniqueness in Stremio) can no longer be disabled. This is now standard.

  • DATABASE_URI

    • Change: New variable.
    • Behavior: Controls the database connection.
    • Default: sqlite:///app/data/db.sqlite (maps to the db.sqlite file inside your data volume mount).
    • Action:
      • For standard SQLite usage with Docker, the default is usually fine if your volume is ./data:/app/data.
      • If you change the path here (e.g., to sqlite:///app/mydata/mydb.sqlite), ensure your volumes in compose.yaml maps to the correct host directory (e.g., - ./mydata_on_host:/app/mydata).
      • If using an external database like PostgreSQL, update this URI accordingly and you won't need the Docker volume mount for the database itself.

  • LOG_LEVEL

    • Change: Expanded log levels.
    • V1 Levels: error, warn, info, debug.
    • V2 Levels: error, warn, info, http, verbose, debug, silly.
    • Action: Update to one of the new v2 levels if you have this set. info is a good default.

  • SHOW_DIE

    • Change: Removed.
    • Behavior: Results will no longer show a game die emoji.

  • ALIASED_CONFIGURATIONS (Formerly CUSTOM_CONFIGS)

    • Change: Format and endpoint structure.
    • V1 Behavior: Accepted a JSON string of {"aliasName": "configString"}. Accessed at /aliasName/manifest.json.
    • V2 Behavior: Accepts a comma-separated list of aliasName:uuid:encryptedPassword triplets. Accessed at /stremio/u/aliasName/manifest.json.
    • Action: This is a more advanced feature. If you used CUSTOM_CONFIGS, you'll need to adapt to the new format and understand how UUIDs and encrypted passwords for configurations are handled in v2.

  • Proxy Environment Variables (e.g., DEFAULT_MEDIAFLOW_URL, DEFAULT_STREMTHRU_URL, etc.)

    • Change: These specific v1 variables have been removed.
    • New Variables: V2 introduces a more generic set of proxy variables:
      • DEFAULT_PROXY_URL
      • DEFAULT_PROXY_CREDENTIALS
      • DEFAULT_PROXY_PUBLIC_IP
      • FORCE_PROXY_URL
      • FORCE_PROXY_CREDENTIALS
      • FORCE_PROXY_PUBLIC_IP
    • Action: If you were using the v1 MediaFlow or StremThru default proxy settings, migrate your settings to the new DEFAULT_PROXY_... or FORCE_PROXY_... variables as appropriate. Consult v2 documentation for the exact behavior of these new proxy variables.

General Steps for Environment Variables:

  1. Carefully review your v1 .env file or environment configuration.
  2. Compare against the changes listed above and the complete v2 environment variable documentation.
  3. Update your .env file or the environment: section in your compose.yaml for v2.

3. Custom Formatter Syntax Revisions

If you used custom stream title formatting in v1, some variable names available in the formatter templates have changed.

👉 Action Required: Update your custom formatter strings in the AIOStreams v2 UI.

Key changes to formatter variables:

  • {provider.cached} is now {service.cached}.
    • The provider object/variable has been renamed to service.
  • {stream.personal} is now {stream.library}.
    • The personal attribute (indicating if an item is in the user's Debrid library/cloud) has been renamed to library.
  • Conditional display for P2P streams based on infoHash:
    • In v1, you might have checked for the existence of {stream.infoHash} to identify P2P streams.
    • In v2, {stream.infoHash} may now have a value even for non-P2P streams (e.g., if derived from a URL).
    • New Method: Use {stream.type}. For P2P streams, {stream.type} will be equal to 'p2p'.
      • Example conditional logic: {stream.type::=p2p["[P2P]"||""]}

Migration Steps for Custom Formatters:

  1. Note down your v1 custom formatter strings.
  2. Once AIOStreams v2 is running, go to its configuration UI.
  3. Find the section for custom stream title formatting.
  4. Recreate your formatters using the updated v2 variable names and logic (e.g., replacing provider with service).

This migration involves several steps, but the enhanced capabilities and stability of AIOStreams v2 are designed to significantly improve your experience. If you encounter issues not covered here, please consult the main AIOStreams v2 documentation or seek assistance in the AIOStreams Discord Server.