It’s too busy at the moment
But that doesnt make sense to the errortext; especially when retry/download again the system asks me if he should overwrite
Offline went fine
I tried to playback the same file with FW 1.1 under the same circumstances as my previous testing with this, but I still experience sluggishness, was something forgotten in the FW update? I can’t get to my adb setup at the moment to verify the settings however…
Turn automatic keystone off and back on.
1 Like
First of all, sorry for not thoroughly reading the release notes in my rush to share the news; this was mentioned in there.
I checked, without doing your suggestion, I got these values:
W:\Android\platform-tools>adb shell getprop vendor.hwc.compose_policy
0
W:\Android\platform-tools>adb shell getprop persist.sys.keystone.display.id
-1
After your suggestion, the vendor.hwc.compose_policy is showing 6. But it’s not persistent, after a reboot it’s back to 0. What’s the thought behind implementing it this way, and is this definitive? To ask the Kodi user to do this after every reboot will grow tiresome, it would be great for heavy Kodi users like myself to be able to save the setting.
it’s supposed to be persistent. If not, looks like the merge got bungled. I’ll have it checked tomorrow. Thanks for reporting.
1 Like
@Philips_Support_P I’m not sure if it’s my idea or changed conditions in my living room, but I can now hear the fan again whereas on 1.0.32 I couldn’t hear it. Were there changes made between these two versions in this regard? It’s not as loud as it used to be in 1.0.29 but I can hear it again in Energy Saver in 1.1.0.
Depending on your reply I’ll run a sound measurement tomorrow, revert to 1.0.32 and measure again, then update to 1.1 again after.
I also found that while airplay mirroring or streaming, I can use the airplay shortcut to go back to my stream if I went to home. But it goes into the airplay receiver settings, and I have to press Back one time to get to the playing content. That should be documented if that works as intended (I can see that going into the settings to tweak something Airplay related might be needed, so no need to fix that, just needs to be documented in the relevant guide.
And may I suggest that in the future we as beta testers always get the latest release that’s going public before the public, so we can actually find stuff like these before they go live, l so they can be fixed, documented, or mitigated in time.
1 Like
@Philips_Support_P, @Philips_Support_2!
BIG PROBLEM!
I was watching internal video source, set a “sleep timer”, PPM correctly shut down while playing, then I woke up some hours later with the PPM on and stuck on the “no input signal” screen. However, the fan was not running and the PPM was crazy hot. AirMote wouldn’t power off the PPM. It was painful to push and hold the power button on the unit it was so hot.
I just did the update to 1.1.0, will monitor to see if symptom recurs, but I’m really worried that this will damage the unit or start a fire…
I got the same error once at first but after many retries, it went successfully. Downloading the update hasn’t went smooth since the start. Something to improve 
@fhteagle That is worrying, was it plugged during that time? In any case, if anything happens, I would assume Philips would be responsible especially if it’s a regression in the firmware.
Yes it was plugged in to the OEM usb-c charger, but no usb-c video or HDMI cable were connected. It literally woke itself up without turning the fan on for zero reason.
@IvoGrijt noted. This was a rushed update with a release date announced already. Ideally we needed 1 more week to iron out the kinks after 1.0.32.
1 Like
No hard feelings (just soft ones 
)
You should take to your marketing team. They should only announce updates once it’s sure and stable. Oh well, I understand the feeling of both teams 
1 Like
In this case they asked us a reasonable launch date, I said 7th of May 
1 Like
Remember when I posted this:
Turns out it wasn’t the fan, but the light engine.
I’ve tested with both chargers I have, the 15V4A capable PPM standard and another one that’s 15V3A capable, with the same results.
Edit (2:45AM): The noise is gone, unplugging and replugging the power cable no longer has an effect. Difference: the battery is now full charged.
So I now think it might be a combination of the light engine going brighter, and the battery charging. I’ll try some more settings and at a lower battery level again tomorrow to verify or repudiate these findings.
Edit (2:55AM): I was using wired headphones while watching a movie after my initial testing, and when I paused the movie to write the 2:45 edit, I noticed afterwards that there was a hum in the headphones. I unplugged the headphones, et voilá! the noise was back. Plug them in, noise gone. So it seems to be a grounding or some other electrical whining that is picked up by the audio system, and being output by the speakers or the headphone jack (system volume does not affect the sound level of the noise). In the headphones as well as the speakers the sound only happens when plugged in, charge level and status do not have an effect on the noise, contrary to what I thought before.
FW 1.1.0.
When I tested on 1.0.32, I never noticed this noise or behavior.
It wasn’t there before 1.1.0 @Philips_Support_P, I’m pretty sure of that. I’ll try this weekend to find time to finally roll back to 1.0.32 and test my memory.