Fixed
Status Update
Comments
mm...@commonsware.com <mm...@commonsware.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.
yb...@google.com <yb...@google.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.
mm...@commonsware.com <mm...@commonsware.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.
mm...@commonsware.com <mm...@commonsware.com> #6
sigh... all the blacks look like light grey :( Please fix this. Videos are unwatchable.
de...@gmail.com <de...@gmail.com> #7
Same here, noticed after the 6.0 update.
mm...@commonsware.com <mm...@commonsware.com> #8
Same issue here with youtube. It's really annoying.
de...@gmail.com <de...@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.
st...@gmail.com <st...@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.
st...@gmail.com <st...@gmail.com> #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!
yb...@google.com <yb...@google.com> #12
The difference in the blacks behind Dennis is especially noticeable. Very poor on the last image
st...@gmail.com <st...@gmail.com> #13
This happens on both my Nexus 6P and Nexus 5X as well!
da...@google.com <da...@google.com>
ge...@gmail.com <ge...@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:
ma...@marcardar.com <ma...@marcardar.com> #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
vi...@google.com <vi...@google.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.
mo...@gmail.com <mo...@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.
da...@google.com <da...@google.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.
sh...@gmail.com <sh...@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.
ap...@google.com <ap...@google.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.
ap...@google.com <ap...@google.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.
ma...@marcardar.com <ma...@marcardar.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.
da...@google.com <da...@google.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.
ap...@google.com <ap...@google.com> #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).
ap...@google.com <ap...@google.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
ap...@google.com <ap...@google.com> #27
Actually besides video it also happens when chromecasting photos to my NP - while on my Chromecast colors pop nicely.
Description
Version used: 1.0.0-alpha1
Devices/Android versions reproduced on: n/a
A common scenario is where an app needs to ship a database as part of the APK, or downloaded on first run of the app. That might serve as starter data, or it might serve as a read-only database of reference information. For the packaged-in-the-APK scenario, Jeff Gilfelt's SQLiteAssetHelper is a common solution, which replaces SQLiteOpenHelper and transparently copies the database from assets into the proper spot in the filesystem before proceeding.
With Room, there is no obvious way to handle the pre-populated database scenario.
One possibility is that Room doesn't do anything, and we have to arrange to get the database in position prior to creating the RoomDatabase. However, for that to work, we need to know where to put the database. While we supply the database name, technically Room could be storing that database anywhere (e.g., in a room/ subdirectory off of the normal database directory on internal storage). If we are going to go this route, we need some sort of documented statement about where Room stores the database, or a method to retrieve that location (prior to creating the RoomDatabase), so we know where to copy the database file into.
Other possibilities include:
- Having the option of subclassing the Framework implementation of SupportSQLiteOpenHelper, so we can craft a SQLiteAssetHelper-style implementation. Right now, that class is not part of the public API. While we could fork all of the Framework stuff to try to get this, that seems like overkill.
- Having a createFromAsset() and/or createFromFile() method on RoomDatabase.Builder, for us to provide the location of the starter database, for Room to copy into position for us if the database does not already exist.
Thanks!