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.
