Obsolete
Status Update
Comments
to...@gmail.com <to...@gmail.com> #2
Some additional information - it seems that it affects only hardware decoded videos (e.g. enabling "Force software decoding" in Archos Video Player makes the issue disappear.) It's also interesting to note that Kodi does not show the issue even with hardware acceleration.
am...@gmail.com <am...@gmail.com> #4
Have the same issue with my NP on 6.0. Washed out blacks. Only tried it with the Play movies & TV app. My other NP on 5.1.1 works fine.
dh...@gmail.com <dh...@gmail.com> #5
Same problem on two Nexus Players with Android TV 6.0. Dark movies are unwatchable - darks are too light...washed out as others say. Only occurs during video playback. Not affecting interface of OS or apps.
dh...@gmail.com <dh...@gmail.com> #6
sigh... all the blacks look like light grey :( Please fix this. Videos are unwatchable.
km...@gmail.com <km...@gmail.com> #7
Same here, noticed after the 6.0 update.
dh...@gmail.com <dh...@gmail.com> #8
Same issue here with youtube. It's really annoying.
n0...@gmail.com <n0...@gmail.com> #9
On my Nexus 6P the original MDA89D build didn't have this issue, but flashing the 3 other images shows the issue.
It's especially bad on AMOLED screens as the RGB value 0/0/0 should turn the screen off completely, this this doesnt and is washed out.
It's especially bad on AMOLED screens as the RGB value 0/0/0 should turn the screen off completely, this this doesnt and is washed out.
km...@gmail.com <km...@gmail.com> #10
I notice that this still has a Priority of "Small". I think for those of us who are experiencing it, it's more like an Emergency level thing. Please help.
[Deleted User] <[Deleted User]> #11
Figured I'd add some photos as I did just get another nexus player out of the box and noticed this with my other one, I named the pictures the version of android they are on. Current build I'm running is MRA58N. First one is from 5.0, then 5.1.1, then 6.0. As you can tell by the last one, Dennis' shirt is really light blue and if you look at the objects beside him they seem washed out/the lighting isn't correct. Thank you!
n0...@gmail.com <n0...@gmail.com> #12
The difference in the blacks behind Dennis is especially noticeable. Very poor on the last image
n0...@gmail.com <n0...@gmail.com> #13
This happens on both my Nexus 6P and Nexus 5X as well!
bi...@gmail.com <bi...@gmail.com> #15
Here are a couple screenshots from my Nexus 5X to show the issue. Note, it helps to compare the images in a dark room.
Here is a screenshot of a video as played within the YouTube app. Notice the black portions of the image are actually dark gray.
http://i.imgur.com/76hNVHj.png
And here is a screenshot of the same video being playing within Chrome. Notice the deeper black and better contrast.
http://i.imgur.com/WQNAYq7.png
And here's a link to the video if you want to see it yourself:https://www.youtube.com/watch?v=JApehOE5PrI
Here is a screenshot of a video as played within the YouTube app. Notice the black portions of the image are actually dark gray.
And here is a screenshot of the same video being playing within Chrome. Notice the deeper black and better contrast.
And here's a link to the video if you want to see it yourself:
ya...@zentertain.net <ya...@zentertain.net> #16
If this is happening on 5X and 6P, this issue should really get more attention than it is. 6P is an AMOLED screen, one of the huge selling points for me is perfect blacks. This issue basically renders that feature obsolete for videos
lr...@gmail.com <lr...@gmail.com> #17
Google, please fix this issue. I expected my Nexus Player to improve with a new OS update, not become unusable. On my LG OLED TV, and the problem is very obvious. For now, I'll have to stream videos using my Xbox instead of Nexus Player.
xc...@gmail.com <xc...@gmail.com> #18
Sorry to everyone who got a notification about this issue and may have gotten their hopes up. I cannot believe that no one has officially recognized this issue other than marking a support thread as "assigned". This affects a number of flagship devices and there is no urgency to fix it even though we are in the middle of the busiest shopping season of the year. I bought 3 nexus players because they have a fantastic UI with great performance. I purposely didn't install 6.0 because of this issue, but I of course didn't know that google pushes updates without asking to nexus players so all 3 look like crap now. Why cant someone at least say this is a known issue and there will be an update out in the coming weeks. Right now I am close to returning all of these players and going back to Roku.
pv...@gmail.com <pv...@gmail.com> #19
While many users will not notice the image quality difference, that does not discount the fact that there is one and it is a dealbreaker for a dedicated media player to have these issues for any length of time. Every user is affected by this and is exposed to it any time they're watching video. Patching this should be priority number 1.
mo...@gmail.com <mo...@gmail.com> #20
It's possible the colour/gamma issues with devices other than Nexus Player are caused by unrelated bugs, as they use completely different platform drivers for their displays. Please do not assume they are the same, use https://code.google.com/p/android/issues/detail?id=192577 to track the colour/gamma problem on Nexus 6P.
km...@gmail.com <km...@gmail.com> #21
I have this issue on my Nexus Player as well. I hope it's getting fixed before Kodi launch their next version which will use the internal decoder. Right now "cast" youtube through Kodi to get around the issue.
mo...@gmail.com <mo...@gmail.com> #22
I just got a Nexus Player and have had the same issue since 6.0 update. In 5.1 and 5.0 Youtube and Google Play Movies were fine, after updating to 6.0 blacks are grey and it is very noticeable. This makes my Nexus Player unusable for viewing video and I will have to return it. My Raspberry Pi Kodi and my legacy smart tv app show YouTube videos just fine, with proper blacks. My tv is a 2014 Sony KDL-40W605B with HDMI levels set to auto.
I wonder how widespread is this bug, I mean, if every Nexus Player with 6.0 suffers from the issue or it is just some of us. And if, as I suspect, this is a widespread bug, why it hasn't been fixed by now and just assigned a "small" priority, since this bug just breaks the main purpose of the device and makes it useless.
I wonder how widespread is this bug, I mean, if every Nexus Player with 6.0 suffers from the issue or it is just some of us. And if, as I suspect, this is a widespread bug, why it hasn't been fixed by now and just assigned a "small" priority, since this bug just breaks the main purpose of the device and makes it useless.
xa...@android.com <xa...@android.com>
si...@gmail.com <si...@gmail.com> #23
I'm also suffering from the same issues as well with my nexus player.I thought my tv was broke. The small priority is a joke as it makes this thing watching content useless. Also I don't like how google just doesn't corresponds and keep us updated with the community about this bug.
pv...@gmail.com <pv...@gmail.com> #24
Hey everyone, We understand the severity of this issue. It's a widespread problem impacting all Nexus Players on 6.0. We're working as fast as possible to resolve it.
We also noticed similar problems on Nexus 6P and 5X, as reported in #14; however, those had a different root-cause. Those have been fixed internally, and will be included in a future MR.
We also noticed similar problems on Nexus 6P and 5X, as reported in #14; however, those had a different root-cause. Those have been fixed internally, and will be included in a future MR.
bu...@ucw.cz <bu...@ucw.cz> #25
For the NP I would suggest offering the ability to let the end-user forcibly choose RGB Full (0-255) or Limited (16-235) system-wide, even if it would be hidden somewhere under Developer Options.
Even if you default to one, there's always the possibility that in an end-user system the other option is the only correct output in a chain of devices (e.g. NP > A/V receiver > TV/projector).
Even if you default to one, there's always the possibility that in an end-user system the other option is the only correct output in a chain of devices (e.g. NP > A/V receiver > TV/projector).
do...@gmail.com <do...@gmail.com> #26
Thank you for updating us and for updating the priority to High. Good to know it's being worked on actively.
Odd that the issue is so similar between the phones and the NP and yet it's a different root cause. I'd be interested in what the causes were, but I suppose I'd be happiest with the fixes
Odd that the issue is so similar between the phones and the NP and yet it's a different root cause. I'd be interested in what the causes were, but I suppose I'd be happiest with the fixes
tt...@gmail.com <tt...@gmail.com> #27
Actually besides video it also happens when chromecasting photos to my NP - while on my Chromecast colors pop nicely.
do...@gmail.com <do...@gmail.com> #28
I guess people with high contrast and crushed black settings on their TV don't notice the problem, but if you have neutral settings or a calibrated display it's very noticeable.
en...@google.com <en...@google.com>
pi...@gmail.com <pi...@gmail.com> #30
Hopefully the devs are serious this time and not teasing us. I was this close to returning the nexus player when the priority was changed from small to high. I agree they should have an option to roll back if they can't get on the ball and fix their issues in a timely matter.
en...@google.com <en...@google.com> #31
Glad that this is finally being addressed. Even with my tv on maximum contrast the picture is still washed out. Hard to believe they allowed the 'upgrade' to go ahead with such a glaring fault.
pi...@gmail.com <pi...@gmail.com> #32
Also relieved to hear this is finally getting traction. I hope there are real signs from Google soon that this platform hasn't already been abandoned.
en...@google.com <en...@google.com> #33
Got a Nexus 6P early November and have noticed the gray blacks during YouTube videos right away. Did some research and this problem is really widespread. Has checked for updates on this issue periodically (so annoying, I check daily now) and surprised it has taken this long for an issue like this to be acknowledged to a higher priority. As of this comment, the problem still persists. -Nexus 6P, with November security update.
km...@gmail.com <km...@gmail.com> #34
Quick update: we have identified the issue in the Nexus Player hardware composer and working on a fix. Thank you for your patience.
en...@google.com <en...@google.com> #35
A google member stated that there won't be a fix this entire month? Hopefully that's not true.
ma...@go-huml.com <ma...@go-huml.com> #36
I'll have sold mine by the time they can be bothered to fix this. Theyve proved they've got no real interest in the nexus player which I suspect will have no support in a few months.
xc...@gmail.com <xc...@gmail.com> #37
Are you ever going to change Android 6. So phone numbers with - can be called back asap as we receive them in text to call.
xc...@gmail.com <xc...@gmail.com> #38
Hopefully they will get a fix out before Christmas. I don't blame people for bringing their nexus back to the store. That's nearly 3 months since the grey washed out colors bug was introduced. A smaller company with less resources like ROKU corrects bugs faster than google.
be...@googlemail.com <be...@googlemail.com> #39
@tergulath@gmail.com - The argument falls flat, because you could easily argue that they do so exactly because they are so small, they have less stuff to correct bugs for ;)
Anyway, the fix is coming, as they have found the issue and now it's just a matter of having patience. - The real issue is that it took this long to make people realize that there actually was an issue... and i am not only speaking about google here. Those who never calibrate their monitor's etc., that didn't think they had/have a issue with the player.
But maybe if the same issue had plagued the chromecast, then a lot more people would have actually noticed it and screamed about it.
Anyway, the fix is coming, as they have found the issue and now it's just a matter of having patience. - The real issue is that it took this long to make people realize that there actually was an issue... and i am not only speaking about google here. Those who never calibrate their monitor's etc., that didn't think they had/have a issue with the player.
But maybe if the same issue had plagued the chromecast, then a lot more people would have actually noticed it and screamed about it.
Description
The last message in LogCat is:
D/dalvikvm(): Trying to load lib /data/data/com.test/lib/libTestLib.so 0x46276110
i.e. it does not get past the loading stage; there is no 'Added shared lib' message.
- Devices running Android 2.3 and above do not seem to be affected.
- Also, libraries that do not include <iostream> don't seem to be affected either.
- The problem does not occur when using the GCC 4.6 toolchain.
Overall, this seems like a critical issue which currently renders the GCC 4.7 toolchain unusable for compiling code that is supposed to be used on devices with Android 2.2.
The following is a minimal example to reproduce the issue:
-------------------------------------------------------
TestActivity.java:
------------------
package com.test;
import android.app.Activity;
import android.os.Bundle;
import android.util.Log;
public class TestActivity extends Activity {
static {
System.loadLibrary("TestLib");
}
@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
Log.d("TestActivity", "Hello, world!");
}
}
TestLib.cpp:
------------
#include <iostream>
Android.mk:
-----------
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE := TestLib
LOCAL_SRC_FILES := TestLib.cpp
include $(BUILD_SHARED_LIBRARY)
Application.mk:
---------------
APP_ABI := armeabi-v7a
APP_STL := gnustl_static # or _shared, doesn't matter
NDK_TOOLCHAIN_VERSION=4.7 # if this is commented out, everything works
-------------------------------------------------------
Digging deeper into the <iostream> source code, I found out that the issue can be traced back to the following code snippet:
--------
namespace std
{
struct ios_base // from <bits/ios_base.h>
{
struct Init
{
Init();
};
};
static ios_base::Init __ioinit;
}
--------
- By replacing the contents of TestLib.cpp with only the above code snippet, the library will fail to load.
- If, additionally, a dummy implementation of std::ios_base::Init::Init() is provided, the library will load successfully.
std::ios_base::Init::Init() {}
- Renaming the namespace from 'std' to another name, e.g. 'xstd', will naturally cause the linker to complain:
error: undefined reference to 'xstd::ios_base::Init::Init()'
This leads me to believe that there is an issue with the implementation of std::ios_base::Init::Init() in the GCC 4.7 sources (as opposed to the GCC 4.6 sources). After checking out the NDK toolchain sources, I could not detect any differences between the different versions of ios_init.cc, where the Init() constructor is defined. That implies that there is an issue with a function used inside the constructor, and this is where I stopped investigating further.