(2014-07-08, 16:44)Matt Devo Wrote:

(2014-07-08, 06:15)Veronica Wrote: 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.

(2014-07-08, 09:44)noggin Wrote: 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=165707&pid=1744261#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.

Quote: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.

(2014-07-08, 11:03)infobank Wrote: 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.

(2014-07-08, 11:31)fritsch Wrote: 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.

(2014-07-08, 16:01)jmhenry5150 Wrote: 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

(2014-07-08, 18:27)Mark the Red Wrote:

(2014-07-08, 16:01)jmhenry5150 Wrote: 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.

(2014-07-08, 18:41)jmhenry5150 Wrote:

(2014-07-08, 16:44)Matt Devo Wrote: 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

(2014-07-08, 08:39)Mark the Red Wrote: Voila! Movies now forever viewable with awesome blacks just like God intended!

(2014-07-08, 21:38)Mark the Red Wrote: 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

(2014-07-08, 11:31)fritsch Wrote: 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.

(2014-07-08, 21:38)Mark the Red Wrote: 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.....

(2014-07-08, 22:43)Mark the Red Wrote: Matt,

Just curious, what XBMC skin are you using?

(2014-07-08, 23:34)Netix Wrote: Worked perfectly fine for me the first time also ! Running standalone openelec here, Thx for the input.

It should be added to the wiki.

(2014-07-08, 23:41)Matt Devo Wrote: this is going to be dependent on the specific display the user has connected. On my 24" Dell Monitor, it makes no difference whatsoever.

(2014-07-09, 00:12)Mark the Red Wrote:

(2014-07-08, 23:41)Matt Devo Wrote: 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.....

(2014-07-09, 00:17)jsp1 Wrote: 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.

(2014-07-09, 00:19)Matt Devo Wrote: 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.

(2014-07-09, 00:26)Mark the Red Wrote: 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.

(2014-07-09, 00:27)jsp1 Wrote: 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.