feat: cinepro manager binary support for windows

[nischaldoescode]

Pull Request

@An0n-01 @AnonNanoo Heyyy this Pull request specifically introduces the idea which i talked about it here:

Github Discussion

Description

Adds the first Windows-focused CinePro Manager setup experience under setup-binary/.

This PR introduces a Flutter-based desktop manager and an Inno Setup installer for Windows. The goal is to let users install and run CinePro without manually cloning the repo, running Git commands, or figuring out local setup steps by themselves.

The manager is designed as a native-feeling Windows control center for installing, updating, configuring, and running CinePro Core and the CinePro UI. The Inno setup installs the manager app itself, creates shortcuts, supports a setup language prompt, and can launch the manager after installation so the manager can start the verified CinePro install flow.

The manager intentionally does not trust raw GitHub source ZIP installs. Core installation is designed around signed manager-ready release assets using an Ed25519 signed manifest, SHA256 verification, staged extraction, and crash recovery.

It May look very messy push, but i couldn't help myself i forgot to initialize .gitignore and Ofc I could have tried the other way around but I couldn't help myself.. I will correct and be careful on future pushes..

As of Now any feedbacks are welcomed.

Type of Change

• 🐛 Bug fix (non-breaking change which fixes an issue)
• 🌟 New feature (non-breaking change which adds functionality)
• 📀 New provider (adding a new streaming source provider)
• 💥 Breaking change (fix or feature that would cause existing functionality to not work as expected)
• 📝 Documentation update
• ♻️ Code refactoring (no functional changes)
• 🎨 Style/formatting changes
• ⚡ Performance improvement
• 🔧 Configuration change

Related Issues

Closes #11

Changes Made

• Added setup-binary/manager, a Flutter Windows desktop manager for CinePro.
• Added setup-binary/installer, an Inno Setup script for packaging the manager as a Windows installer.
• Added the CinePro logo as the manager and installer identity asset.
• Added native Windows window behavior, tray behavior, bounded resizing, app title, and manager icon support.
• Added a responsive manager dashboard with install/update controls, service controls, Redis/Docker controls, environment editing, logs, notices, and uninstall prompts.
• Added install location handling with separate manager app folder and CinePro content folder.
• Added GitHub release lookup for Core manager-ready releases.
• Added GitHub main branch lookup for cinepro-org/ui, since the UI repo currently does not publish releases.
• Added Ed25519 signed manifest verification for Core release manifests.
• Added SHA256 and byte-count verification before using downloaded release assets.
• Added safe ZIP extraction that rejects unsafe paths and extracts into staging before swapping active folders.
• Added state-based crash recovery through state.json.
• Added rollback-aware install/update structure with current, previous, and staging folders.
• Added bundled Node runtime support through the signed release manifest.
• Added .env.example based environment variable editor.
• Added required TMDB_API_KEY validation before starting Core.
• Added Docker detection and managed Redis controls.
• Added process supervision so Core and UI started by the manager are stopped when the manager exits.
• Added detection for services that close outside the manager, with logs and closable toast notices.
• Added dynamic frontend URL detection from frontend process output instead of hardcoding localhost:5173.
• Added manager app update checks from GitHub release assets with required .sha256 verification.
• Added a three-dot manager menu with manager update, changelog, report bug, language, shortcuts, and CinePro Foundation info.
• Added Windows-only keyboard shortcuts and shortcut help.
• Added setup language prompt in Inno Setup using real Inno language files.
• Added post-install setup flow that launches the manager with --setup-install.
• Added helper scripts for generating Ed25519 release keys and signing release manifests.
• Added detailed setup-binary README documentation with development, build, signing, testing, and contribution notes.

Provider Information (if applicable)

Not applicable. This PR does not add or modify a streaming provider.

Provider Details

• Provider Name: Not applicable
• Provider ID: Not applicable
• Base URL: Not applicable
• Content Types Supported:
  • Movies
  • TV Shows

Provider Testing

Not applicable. This PR adds the Windows manager and setup flow, not a provider.

Tested with the following TMDB IDs:

• Movies:
  • TMDB ID: 550 (Fight Club)
  • TMDB ID: _ (Your test movie)
• TV Shows:
  • TMDB ID: 1399/1/1 (Game of Thrones S01E01)
  • TMDB ID: _ (Your test episode)

Test Results:

Not applicable. No provider was added or modified.

Provider Information (if applicable)

Not applicable. No provider was added or modified.

Checklist

General

• My code follows the code style of this project
• I have run npm run format to format my code
• My code builds without errors (npm run build)
• I have tested my changes locally
• I have commented my code, particularly in hard-to-understand areas
• My changes generate no new warnings or errors
• I have read the CONTRIBUTING.md guidelines

Provider Checklist (if adding/modifying a provider)

• Provider extends BaseProvider from @omss/framework
• Provider has a unique id and descriptive name
• Provider declares correct capabilities (movies/tv support)
• Implements getMovieSources() and/or getTVSources() correctly
• All streaming URLs use this.createProxyUrl() for proxying
• Includes proper error handling with diagnostics
• Uses this.console.log() for logging (not console.log())
• Includes appropriate headers via this.HEADERS
• Returns standardized ProviderResult format
• Provider file is in src/providers/ directory
• Provider exports the class properly for auto-discovery
• Tested with multiple TMDB IDs for movies and/or TV shows
• Works correctly with the proxy system
• Handles edge cases (missing content, API errors)

Not applicable. This PR does not add or modify any provider.

Documentation

• I have updated the README.md if necessary
• I have added/updated comments in my code
• I have documented any new environment variables
• I have added examples if introducing new patterns

Testing

How Has This Been Tested?

The Windows manager was tested locally through Flutter analysis, widget tests, Windows release builds, and Inno Setup compilation.

Core npm run build was attempted, but it could not start because the local Windows npm installation is currently broken and points to a missing npm-cli.js file under the user's roaming npm directory. The failure occurred before TypeScript compilation began.

Test Configuration

• Node.js version: v22.14.0
• Operating System: Windows
• Cache type used: memory by default, Redis support tested through manager control logic

Testing Steps

1. Ran Flutter static analysis for the manager.
2. Ran Flutter widget and service tests for the manager.
3. Built the Windows Flutter release executable.
4. Compiled the Inno Setup installer with Inno Setup 7.
5. Verified the generated setup executable exists.
6. Verified manager update logic and frontend URL detection logic through tests.
7. Verified setup-binary remains intact after pulling the latest upstream development branch.

Test Output

flutter analyze
No issues found.

flutter test
All tests passed.

flutter build windows
Built build\windows\x64\runner\Release\cinepro_manager.exe

Inno Setup 7 compile
Successful compile.

Resulting Setup program filename:
setup-binary\installer\output\cinepro-manager-setup-0.1.0.exe

Core build attempt:

npm run build

Error: Cannot find module
'C:\Users\Nischal Sharma\AppData\Roaming\npm\node_modules\npm\bin\npm-cli.js'

Node.js v22.14.0

Screenshots (if applicable)

Not included in this PR body.

The manager UI can be reviewed by running the Flutter Windows application or installing the generated Inno Setup package locally.

Additional Context

This PR is focused on Windows support initially.

The setup binary installs the manager application. The manager then performs the actual CinePro Core/UI installation flow because the manager owns the safety and recovery mechanisms, including:

• Ed25519 manifest signature verification
• SHA256 verification
• Byte-count verification
• Safe ZIP extraction
• Staging and rollback folders
• Crash recovery through state.json
• Structured logs and user-facing error reporting

This separation is intentional.

Inno Setup should not directly download and extract GitHub archives because doing so would bypass the manager's verification, rollback, and recovery model.

The current CinePro Core release workflow still needs to publish manager-ready signed assets before production installs can be completed entirely through the manager.

Expected Release Assets

cinepro-core-windows-x64.zip
cinepro-core-windows-x64.manifest.json
cinepro-core-windows-x64.manifest.sig
node-v24.x-win-x64.zip

The manager currently contains a placeholder Ed25519 public key.

Before production usage, this key must be replaced with the project's real release signing key.

Helper Scripts Added

setup-binary/manager/tool/generate_release_keys.dart
setup-binary/manager/tool/sign_release_manifest.dart

Performance Impact

• No performance impact
• Performance improvement (describe below)
• Potential performance concern (describe below)

Details

No runtime provider or scraping path is modified.

The manager is isolated under setup-binary/ and only affects users who choose to build or run the Windows setup manager.

Breaking Changes

Details

No breaking changes to existing Core functionality are intended.

The manager is an additive feature and does not alter the current installation workflow for existing users.

Dependencies

New Flutter manager dependencies under setup-binary/manager:

• archive
• crypto
• cryptography
• ffi
• file_selector
• flutter
• http
• path
• tray_manager
• win32
• window_manager

No new Core runtime dependency is introduced by this work.

Reviewer Notes

Feedback would be especially valuable on:

• Whether setup-binary/ is an acceptable folder boundary for the Windows manager.
• Whether the installation flow should remain manager-driven after Inno Setup installs the application.
• Whether the signed manifest format is sufficient for the first manager-ready release workflow.
• Whether the Ed25519 signing approach aligns with the project's release process.
• Whether the manager should remain a setup helper or evolve into the official Windows control center.
• Whether Docker and Redis controls belong in the initial release or should be hidden behind an advanced section.
• Whether frontend installation should continue tracking cinepro-org/ui main until signed UI releases exist.

---

For Maintainers

Merge Checklist

• Code review completed
• All CI checks passing
• No merge conflicts
• Provider tested by reviewer (if applicable)
• Documentation updated (if needed)
• Version bump needed? (no)

[An0n-01]

Hey @nischaldoescode this is a really good idea.

However, please note that I won't be merging this PR since the commits are a little messy (pls no .exe in the git) and it does not seem to work for me....

I would be more then happy to create a new repo for the CinePro Ecosystem Manager (would be nice to start/stop/update all cinepro products)🔥. Is that alright with you?

[An0n-01]

Hey @nischaldoescode this is a really good idea.
However, please note that I won't be merging this PR since the commits are a little messy (pls no .exe in the git) and it does not seem to work for me....
I would be more then happy to create a new repo for the CinePro Ecosystem Manager (would be nice to start/stop/update all cinepro products)🔥. Is that alright with you?

@An0n-01 Yoo imma busy now... Can't contribute much. I was free when I started this but im busy now I will catch up on it soon.

ah sad....

Nah we will provide a binary in the main repo's relases

hmm... that does not make sense. the manager might change while the scraping does and the other way around. we should keep a manger separate from the scraping logic.

for dev you can add it in separate repo ofc, this was just to let you know...

okay dockay.

Make sure to implement the signature and the things as I have mentioned above to maintain new update, release for the cinepro core

Got it ?.

Why exactly can we not trust the github generated source.zip? that should be safe. (more safe than supplying node packaged to the end customers...)

Now add all of these in a new repo.

I'll open a repo and add you as maintainer, yes.

In that main repo lemme maintain the releases tab.

no.

It will be okay for anyone who knows flutter to come and contribute for this idea.

yeah that sounds good.

But I want the releases control... I hope that is okay.

You won't get access to the releases control of https://github.com/cinepro-org/core . For the new repo for the manager, you can get it sure.

And do not cuss in this organization.

[An0n-01]

I was saying i need access to the release tab of the other repo you will create not the core release in the core release you can add the release which I will provide in the release of the binary repo.

okay.

And..

no. (and I am worrying a little😂)

[An0n-01]

you should really read https://noslopgrenade.com/ .... i am asking for your personal reason. not claudes💀😭😭😭🙏🙏

[An0n-01]

I disagree on your strategy. You cannot reason to do something "because we don't have it yet" while it is only additional work and also a larger security risk. I will lock this issue and you can write to me about this on telegram.

[nischaldoescode]

you should really read https://noslopgrenade.com/ .... i am asking for your personal reason. not claudes💀😭😭😭🙏🙏

Fuck that, it's really lengthy to explain that's why and im busy too. If not I would have drawn a graph by now to explain which I will to add in the binary repo.

For now just remember, we can't use it what you are saying because we can't really validate the commits although in the same zip file
source.zip we can add manifest and again we will need the signature

So why not just add what manager demands ?...

I saw exactly this kind of design on electron docs and other frameworks as well.

I will explain much about it laterrrr.

[nischaldoescode]

I disagree on your strategy. You cannot reason to do something "because we don't have it yet" while it is only additional work and also a larger security risk. I will lock this issue and you can write to me about this on telegram.

So what do you want then just randomly fetch the zip for new changes c'mon i ain't saying we need to something. It is more committed towards security we are indeed validating the signatures.

I also told in my pr and in the discussion too that I am okay with the feedback in this design but it is what should we go for.

I did my research then only I added the pr.