[jmhenry5150]

Do you have that issue while in Confluence skin or while using other skin? I'm having it in Aeon MQ5 skin but not in Confluence, i also have a casual freeze/hang while browsing the menus or when i switch mode to watch TV and after a while of not being in use, i go back to it only to find out it's frozen and nothing respond so i have to force POWER OFF.
Again this is with AEON MQ5 skin, with Confluence i only had 1 freeze while browsing the menus and that's it with AEON MQ is more frecuent.

Confluence is BORING as hell, now the question is does this box has the guts to run AEON MQ5 with all the whistles? Will adding 2gb more of RAM will make it more fluent and fix some of the issues or not?

I'll disable HARDWARE ACCELERATION and report back, i wonder how are other skins behaving... need FEEDBACK

the hardware acceleration setting doesn't affect UI (skin) rendering, only video playback/decoding.

I may be wrong but the latest fernetmenta XBMC builds (may not be in OpenElec yet) may address this with a workaround : http://forum.xbmc.org/showthread.php?tid...pid1744261

I had some content that always froze prior to this and now plays fine if you disable "Prefer VAAPI rendering" (which retains VAAPI decoding, but uses software de-interlacing AND continues to use the SSE copying for progressive content too) It may not fix everything - but I've not had any hangs with VAAPI acceleration since?

if that's the case, I'll do a custom OE build with that branch.

Matt Devo - I may well be running two Chromeboxes on the same network, both with new core boot firmware, soon. How do I ensure they have different MAC addresses?

current version of my script will persist the MAC address of any newly-flashed box, and allow you to load the device-specific data (VPD) from a firmware backup (if you have it) for any that were originally flashed before I added this feature.

Something so easy was so difficult for me...

When I tried to switch to Developer Mode, by holding reset when power on, there was no signal through the HDMI cable. Nothing displayed on the TV.

If I boot it normally, I can see the screen to log in within 3 seconds. What's going on?

TV? HDMI cable?

your TV is not able to set the resolution needed for the recovery screen/dev boot screen (1024x768). Use a computer monitor to setup instead.

Yeah disabling of "Prefer VAAPI Rendering" is a workaround exactly for that issue. On older builds or on OpenELEC 4.0.x there is another option in Expert Settings of Acceleration: "Use SW Filter" which needs to be turned on.

The Prefer VAAPI Rendering is the inverted setting of "Use SW Filter". It will automatically fallback to VAAPI Rendering when you are decoding surfaces larges than 1920x1088 for peformance reasons.

on OE 4.0.6, I get a full lockup with the "Use SW filter" option selected, but only a ~3-5s hitch with it deselected. I'll try pulling from your repo and see if that works better.

Tried this on my DEV box and received this:

MediaRoom:~ # xrandr --output HDMI1 --set "Broadcast RGB" "Full"
X Error of failed request: BadMatch (invalid parameter attributes)
Major opcode of failed request: 139 (RANDR)
Minor opcode of failed request: 21 (RRSetCrtcConfig)
Serial number of failed request: 63
Current serial number in output stream: 63

perhaps your output isn't on HDMI1, but on HDMI0? there's nothing wrong with the syntax of the command

Werid, I ran this and got a different error:

MediaRoom:~ # xrandr --output HDMI0 --set "Broadcast RGB" "Full"
warning: output HDMI0 not found; ignoring
X Error of failed request: BadRROutput (invalid Output parameter)
Major opcode of failed request: 139 (RANDR)
Minor opcode of failed request: 15 (RRGetOutputProperty)
Serial number of failed request: 36
Current serial number in output stream: 36

---

MediaRoom:~ # xrandr --output HDMI1 --set "Broadcast RGB" "Full"
X Error of failed request: BadMatch (invalid parameter attributes)
Major opcode of failed request: 139 (RANDR)
Minor opcode of failed request: 21 (RRSetCrtcConfig)
Serial number of failed request: 63
Current serial number in output stream: 63

I have OPENELEC standalone. I think Ubuntu might have a different config file for the graphics card. However, I am certain somewhere inside Ubuntu is a way to change this. Sorry I can't help.

I have the exact same - OPENELEC standalone

[Matt Devo]

perhaps your output isn't on HDMI1, but on HDMI0? there's nothing wrong with the syntax of the command

Werid, I ran this and got a different error:

MediaRoom:~ # xrandr --output HDMI0 --set "Broadcast RGB" "Full"
warning: output HDMI0 not found; ignoring
X Error of failed request: BadRROutput (invalid Output parameter)
Major opcode of failed request: 139 (RANDR)
Minor opcode of failed request: 15 (RRGetOutputProperty)
Serial number of failed request: 36
Current serial number in output stream: 36

then the display output selection isn't the issue apparently. BTW, it's helpful if you quote only the relevant part of a post, rather than the entire thing - much easier to read/reply to.

[Mark the Red]

My apologies to all if my how-to isn't 100% for everybody. Last thing I want is to create more headaches for Matt than I already have with my IR receiver issue.

The code worked first time for me without any issues. I was very proud of myself of creating the autostart.sh command because I noticed it wasn't a persistent change and I'm as green as they come with Linux.

Logically, I don't see why this wouldn't work for any of the Celeron Asus Chromebox's, but in case this MIGHT have an effect as to why yours is not working, here is what I did from a brand spanking 100% fresh install of Openelec 4.0.6

Within XBMC:

(1) Settings -> System -> Video Output (Expert Mode) I set the output display to HDMI1 and not the default (auto detect) mode. I also checked to ensure the limited RGB range was not checked off. All other video settings were default, although I did tinker a lot in the audio settings to get full HDMI passthrough.

I only have one cable plugged into my celeron (no keyboard, no mouse, no cat5) just an HDMI cable and of course the power.

I played Sin City and then putty.exe from my computer, root access permission and then the code I posted earlier. The change is immediate and startingly noticeable for anybody with a TV not using a crappy $100 Jensen TN panel display.....

[jsp1]

Voila! Movies now forever viewable with awesome blacks just like God intended!

Sweet! Thank you for posting this. Does it retain with Openelec upgrades, or do you need to reapply each time?

Works great for me on standalone 4.0.6, very noticeable difference!

---

My apologies to all if my how-to isn't 100% for everybody. Last thing I want is to create more headaches for Matt than I already have with my IR receiver issue.

The code worked first time for me without any issues. I was very proud of myself of creating the autostart.sh command because I noticed it wasn't a persistent change and I'm as green as they come with Linux.

Logically, I don't see why this wouldn't work for any of the Celeron Asus Chromebox's, but in case this MIGHT have an effect as to why yours is not working, here is what I did from a brand spanking 100% fresh install of Openelec 4.0.6

Works great, no need for apologies. The autostart was a nice easy bit of persistence too. You should be proud. Great picture quality increase on my 47" LG.

---

Yeah disabling of "Prefer VAAPI Rendering" is a workaround exactly for that issue. On older builds or on OpenELEC 4.0.x there is another option in Expert Settings of Acceleration: "Use SW Filter" which needs to be turned on.

The Prefer VAAPI Rendering is the inverted setting of "Use SW Filter". It will automatically fallback to VAAPI Rendering when you are decoding surfaces larges than 1920x1088 for peformance reasons.

Fails hard for me too. Hard crash when trying to play 1080p video on openelec current release. Glad to know you are keeping an eye on the thread though!

[Mark the Red]

Matt,

Just curious, what XBMC skin are you using?

[jsp1]

If it helps narrow anything down here is my setup, which worked with Mark the Red's tutorial. (Wiki worthy by the way...in my opinion)

Asus Chromebox - Openelec standalone 4.0.6 > Pioneer vsx-821 receiver > LG 47" LCD (calibrated) all by hdmi only.
Ethernet connected to my network through a switch.
Logitech K400 - always plugged in dongle
MCE remote - generic Chinese knockoff

Log in through ssh with Putty from windows 7 w/ login: root and password: openelec

Copy and paste commands being careful not to leave spaces from clipboard.

No failures...I had a movie playing during this as well perhaps that has something to do with it.
Image instantly switched to nice dark blacks.

It was HDMI1 in my case.

Not sure if any of that is relevant, but I figured it is better than *shrug* "It works for me."

Sorry for that initial response implied but not intended attitude.

[Netix]

My apologies to all if my how-to isn't 100% for everybody. Last thing I want is to create more headaches for Matt than I already have with my IR receiver issue.

The code worked first time for me without any issues. I was very proud of myself of creating the autostart.sh command because I noticed it wasn't a persistent change and I'm as green as they come with Linux.

Logically, I don't see why this wouldn't work for any of the Celeron Asus Chromebox's, but in case this MIGHT have an effect as to why yours is not working, here is what I did from a brand spanking 100% fresh install of Openelec 4.0.6

Within XBMC:

(1) Settings -> System -> Video Output (Expert Mode) I set the output display to HDMI1 and not the default (auto detect) mode. I also checked to ensure the limited RGB range was not checked off. All other video settings were default, although I did tinker a lot in the audio settings to get full HDMI passthrough.

I only have one cable plugged into my celeron (no keyboard, no mouse, no cat5) just an HDMI cable and of course the power.

I played Sin City and then putty.exe from my computer, root access permission and then the code I posted earlier. The change is immediate and startingly noticeable for anybody with a TV not using a crappy $100 Jensen TN panel display.....

Worked perfectly fine for me the first time also ! Running standalone openelec here, Thx for the input.

It should be added to the wiki.

[Matt Devo]

Matt,

Just curious, what XBMC skin are you using?

for testing, Confluence

Worked perfectly fine for me the first time also ! Running standalone openelec here, Thx for the input.

It should be added to the wiki.

this is going to be dependent on the specific display the user has connected. On my 24" Dell Monitor, it makes no difference whatsoever.

[jsp1]

Mark the Red,

Amber and Neon both have quite acceptable performance with a good feature set. I haven't had many recent problems with either skin. If you were looking for alternatives to Confluence or Aeon.

[Mark the Red]

^^^^

Thanks Matt and jsp1. I have no performance issues with any skin whatsoever although I did upgrade the memory. In fact, I am very impressed with how responsive this $200 ($170 + $25 memory) rig is. For instance, I was streaming a 20GB 1080p .mkv file with DTS-MA 7.1 audio last night and it didn't even blink over wifi when I fast forwarded or jumped to different scene. Didn't even blink an inch. Awesome.

Regarding the skins, I like Aeon Nox but I just wanted to know what the pro's use. Grass is greener and all....

---

this is going to be dependent on the specific display the user has connected. On my 24" Dell Monitor, it makes no difference whatsoever.

Agreed, that is why Intel defaults their gpu's to the limited RGB range for increased CPU compatibility. Most computer monitors don't have great black levels.

BUT the big value added feature to most Home Theater TV's (especially plasma's) is their high contrast ratios and deep inky black levels. I would also say the same thing about Smartphones. For some reason PC's are slow to the party. It's too bad because without coming off as too much of a Home Theater snob, once you've watched a good HD source on a TV that can accurately represent and distinguish the blacks in the 0-16 range, you can't go back. Even my wife noticed it right away when I showed her last night. AND 5 years ago she wouldn't care a fig between a Jensen Walmart TV and a Pioneer Kuro. Sin City, Bladerunner and No Country for Old Men are perfect movies to demonstrate how important good blacks are.

[jsp1]

Oh, OK...I thought I had seen a post about Aeon performance. That is the only reason I chimed in. I've been under the impression that Confluence is the "Official" xbmc skin and therefor is used by all/most people who have anything to do with development. I could be wrong though...it's been known to happen.

[Matt Devo]

this is going to be dependent on the specific display the user has connected. On my 24" Dell Monitor, it makes no difference whatsoever.

Agreed, that is why Intel defaults their gpu's to the limited RGB range for increased CPU compatibility. Most computer monitors don't have great black levels.

BUT the big value added feature to most Home Theater TV's (especially plasma's) is their high contrast ratios and deep inky black levels.
I would also say the same thing about Smartphones. For some reason PC's are slow to the party.....

I'm just not sure how this setting differs from disabling the XBMC setting for 'Use limited color range (16-255)' which is by default not selected.

---

Oh, OK...I thought I had seen a post about Aeon performance. That is the only reason I chimed in. I've been under the impression that Confluence is the "Official" xbmc skin and therefor is used by all/most people who have anything to do with development. I could be wrong though...it's been known to happen.

this is correct

[Mark the Red]

I'm just not sure how this setting differs from disabling the XBMC setting for 'Use limited color range (16-255)' which is by default not selected.

What I don't know about Linux, OpenELEC kernels would fill the Library of Congress. But there is no question whatsover that the Intel xrandr config file supercedes the XBMC checkbox setting. I can assure you this is not a placebo or psychosomatic fix. It IS a night and day difference. The dudes over at the Intel forum where I located the fix can speak a lot more intelligently regarding the how and why of this.

[jsp1]

Matt,

Given the instant change in picture quality when the command was initiated, I would assume that for some people the 'Use limited color range' feature is not functional. Mine was already disabled, however it was obviously not using the extended color palette. It was definitely not placebo though I was watching the screen as it happened.

[Matt Devo]

What I don't know about Linux, OpenELEC kernels would fill the Library of Congress. But there is no question whatsover that the Intel xrandr config file supercedes the XBMC checkbox setting. I can assure you this is not a placebo or psychosomatic fix. It IS a night and day difference. The dudes over at the Intel forum where I located the fix can speak a lot more intelligently regarding the how and why of this.

Matt,

Given the instant change in picture quality when the command was initiated, I would assume that for some people the 'Use limited color range' feature is not functional. Mine was already disabled, however it was obviously not using the extended color palette. It was definitely not placebo though I was watching the screen as it happened.

I didn't mean to come across as dismissive, just wanted to point out that it's not something everyone will necessarily need to do. I'll hook one of my CB's up to my Panny plasma tonight and see if any effect there. With my Dell monitor (and DisplayPort connection) there's a momentary freeze followed by a screen refresh, but no change in PQ or color range.