AIX Player Download

Privacy Policy — AIX Player

Last updated: 10 October 2026

AIX Player is a video player for Windows and macOS, published by Ace Thought Technologies, which operates the AixApps brand. This policy describes what the app does and does not do with information.

The short version: AIX Player has no account, shows no advertising, and does not keep a history of what you watch on our servers. Your library stays on your device. Videos go to the TV or media service you choose when you use those features, not to us (sections 4 and 8). Diagnostics are off until you agree in the consent regions listed below, and on elsewhere until you switch them off in Settings. They include technical information and feature outcomes; on Windows a playback-failure report can also include eight file-header bytes. This page explains the details.

1. There is no AIX Apps account

There is no AIX Apps sign-up or sign-in. We do not ask you to create a profile with your name, email address, phone number or date of birth, and we hold no AIX Apps account for you.

Other companies’ accounts may be involved, and none is ours:

  • Microsoft account — if you buy the optional upgrade on Windows. The purchase happens in the Microsoft Store, under Microsoft’s terms.
  • Apple Account — if you buy or restore the optional upgrade on the Mac. The purchase happens in the Mac App Store, under Apple’s terms.
  • Roku account — if you cast to a Roku. Roku requires our receiver channel to be added from your Roku account, so that step takes place on Roku’s website, under Roku’s terms.
  • Your media-server account — if you connect to Jellyfin, Emby or Plex, as described in section 8.

2. Your videos and your library stay on your device

AIX Player reads video files from folders you choose. To build your library it stores an index on your own device: file names and locations, durations, resolutions, thumbnail images, playlists, favourites, and the position you stopped at in each file.

That index is never uploaded to us. It lives in the app’s local storage. Playing or casting a video does not upload your library to us either. The limited diagnostic information described below is separate from the index. See section 10 for removing local data.

3. Diagnostics are optional, and you are always in control

Whether AIX Player asks before sending diagnostics depends on the country or region set on your device. The same rule applies on Windows and the Mac.

In the app’s consent-first regions — the European Union and wider European Economic Area, the United Kingdom, Switzerland, South Korea, China, Brazil and Russia — the first run asks, once, whether to send diagnostics. No new diagnostic reports are submitted unless you agree. Dismissing the question records a decline.

Everywhere else, diagnostics start enabled after the app records that regional default, so crashes and casting failures can be found and fixed. You can switch them off at any time. If the app cannot determine your region, it asks; it never assumes. A recorded choice is kept for later launches.

In every region the control is the same: Settings → About → Send anonymous diagnostics. The setting is checked before each new report, so switching it off stops new reports without restarting the app. It does not withdraw reports already handed to Microsoft’s exporter: reports queued in memory or saved locally for retry can still be sent, including on a later launch. It also does not erase reports already received.

Windows reads its Country or region setting, with a locale-based fallback if the Windows region APIs fail. The Mac reads its Language & Region setting. The app does not use your network location to make this consent decision.

While diagnostics are on — because you agreed, or because your region starts enabled — the app sends technical reports to Microsoft Azure Application Insights, a service operated by Microsoft. Microsoft’s separate SDK health counters, called Statsbeat, are disabled in these versions of the app.

3.1 What is sent

There are two kinds of report. Both are described here because both are sent.

Crash and error reports — when something goes wrong: the error type, its numeric error code (shown in hexadecimal), its redacted message, the name of the operation that failed, and a technical stack trace naming the app’s code and, where available, source file names and line numbers. If an error wraps an underlying error, the report also includes that underlying error’s type, redacted message and code stack, with limits on their length. The separate underlying-message field is withheld for private media-server errors. These are code locations, not the locations of your videos.

If the player takes too long to shut down, the report also says whether its quit command was accepted, was still pending, was cancelled or was not sent, or gives the type of its failure; whether the source was local or a network stream; and whether hardware decoding was last observed active, inactive or unknown. It records the shutdown wait limit and, once, whether the forced shutdown completed, left the player running until the app exited, failed, or had not settled within a further 30 seconds, and how long that took (up to that limit). A counter that restarts with the app pairs these two reports within the same launch. The later report may not be sent if the app has already exited. These shutdown details include no video path or title.

Usage events — a small set of named events that tell us whether core features work. They are not used for advertising or profiling. They include:

Event What it carries
Graphics hardware detected — Windows Adapter model, generation, video memory, shared memory, whether it is integrated or discrete, and the graphics driver version
Playback failed Failure reason, engine reason code, codec, file extension and whether the source was a network stream; where the file can be checked, whether it was readable and a rough size band. On Windows: up to the first eight bytes as hexadecimal text (magic). On the Mac: only a format label from a fixed list, such as mp4, matroska or unknown (format), with no header bytes
Thumbnail generation failed File extension; requested decoder, attempted decoders, failure stage, attempt count and fallback/result flags; exception type and a short, redacted error line; codec, pixel format, transfer function, Dolby Vision profile, HDR/wide-colour flags and a rough band for the file’s duration. The thumbnail image is not sent
Casting outcomes Casting technology and connection, pairing, start, stop or command outcome; reasons for a refused connection or invalid queue; timeout operation and timeout length; conversion progress and, for a seek wait, the target percentage. No video title or watched-title history is attached
Purchases and restores — Windows and Mac Product identifier, public catalog price where available, purchase/restore outcome and failure category; Store connection/catalog problems and whether the entitlement could be saved or recovered. The Mac also reports entitlement revocation and its outcome. Windows also reports Store-page and review-prompt activity. These events contain no payment-card details, receipt or Store-account identifier
Library maintenance Scan completion, counts, budgets and fallback reasons; stale or duplicate row counts; failed analysis with extension and attempt count; database collection/version, error type and lock status where reported. No library listing is sent
Download, network or saved-sign-in failure Download scheme, address category and failure reason; timed-out network operation; media-server provider and connection error/status; which secret-storage operation could not save a credential and why, without the credential
App startup and other feature outcomes Startup stage, failed operations, and refused folder/address schemes; fixed outcome labels rather than the folder or full address

The file’s duration band is its length, not how long you watched it. Conversion and seek percentages describe an operation that failed; they are not a continuous playback log. Error text can carry information that the redaction rules do not recognise, as section 3.2 explains.

Reports also carry: the event name or code component, app version, Debug/Release build, process and operating-system architecture (including whether the process is emulated), shutdown state, and a random session identifier generated fresh each time the app starts. The exporter adds the report time, technical type/severity, SDK and application metadata, and another per-process instance identifier. These random identifiers group reports within a launch; they are not saved as a permanent user or device ID.

3.2 What is removed, and the limits of that

Error messages, event names and every event-property value pass through automatic redaction before sending. Recognised email addresses and credential patterns are replaced; a property named as a password, token or other secret has its value withheld altogether. Media-server service errors get a fixed message and exception types instead of the original message.

File paths and web addresses are reduced rather than deleted, and we want to be precise about it:

  • A recognised file path becomes its file extension plus a short hash of the file name, or a folder placeholder. The recognised folder structure and readable name are removed. The hash is deterministic and not salted: the same name can be recognised across reports, and someone who guesses a name can compare its hash. This is not a guarantee of anonymity.
  • A web address keeps its scheme and hostname, for example https://example.com/…. Its user information, path, query and fragment are removed; the removed URL path is not replaced with a filename hash. A private or personal hostname can itself identify a person or device.
  • Recognised IPv6 addresses and private/local IPv4 addresses are masked, as are IPv4 addresses with a port or a clear network cue. A bare public-looking IPv4 address can remain. Fields named as software or driver versions skip address masking so that version numbers are not mistaken for addresses.

One limitation worth stating plainly: pattern matching cannot recognise every name, bare filename, unusual path or piece of personal text in an error. Although the Settings switch says “anonymous diagnostics”, the retained hostnames, hashes and unrecognised text mean that we cannot promise every report is anonymous. The Windows file-header field is also actual file content, not a hash.

3.3 What is never sent

Through the app’s diagnostic channel, we do not send:

  • Video pictures, sound, thumbnail images, or a copy of your video file. On Windows there is one limited file-content exception: a playback failure can send the first up to eight bytes, as hexadecimal text. These normally help recognise a file’s format, not a picture or sound; if a non-video file is opened, those bytes can instead be ordinary text. On the Mac, the header is converted locally to a fixed format label and no header bytes are sent.
  • Your library index, playlists or favourites, or a history of which titles you watched and for how long. The failure-related size/duration bands and progress percentages in section 3.1 are separate.
  • Your Store-account identifier, purchase receipt, card number or billing address.
  • An advertising identifier, or a permanent user/device identifier assigned by our diagnostics code. The per-launch identifiers change; the filename hashes and retained text described above can repeat.

The app does not request GPS or precise location for diagnostics. However, the receiving service necessarily sees the public IP address used to connect. Microsoft documents that Application Insights normally uses it to derive city, state/province and country/region, then discards the address and stores 0.0.0.0 in its place. That is Microsoft’s default, not a claim that an IP address is never received or that coarse location is absent. Azure resource settings can change this behavior. Microsoft’s explanation of IP handling.

Your configured country is used locally for the consent decision; it is not a location field added to our reports. Connections to a Store, a TV or your own media server are separate from diagnostics and are described below.

4. Casting stays on your network — with one honest exception

When you cast a local video file to a TV, playback is between your device and the TV you chose. AIX Player can start a temporary web server on your device so the TV can fetch the video directly. On the Mac, it also uses Apple’s native AirPlay service. We do not upload the video to a server we operate or route it through one.

The exception is set-up, not playback. Getting some devices ready can involve their manufacturer:

  • Roku requires our receiver channel, added from your Roku account on Roku’s website.
  • Chromecast devices load their receiver through Google’s infrastructure.
  • AirPlay on the Mac uses Apple’s system services and route picker.
  • Other TVs may ask for a one-time pairing step.

App-managed TV pairing codes or tokens are stored locally and are not sent to us. Your TV and Apple’s system services have their own privacy policies. If the source is an internet stream or a remote media server rather than a local file, that source is also contacted to obtain the video.

5. Where diagnostics are stored, and for how long

Reports are stored in Microsoft Azure Application Insights. Storage location and retention are configured on that service; the app’s diagnostics switch does not change them. Turning diagnostics off stops new reports, but does not delete reports already received or cancel the exporter’s saved retry queue.

6. Purchases

The optional upgrade is sold and processed by the Microsoft Store on Windows and by the Mac App Store on the Mac, under the respective Store’s terms and privacy policy. We never see or receive your card number, billing address or other payment details.

The app asks the Store for products, prices and purchase status, and saves the entitlement information it needs locally so it can recognise your upgrade. On the Mac this uses Apple’s StoreKit, including purchase, restore and transaction updates. When diagnostics are enabled, the product and purchase/restore outcomes listed in section 3.1 are sent to us; the receipt and Store-account identifier are not.

7. No advertising, no third-party tracking

AIX Player contains no advertising in any version, free or paid. It contains no advertising identifiers, social-media trackers, marketing pixels or advertising-attribution products. The diagnostic service in section 3 receives technical reports and feature outcomes, not data for targeted advertising.

We do not sell your information or share it for advertising, and we do not build an advertising profile of you. Sending diagnostics to Microsoft for processing, and connecting to the services you choose, are the data flows described in this policy.

8. Network shares and media servers — new in 3.0.6 — and what is still switched off

Network shares and media servers let you play video stored elsewhere. You choose the computers, servers and accounts involved. Their sign-in details and playback records are not sent to AIX Apps; technical failure reports can be sent when diagnostics are enabled, as described above.

Network shares (SMB). The app can browse shared folders on a computer or NAS and play from them. On Windows, choosing to remember a sign-in saves the credential in Windows Credential Manager; Forget sign-in removes it after you confirm. The app may also save the server address and username locally. On the Mac, the SMB password is held in memory for the connection and open files, not saved to disk or Keychain. Remembering a server saves its address and username, not its password, so a later app session may ask you to sign in again. Authentication goes to the server you select.

Media servers (Jellyfin, Emby, Plex). You sign in to your own server. The sign-in token is saved in the app’s local connection file: on Windows, encrypted for your Windows user account; on the Mac, encrypted using a random key kept in the macOS login Keychain. The Mac does not put each token directly in Keychain. If encryption is unavailable, the app does not save that token in plaintext; you may need to sign in again. Removing a connection removes its saved token, including the app’s recovery copy.

Plex linking contacts plex.tv. The account token obtained during linking is used to find your servers; only the selected server’s token is kept. The app also creates a persistent, random media-server client identifier and sends it to the selected service, including plex.tv during linking. This is separate from the diagnostic session identifiers.

While you play from a media server, the app reports the title’s identifier and your playback progress to that server so it can resume and mark titles watched. The server records that under its own privacy policy, which we do not control. Posters and titles come from the server and are cached on your device. The app also supports browsing compatible DLNA media servers.

Still switched off in the Store releases: linking cloud-storage accounts (OneDrive, Google Drive, Dropbox). That disabled feature does not connect to those services or handle cloud-account credentials. If a future Store version enables it, this page will be updated before that version ships.

9. Children

AIX Player is a general-purpose media player and is not directed at children. We do not ask children to provide personal information or create an account. The diagnostic controls and limitations described above apply to everyone.

10. Your choices

  • Turn diagnostics off or on at any time in Settings → About. Switching off stops new reports; previously queued or saved reports can still be sent.
  • Remove saved sign-ins by removing media-server connections and, on Windows, using Forget sign-in for network shares. A Windows network credential can be shared with other Windows apps.
  • Remove local data as well as the app if you want to erase the library index, thumbnails, playlists, favourites, playback positions and app-managed TV pairing records. Do not assume deleting the Mac app also removes its saved data or its Keychain encryption key. Uninstalling does not erase records already held by Microsoft, Apple, your media servers or other services you used.
  • Ask us anything using the address below.

We have no AIX Apps account to use to look up your reports. If you have sent diagnostics and want them removed, contact us with the approximate date and time and we will do what we reasonably can. We may be unable to identify which were yours; the reports have no AIX Apps account identifier, but the redaction limitations in section 3.2 still apply.

Depending on where you live you may have rights under laws such as the GDPR or the CCPA. We do not sell personal information.

11. Changes to this policy

If this policy changes we will update the date at the top and publish the new version here. If a change materially affects what is collected, we will say so plainly rather than quietly amending the text.

12. Contact

Questions about this policy, or about privacy in AIX Player:

support@aixapps.net

AixApps