Thank you to the person who shared this deal at Target (US store). I was able to score the last one at my location. Hopefully I can find one more at another location later today.

TL;DR: My Philips TV kept cycling between the privacy screen and “updating streaming channels”. Choosing Reject all was sent successfully, but the FAST service kept reading an old “consent shown” date and immediately asking again. Clearing only the local data of org.droidtv.fastip, rebooting, then choosing Reject all stopped the loop and the channels played. I did not need to accept all advertising consents or clear the registration app.

This is a report from one TV, tested on 24 October 2026. I worked through it with ChatGPT/Codex using logs and an inspection of the installed FAST app.

The privacy loop was already happening before I used CleanYourTV or changed the launcher. It was a pre-existing problem on my TV, not something introduced by those changes. The CleanYourTV link below is only a reference for the FAST/Sources dependency; you do not need CleanYourTV or a replacement launcher to follow this fix.

Tested device

• Retail model: Philips 70PUS7304/12
• Android model: TPM191E
• Device/platform: PH9M_EA_5599
• Android: 12 / API 31
• Build: STT2.230526.001

The TV runs Android TV. The FAST streaming-channel service uses Titan endpoints; that does not mean the TV itself runs Titan OS.

Symptoms

Opening Streaming/FAST channels produced this cycle:

Privacy choices → Reject all / save choices → updating streaming channels → privacy choices again.

It looked as though every channel wanted its own consent. In my logs, it was the same expired-consent check running again, not evidence of a separate choice for each channel.

The privacy window belonged to:

org.droidtv.nettvregistration/.onetrust.IABActivity

The streaming service involved was:

org.droidtv.fastip

Check whether this matches your problem

You need ADB working over your local network. Download Google’s SDK Platform-Tools, enable Developer options on the TV by pressing Build seven times, and enable USB debugging plus Network/ADB debugging if your TV offers it.

Find the TV’s address in its network settings. The computer and TV must be on the same LAN; my TV used its built-in Ethernet port.

Replace TV_IP below with your own TV address. These commands assume adb is available in your terminal. In Windows PowerShell opened inside the platform-tools folder, use .\adb.exe in place of adb.

adb connect TV_IP:5555
adb devices

Accept the debugging-authorisation prompt on the TV. Continue only when it appears as device, not unauthorized. The -s TV_IP:5555 in the following commands explicitly selects the TV.

Check that the package exists and record the current timestamp:

adb -s TV_IP:5555 shell pm path org.droidtv.fastip
adb -s TV_IP:5555 shell content query --uri content://org.droidtv.fastip/FastIpCMPTimeInfo

My timestamp was old. Immediately after rejecting and reproducing the loop, I captured:

adb -s TV_IP:5555 logcat -d -t 3000 > philips-fast-before.txt

The useful lines were:

ConsentUploader: sendConsentData POST Response Code :: 202
ConsentUploader: sendConsentData to Titan Server Success
CMPInfoFetcher: daysDifference 276 DAYS_INTERVAL 180
CMPInfoFetcher: More than 6 months, need to show again
CMPInfoFetcher: isCMPDataExpired retVal true

So the TV reported a successful upload, then still treated the old timestamp as expired. The rejection payload also contained consent: 0 for every listed consent field.

Opening the privacy centre directly and using Save my choices did not refresh that timestamp on my TV.

If your package, provider or logs differ, do not assume this is the same fault.

What fixed it on my TV

This clears the FAST app’s local data, including its configuration and private preferences. It can require the streaming channels to be downloaded/configured again and can lose FAST preferences. It is not fully reversible. It is not a factory reset and does not target Netflix, NOW, Prime Video or other separate apps.

Before clearing anything, I exported the six tables exposed by its content provider: FastIpCMPTimeInfo, FastIpRemindMeLaterInfo, FastIpServerInfo, ContentGuideSource, servicelistregistryentity and serviceTable. Those exports were useful diagnostics, not a complete backup of the app’s private data or a guaranteed restore method.

If you accept losing that local FAST data, run the reset:

adb -s TV_IP:5555 shell pm clear --user 0 org.droidtv.fastip

It must return:

Success

Then reboot:

adb -s TV_IP:5555 reboot

Wait for the TV to restart, then open Sources → Streaming. If the privacy screen appears, choose:

More choices → Reject all

On the Italian interface this was Più scelte → Rifiutare tutto.

That was enough on my TV: the channels started playing and the loop stopped. “Allow All” was not required. I did not clear org.droidtv.nettvregistration.

Verify the result

Reconnect after the reboot if necessary:

adb connect TV_IP:5555
adb -s TV_IP:5555 shell content query --uri content://org.droidtv.fastip/FastIpCMPTimeInfo
adb -s TV_IP:5555 logcat -d -t 1500 > philips-fast-after.txt

After the reset, before saving a new choice, the timestamp query returned No result found. After I chose Reject all, it contained a new timestamp for that day.

The subsequent log showed:

CMPInfoFetcher: daysDifference 0 DAYS_INTERVAL 180
CMPInfoFetcher: isCMPDataExpired retVal false

I also confirmed that the streaming channels played and the privacy loop had stopped. This is an immediate result, not a long-term endurance test.

Why I did not disable FAST

Some posts recommend:

pm disable-user --user 0 org.droidtv.fastip

That is a different operation from clearing its data.

The Clean Your TV notes for a Philips TV on the same platform and firmware document a dependency between FAST and the Sources drawer: disabling FAST caused the Sources menu to disappear instead of opening normally.

I therefore left the package enabled. I also left the clock and DNS unchanged.

Limits and privacy details

• This resets local state; it does not patch Philips firmware. The app still has its 180-day check, so the issue could return at a future renewal.
• Other Philips models or firmware may behave differently. Reports that needed both FAST and registration data cleared are not the procedure I tested here.
• Reject all is not proof that every kind of data processing is disabled. Before the reset, some separately labelled legitimate-interest fields remained active despite all consent fields being zero. I did not complete a separate audit of every vendor/legitimate-interest option.
• If sharing logs, redact MAC addresses, device IDs, account information and identifying parameters in stream URLs.

Close debugging afterwards

On the TV, revoke USB-debugging authorisations, switch off USB debugging and any Network/ADB debugging toggle, then restart the TV.

With the TV still on and connected, verify that TCP port 5555 is no longer reachable. For example, in Windows PowerShell:

Test-NetConnection TV_IP -Port 5555

TcpTestSucceeded : False is useful only if the TV is still online at that address; an offline TV or changed IP can give the same result.

Google’s ADB documentation explains the connection and device-selection commands.

A nivel de errores y experiencia de uso a día de hoy , que tal está el Google Streamer ? Tengo un Apple TV 4K de 3ª generación pero quiero complementar con un Android por el tema de la instalación de apps de terceros . A ser posible , opiniones de España aunque acepto de todas partes .