Three jobs, in order. It authenticates the account, using either a portal login of server address, username and password, or a playlist link that carries credentials inside the URL. It decides entitlements, meaning which channels and titles your account may open and how many streams it may hold at once. Then it delivers, publishing the rolling playlist for each channel and serving the segments your player asks for. Everything the viewer experiences is the visible edge of those three jobs. A login failure is job one, a channel that refuses to open while others work is job two, and a channel that opens then stalls is job three.

1. 1Authenticate the account
2. 2Decide entitlements and connection count
3. 3Publish playlists and serve segments

A playlist link is a static file listing channels and their stream addresses. A portal login is an API relationship, where the app queries the server for live channels, on-demand titles, series and program guide data, and re-queries as things change. In practice the portal route keeps favorites and guide data in step, updates when the catalog moves, and lets the server manage sessions more cleanly. The playlist route is simpler and works anywhere, which is why it survives. Neither changes the video itself. Where they differ for you is maintenance: a portal setup usually needs no attention after activation, while a playlist may need replacing if the address changes.

1. 1Playlist: a static list, simple and portable
2. 2Portal: an API relationship with live catalog and guide data
3. 3Same video path underneath either one

Because groups are usually served together. When one entire group breaks while other groups play normally, the fault is server-side by definition, and nothing on your device will change it: not restarting, not a new app, not a faster internet plan. That single observation is the most useful diagnostic anyone can learn, and it is missing from nearly every troubleshooting guide, which opens instead with restart the app and check your connection. Scope the failure first. One channel means that source, one group means the server, everything means your line, player or session. Then switch away and back, because recovery on return proves the session stalled rather than the bandwidth failing.

1. 1One group down, others fine: server-side
2. 2Restarting the device cannot fix a server fault
3. 3Switch away and back to rule bandwidth in or out

Peak-hour buffering is often oversold capacity, meaning more concurrent viewers than the delivery infrastructure comfortably serves, and no setting on your device touches it. Guides rarely admit this because it moves the blame off the reader. It is worth stating plainly: some buffering is not yours to fix. What you control is which service you pay, and the honest way to compare is by published uptime. We publish 99.99%, which is about 53 minutes of downtime across a whole year, and we would rather be held to that figure than praised in adjectives. Ask any service for the same number, and treat an unwillingness to state one as informative.

1. 1Peak-hour congestion is a capacity problem, not a settings problem
2. 2Ask for a published uptime number
3. 399.99% is roughly 53 minutes a year

At the server, not in the app. Your plan carries between 1 and 5 simultaneous connections, and the server counts open sessions against that number, refusing the next one when the limit is reached. Installs are unrelated and unlimited, so every device in the house can be configured permanently; only concurrent playback is capped. The usual confusion is a device that was left on a channel in another room, which continues to hold a session even with the television off, so close the app rather than only cutting the screen. If a device disconnects badly, a stale session can linger briefly before the server releases it.

1. 1Sessions are counted server-side
2. 2Unlimited installs, capped concurrent streams
3. 3Close the app, not just the television