Starting My TV Player automatically when Windows boots
There is no toggle for this in the app. There is a good way to do it in Windows, and one detail about packaged apps that makes the obvious method fail.
The app has no run-at-startup switch. Here is how to do it with Windows' own machinery, and the one wrinkle that makes the method most people try first fail.
Why the obvious method fails
The app is an MSIX package. Packaged apps do not have a stable executable path you can point a shortcut at, so browsing to a folder in Program Files and making a shortcut to the binary either finds nothing or produces a shortcut that breaks on the next update.
What you point at instead is the app's entry in the apps folder.
Before writing this I checked whether the package declares a startup task of its own, which would have put a toggle in Settings, Apps, Startup without any of the steps below. It does not. The desktop packaging manifest is 67 lines and declares no extensions at all, and I checked all 3 manifests in the client tree to be sure I was not looking in the wrong place.
The startup folder, or a scheduled task with a delay
Press Win+R, type shell:appsfolder and press Enter. This opens a view of every installed application, packaged ones included.
Find My TV Player, right-click it, and choose Create shortcut. Windows will say it cannot create one there and offer to put it on the desktop. Accept.
Now press Win+R again, type shell:startup, and move the shortcut into the folder that opens. That folder runs at every sign-in for your user account.
Win+R shell:appsfolder -> right-click the app -> Create shortcut -> Yes (desktop)
Win+R shell:startup -> move the shortcut in here
That is the whole thing. It now appears in Settings, Apps, Startup, where you can turn it off again without deleting anything.
The Task Scheduler alternative is worth it for one case: you want a delay. On a machine that also mounts network storage or waits for a wireless connection, starting the app 30 seconds after sign-in avoids launching into a network that is not ready yet.
Create a Basic Task, trigger At log on, and add a delay. For the action, run explorer.exe with the apps-folder path to the application as its argument, the same indirection the shortcut uses.
There is no switch to start minimised and none to open a specific channel. The desktop head parses no command-line arguments of its own, so anything you read suggesting otherwise is about a different application.
What you will see
The profile picker. Every time.
It does not auto-advance, even with one profile, and even though skipping it was the obvious way to hit a faster startup target. It was rejected permanently because choosing a profile is a security boundary, and a boundary crossed automatically is not one. If your household uses parental controls, that screen is what enforces them.
For reference on what "quick" means: warm launch to Home was measured at about 4.6 seconds, down from 11.6, and picking a profile to reaching Home was roughly halved to about 1.2 seconds.
Whether you should
One argument against, and it is a real one.
We profiled a 12 minute browse session and it ended at 918 MB of working set, having peaked at 1,080 MB. Over 3 identical cycles the managed heap stayed flat at 61.1, 62.6 and 62.5 MB, so the growth is native memory and it does not come back while the app is running.
An app that starts with Windows and stays open all day on an 8 GB machine is holding memory you may want back. On a dedicated box under a television, start it at boot and never think about it. On a work laptop, a pinned taskbar icon is the better answer until that number comes down.
If the machine is under a television, building a small home theatre PC covers what to buy for it, and connecting a laptop over HDMI covers the cheaper version.
What this article measured21 claims, each with the evidence behind it
| Claim | Evidence | Counted |
|---|---|---|
| The app ships no run-at-startup setting. There is no startup task declared and no such toggle in settings, so this is done with Windows' own mechanisms. | n = 1 | Aug 31, 2026 |
| The Store and sideload builds are both MSIX packages, which is why they are launched through the apps folder rather than by a path to an executable. | n = 1 | Aug 31, 2026 |
| The desktop head parses no command-line arguments of its own, so there is no documented switch to start minimised or to open a particular channel. | n = 1 | Aug 31, 2026 |
| An automatic launch still stops at the profile picker. It never auto-advances, and that shortcut was rejected permanently rather than deferred. | n = 1 | Aug 31, 2026 |
| Warm launch to Home was measured at about 4.6 seconds, down from 11.6, with picking a profile to reaching Home roughly halved to about 1.2 seconds. | n = 1 | Aug 31, 2026 |
| The desktop packaging manifest is 67 lines and declares no extensions block at all, which is what rules out both a startup task and protocol activation in one check. | n = 1 | Sep 1, 2026 |
| Three packaging manifests exist in the client tree, one per head plus the console's newer packaging target, so the absence of a startup extension is specific to the desktop package rather than an artefact of looking in the wrong place. | n = 3 | Sep 1, 2026 |
| The package carries its own runtime, so a startup entry cannot fail because a framework has not finished installing. | n = 1 | Sep 1, 2026 |
| For the packaged channel the update check runs on launch at an interval baked in at build time, so starting the app at sign-in is also when it looks for a new version. | n = 1 | Sep 1, 2026 |
| The picker is not skipped even for a household with one profile, and the shortcut that would have made an automatic launch land straight on Home was rejected permanently rather than deferred. | n = 1 | Sep 1, 2026 |
| That picker is what the household gates hang off: kid profiles carry bedtime and daily limits, and the gates fail closed against a persisted snapshot when the profile cannot be fetched. | n = 1 | Sep 1, 2026 |
| Across three identical browse cycles the retained managed heap stayed flat at 61.1, 62.6 and 62.5 MB while the working set climbed 827 to 918 MB, so the cost of leaving it open is outside the collector's reach. | n = 3 | Aug 30, 2026 |
| The same run found the interface stayed responsive throughout: the UI thread never blocked longer than 392 milliseconds and never stopped pumping messages. | n = 1 | Aug 30, 2026 |
| The sleep timer is deliberately session state that is never persisted, precisely so it cannot survive a restart and stop a stream nobody armed, which matters for a machine that starts itself. | n = 1 | Sep 1, 2026 |
| The floating-window entry path carries a generation counter specifically so an in-flight entry cannot re-open the window behind an authentication gate, which is the kind of race an automatic launch makes more likely. | n = 1 | Sep 1, 2026 |
| There are two install channels, and only one of them is the store, which matters if you are scripting a machine: the packaged channel is served from our own domain with its own update document. | n = 2 | Sep 1, 2026 |
| A first launch after adding a large source is slower than every launch after it because parsing and indexing happen on the device, not on a server. | n = 1 | Sep 1, 2026 |
| The same session peaked at 1,080 MB against a documented internal budget of 400 MB, so an app left running all day is holding roughly two and a half times what it is meant to. | n = 1 | Aug 30, 2026 |
| The desktop entry point takes the platform's launch arguments and parses nothing of its own, so there is no documented switch to start minimised or open a particular channel. | n = 1 | Sep 1, 2026 |
| Startup improvements came from named pieces of work rather than tuning: catalog indexes, a remap fingerprint skip, a picker-dwell prewarm, a startup projection database and a lazy recordings graph. | n = 5 | Sep 1, 2026 |
| Leaving the app running is not free: a 12 minute browse session ended at 918 MB of working set and peaked at 1,080 MB, and the growth is native memory that does not return within a session. | n = 3 | Aug 30, 2026 |