Why Streaming Worked on My Phone but Not the TV: The Phone Was Only the Remote

The episode started on my phone before the television finished loading its error message.

We’re having trouble playing this title right now.

I was in an Amsterdam hotel room, trying to watch the final episode of a series my partner and I had saved for the trip. It was close to midnight. The phone played the opening scene over mobile data without hesitation.

The television stayed black.

I blamed the hotel TV.

I restarted the streaming app, signed out, entered the account code again and selected the episode.

The same error returned.

Then I opened my established VPN on the phone and chose a nearby server. Playback remained smooth.

That seemed to prove the VPN worked.

I tapped the Cast icon.

The television did not appear.

I moved the phone from mobile data to hotel Wi-Fi so both devices would share the same network.

The television appeared.

I tapped it.

The streaming logo opened on the big screen, spun for several seconds and returned to the error page.

The phone still played the episode perfectly.

I had assumed the television was receiving the working stream from my phone.

It was not.

The phone and television were making separate connections

The phone had two advantages the television did not.

It had reliable mobile data.

It also had the VPN already running.

The television was using hotel Wi-Fi directly.

That mattered because casting usually does not mean the phone continuously sends the entire video to the screen. In a Google Cast session, the phone acts mainly as the controller. The receiver on the television retrieves and plays the stream itself. (Google)

My phone was telling the television what to play.

The television still had to reach the streaming service through its own connection.

That explained the contradiction:

The phone’s route worked.

The television’s route did not.

The phone had proved that the account and episode worked on one device. It had not proved that the hotel network could carry the same stream to another.

Once that became clear, restarting the phone app again would only test the device that was already working.

The television was the device that needed fixing.

Finding the TV did not mean the TV could stream

Before the phone could discover the television, both devices needed to be on the same local Wi-Fi network. The phone also needed permission to find nearby devices. (Google)

That was why the Cast icon disappeared while the phone was using mobile data.

Moving the phone onto hotel Wi-Fi restored the television in the device list.

But discovery and playback were separate steps.

The phone could now see the TV and send it a command. The TV still had to open its own connection to the streaming service afterward.

The platform added another complication. Netflix currently limits mobile casting to certain compatible receivers. Many smart TVs and streaming devices with their own remotes are expected to use the television app directly. (Netflix)

The Google TV in the room had its own app and remote.

My phone could help select the episode.

It could not lend the television its mobile-data connection or the VPN tunnel running on the phone.

The two devices looked connected because one controlled the other.

They were still travelling to the streaming service separately.

The television had never joined the protected route

I opened the TV’s network settings.

It was connected to the same hotel Wi-Fi as the phone, but no VPN was active on the television.

The streaming app was therefore leaving through the hotel’s ordinary route.

That route could load menus, thumbnails and profile pages.

It failed when the full video started.

I installed my established VPN provider’s Google TV app. The provider had years of public history, mature apps and a large server network, so trying it first seemed reasonable.

Signing in with the remote took longer than expected.

I mistyped the password twice.

The on-screen keyboard covered part of the verification prompt.

By the time the account opened, the episode on my phone had reached a scene we were deliberately trying not to watch without the TV.

I selected the automatic route.

The VPN connected.

The streaming app opened.

The episode reached 8 percent and stopped.

A Dutch route displayed the first frame, then returned to the home screen.

A German server played for twenty seconds before the picture softened, froze and showed the original error again.

The VPN app reported a successful connection each time.

The television showed that none of those routes could carry the episode.

More server cities became more remote-control work

The established provider’s large location list had been useful on my laptop.

On the hotel television, it became another task performed one letter and arrow press at a time.

Netherlands.

Germany.

Belgium.

Automatic.

Every switch required leaving the streaming app, opening the VPN, waiting for the new connection and returning to the episode.

Meanwhile, the phone kept playing on the first route I had chosen.

That initially made the TV failure look like a general speed problem.

It was more specific than that.

The phone had one stable protected route.

The television had a sequence of protected routes that did not remain usable long enough to play the video.

Other travellers describe the same frustration in a sentence: streaming works on the phone, while the hotel television turns casting into a fight with apps and networks. (Reddit)

That was all the outside confirmation I needed.

The hotel room contained two screens using one account, but they did not share the same internet path.

The working phone could not repair the television merely by acting as its remote.

The smaller app started on the device that needed fixing

I closed the established provider and opened OnlydogVPN on the Google TV.

The smaller app displayed a verification code.

Instead of typing another email address and master password with the remote, I entered that code on my phone.

The television connected.

That solved the first practical problem immediately: the playback device joined the protected route without another round of password entry on an awkward on-screen keyboard.

I selected the situation for streaming on shared hotel Wi-Fi.

Then I reopened the streaming app.

The profile screen appeared.

The episode page loaded.

I pressed Play.

The opening scene began on the television.

The resolution sharpened within seconds.

I placed the phone on the bedside table.

The episode crossed the point where every earlier television route had stopped.

Then it crossed the first scene change.

The first ten minutes played without an error.

We stopped watching the connection icon.

The story finally became more interesting than the network.

Only after the episode stayed open did the route design matter. The smaller service uses an HTTP/3-based, obfuscated connection that gave the television a stable route through the shared hotel network.

I could not inspect the hotel network’s internal filtering rules or the streaming platform’s risk system. The visible result was decisive: the phone had always worked, the established TV routes repeatedly stopped, and the smaller app carried the episode on the screen we actually wanted to watch.

The phone finally behaved like the remote it was

After the television stream settled, I picked up the phone again.

It was still on the same hotel Wi-Fi as the TV.

The television appeared as a controllable device.

I paused the episode from the phone.

The television stopped.

I resumed it.

The picture continued.

This time, the relationship made sense.

The phone was the remote.

The television was the player.

The VPN installed on the television protected the device actually retrieving the video.

That was the setup I had imagined at the beginning, even though I had initially placed the VPN on only one side of it.

The phone did not need to carry the episode for the television.

It needed to discover the TV and send local commands.

The television needed its own working route to the streaming service.

Once each device had the correct job, the two screens stopped contradicting each other.

The hotel Wi-Fi flickered without ending the episode

Near the end of the episode, the hotel Wi-Fi weakened.

The picture paused.

A loading circle appeared.

Then the stream continued from the same moment.

The VPN remained connected, and its HTTP/3-based route recovered without returning us to account verification or another server menu. (IETF)

The interruption lasted only a few seconds.

That smaller success explained why the app remained useful after the initial fix.

Hotel networks are rarely perfectly steady.

Access points become crowded.

The signal changes as devices move between wireless bands.

Temporary network sessions expire and reconnect.

The useful streaming route is not the one that produces the highest result in a quick speed test.

It is the one that recovers before the viewer has to restart the episode.

The established provider had repeatedly made us choose another route.

The smaller app absorbed the interruption and continued.

The working phone had hidden the real diagnosis

When video plays on a phone but not a television, it is tempting to blame the TV’s age, the account or the streaming app.

Any of those may be responsible.

But the phone can also create a misleading comparison.

It may be using mobile data while the television uses hotel Wi-Fi.

It may have an active VPN while the television connects directly.

It may run a newer app.

It may play the episode locally while the Cast receiver opens a separate session.

Even when both devices use the same Wi-Fi, they do not automatically share the same VPN route.

The useful checks are therefore practical:

Which device is actually retrieving the video?

Are the phone and TV on the same local network?

Does the service support casting to that receiver?

Is the VPN installed on the playback device or only on the controller?

Does the episode itself play, rather than merely loading the app menu?

Those questions reach the failure faster than restarting the phone.

The phone is often the only device that does not need help.

The smaller route fixed the screen that mattered

The smaller service has fewer server locations and a shorter public history than the largest VPN providers.

Neither limitation affected the hotel room.

The established provider offered more countries and a familiar account, but its tested television routes repeatedly stalled.

The smaller app paired with the TV through a verification code, opened the stream and recovered when the hotel connection flickered.

Most importantly, it solved the problem on the device responsible for playback.

I began the night believing the phone was sending a working video to a broken television.

The episode finished when I recognised what was actually happening: the phone was only holding the remote, and the television needed a working protected connection of its own.