[sow07]

Just tried along with a variety of other resolutions and no change.  Strangely the AVR recognizes each resolution after a few seconds of the HDMI symbol blinking (which is a sync indicator by all accounts) and reports it through the setup display, yet can't pass it through.

It's apparently not an EDID issue or else my clone of the working ChromeOS setup would be successful.  Wondering if there are settings which fall outside of EDID or if this is a case of the Ubuntu OS not honoring EDID properly.

I'm stumped.

have you tried booting the latest LibreELEC from usb to see if that works?    

Last night after trying additional configurations (including yet another AVR), I think I figured something out which would explain the voodoo nature of the problem - cable length and quality.

My original (7 years going) configuration uses a longer (12-15ft), seemingly good quality, HDMI cable which goes through the wall.  In one test where I used the same equipment (Yamaha AVR + CN62) but shorter HDMI cables, everything worked fine at 1080p.  The crucial observation was if I use CN62->Cable A (generic 6ft)->AVR->Cable B (legacy 12ft)->TV it fails, but if I use CN62->Cable A (generic 6ft)->AVR->Cable C (generic 3ft)->TV it works!  It appears it is the totality of the signal path length and quality used that determines whether the configuration is going to work.

The AVR being in the signal path also has a hand in the equation; empirically I found certain AVR+cable combinations (with the 12ft cable) using even my "trusty" DirecTV DVR would fail as well.  The same cabling on different AVR's produces varying results suggesting the embedded AVR HDMI switches contribute to the overall system sensitivity.

My built-in assumption that if, Cable B is operational on a particular configuration (say DTV or standard PC based Kodi machine), it's good across the board, appears to be wrong.  The premise being the AVR is regenerating the signal so problems can't be with the totality of the cabling...but my testing proves that it is.  Additionally, the assumption HDMI being a standard in today's day and age would not suffer from these types of issues appears suspect.

As for the fact the CN62 with ChromeOS works at 1080p using original Cables A and B; I'm surmising the OS video drivers have some control over the signal amplitude/strength which could explain the differences there.  I'm not sure how else to account for that.  HDMI is digital of course, but that digital data is flowing over analog copper wires.

My follow-on question now is whether there is a Ubuntu/Chromebox knob for controlling signal strength/amplitude or anything else that could account for the observed behavior?

I'd also like to hear opinions on finding quality HDMI cables that can be trusted to eliminate any finickyness from systems.  I had been purchasing cheap Ebay china made HDMI cables thinking that relatively short cables can't be done wrong.  I'm no longer so sure.  But I'm also not on board with blindly purchasing extreme $ monster cables either...

Meanwhile, hopefully this brings some measure of relief and understanding to those who have battled similarly strange issues especially involving AVR's.  It has for me...

Thanks! 

So I replaced my "12 ft cable" and found out it was actually 30ft long!  Now using a Costco 12' cable and everything came up just fine with both my older Yamaha AVR and the new Integra/Onkyo AVR.  No issues whatsoever.  Confirmed kill I would say!

So if you are pulling your hair out thinking the AVR or source device (Chromebox or otherwise) isn't working the way you expect, make sure to look closely at the cables length/quality to rule that out first.  This is especially true if you have cables in the wall where you cannot verify either the length or quality.  Importantly, don't assume that because it was previously working with other components (for years even) it will continue to do so with newly added components especially when involving an AVR.

Regards!