[FEATURE] Add optional combined MKV torrent/magnet output for multi-version releases

[Zzackllack]

Description

Currently AniBridge delivers separate torrent/magnet links for each available version (language, subtitles, etc.) of a video/series/anime based on what providers like s.to and aniworld.to offer.

As a new feature, we could optionally combine all available versions into a single MKV and provide one consolidated torrent/magnet link instead of multiple MP4 links. This would reduce clutter for users and allow them to get all audio/subtitle tracks in one file (with a custom torrent name as appropriate).

This behavior should be toggleable via a new environment variable.

Motivation

• Multiple versions (e.g., different subtitle tracks) currently result in separate torrent/magnet links, this can be messy.
• Providing a single, enhanced MKV with all tracks included would streamline the experience while preserving all metadata.
• We already support yt-dlp and the underlying downloads; muxing and packaging could be integrated with existing pipelines.

Proposed Implementation

New Feature Flag

• Add an ENV VAR such as COMBINE_VERSIONS_IN_MKV (bool) to enable/disable combined output.

Muxing Logic

• After gathering all versions for a release, generate a combined MKV file that includes:

  • All audio/subtitle tracks
  • Appropriate metadata and naming

• Replace the multiple magnet/torrent links with a single link pointing to the combined MKV.

Dependencies/Tools

• We’d need to support muxing likely FFmpeg or a similar muxer (e.g., mkvmerge via mkvtoolnix) as part of the pipeline for combining tracks into MKV containers. FFmpeg can remux without re-encoding, making this efficient. Arch Linux Foren

Integration

• Integrate muxing steps after download but before generating the torrent/magnet.
• Fallback to existing behavior if the flag is disabled or muxing fails.

Example Reference

There’s already a project that aims to tackle combining versions into a single container for AniWorld Downloads, AniWorld-Downloader_Mux-Tool (linked below). We might be able to adapt some ideas or workflows from it:

• https://github.com/Yezun-hikari/AniWorld-Downloader_Mux-Tool

Technical Considerations

• Compute overhead: Muxing may require additional CPU, so we should make this optional and document performance implications.
• Error handling: Ensure fallbacks if muxing fails or toolchains are missing.
• Torrent naming: Decide a consistent naming scheme for combined torrents (e.g., include all languages/subs in name).

[coderabbitai]

📝 CodeRabbit Plan Mode

Generate an implementation plan and prompts that you can use with your favorite coding agent.

• Create Plan

Examples

• Example 1
• Example 2

---

🔗 Similar Issues

Related Issues

• Add s.to catalogue support alongside AniWorld #6
• [FEATURE] Support megakino as an additional content provider #24
• [FEATURE] Derive real release ages for synthetic torrents #7

👤 Suggested Assignees

• Zzackllack

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[Zzackllack]

One thing we still need to think through is when the remuxing should actually happen in the workflow.

If we start remuxing immediately when Sonarr/Radarr queries us for available torrents, we’d have to block the response until the MKV is fully built. That could introduce long delays and might even cause timeouts on the Sonarr/Radarr side, resulting in nothing being shown or selectable at all.

An alternative approach could be:

• When Sonarr/Radarr requests available releases, we only expose what’s currently available and construct a single torrent/magnet that represents the combined MKV.
• The actual remuxing would then only start once Sonarr/Radarr actually tries to download the torrent via the magnet URL we provided.
• From there, we remux on-demand and serve/seed the final MKV once ready.

Not sure yet which approach is cleaner, but doing heavy compute during the indexer request phase feels pretty risky.