(2014-07-07, 17:51)jsp1 Wrote: Thanks. Nothing of the sort shows up, lost cause?

Edit: It looks like I can recover my original chromeOS update...perhaps that would contain the info?

(2014-07-07, 18:31)tret Wrote: Has there been any progress (resolution or workaround) for the VAAPI hardware accelerated playback freezing issue?

Symptom - During playback, the video freezes while the audio continues to play. Key presses are non-responsive and the chromebox needs to be powered off/rebooted to regain normal function.

Obviously disabling hardware accelerated playback prevents the symptoms however higher bitrate content playback is choppy, particularly when syncing to a 24p display. I haven't seen much chatting about this issue and haven't been able to find any solutions in the thread. If there isn't one, is this on the XBMC Dev team's radar?

Note: Running standalone openelec v4.0.6. The content is being pulled (over SMB) from a NAS on a 1Gb link. Same config/content works fine on an older Zotac zbox w/ celeron CPU and nvidia GPU.

(2014-07-07, 19:00)tret Wrote: I also set mine up some time ago, approx 6 weeks ago, and haven't updated the firmware since. Matt, is this perhaps something that has been fixed in later firmware/bios updates?

(2014-07-07, 20:17)YellowDog Wrote: I see 12 separate partitions on the firmware backup.

Can anyone suggest how to backup the flash drive. Can I use

Code:

dd if=/dev/sdb of=chrome-backup.img

(2014-07-07, 20:24)Matt Devo Wrote:

(2014-07-07, 18:31)tret Wrote: Has there been any progress (resolution or workaround) for the VAAPI hardware accelerated playback freezing issue?

Symptom - During playback, the video freezes while the audio continues to play. Key presses are non-responsive and the chromebox needs to be powered off/rebooted to regain normal function.

Obviously disabling hardware accelerated playback prevents the symptoms however higher bitrate content playback is choppy, particularly when syncing to a 24p display. I haven't seen much chatting about this issue and haven't been able to find any solutions in the thread. If there isn't one, is this on the XBMC Dev team's radar?

Note: Running standalone openelec v4.0.6. The content is being pulled (over SMB) from a NAS on a 1Gb link. Same config/content works fine on an older Zotac zbox w/ celeron CPU and nvidia GPU.

(2014-07-07, 19:00)tret Wrote: I also set mine up some time ago, approx 6 weeks ago, and haven't updated the firmware since. Matt, is this perhaps something that has been fixed in later firmware/bios updates?

this is a known/documented Intel driver bug, and not a firmware issue.

(2014-07-07, 20:49)jsp1 Wrote: The chromeOS backup is what I was referring to. So that answers my question.

What I don't understand is that so much data is recoverable on the usb that it seems the only thing missing is the firmware backup. Would this be on a fat partition or would it be stuck on some ext4 partition or something? I have stuff coming up from years ago because this drive sees so little use, but not a trace of the firmware rom.

(2014-07-07, 21:12)tret Wrote: [quote='Matt Devo' pid='1748837' dateline='1404757469']


[quote='tret' pid='1748767' dateline='1404750697']
Thanks Matt, do you happen to have any information (main thread, bug number, etc.) about the intel driver bug so I can keep track of it and watch for developments?

(2014-07-07, 21:25)Matt Devo Wrote: https://bugs.freedesktop.org/show_bug.cgi?id=78960

the solution right now is to run with hardware acceleration (VAAPI) disabled until the issue is fixed

(2014-07-07, 21:25)Matt Devo Wrote: I'm pretty sure you would not have been able to use that drive for the firmware backup, the script likely would not handle a flash drive with 12 partitions unless the first was mountable. I guess you could check by manually mounting the first partition ( /dev/sd[x]1/ ).

(2014-07-07, 23:56)jsp1 Wrote: I wasn't clear about it, sorry. I have two separate usb drives...one which was empty and used (presumably) to backup the bios, another drive held the original chromeOS backup. The drive which was supposed to contain the backup of the bios contains no files and does not appear corrupted, however I ran a recovery to try and find the bios file just in case and it is pulling up a lot of old stuff but no sign of the bios at all.

In any case, assuming the bios is lost what are the future problems I might encounter from the lost information? I don't care about using ChromeOS at all, so if that is the only benefit of the correct mac address and box identification then I'm fine without it. However, if it is necessary for some other reason...could I possibly manually insert the correct mac address and device id into the vanilla bios?

From what I understand MAC address is only relevant if I wished to run 2 or more chrome boxes, even then the new box would keep it's own mac so it is a non issue; right? The part I'm not clear on is the device ID, wouldn't that be important if I wanted to load something like Windows 8.1?

Ideally, we see some headway on hardware acceleration under openelec...at least for me the software rendering doesn't always cut the mustard and thus defeats the intended purpose/benefits of the box in the first place.

Sorry for the long and convoluted post. My brain is mush at the moment.

(2014-07-07, 21:27)tret Wrote:

(2014-07-07, 21:25)Matt Devo Wrote: https://bugs.freedesktop.org/show_bug.cgi?id=78960

the solution right now is to run with hardware acceleration (VAAPI) disabled until the issue is fixed

TY sir!

(2014-07-07, 21:25)Matt Devo Wrote:

(2014-07-07, 20:49)jsp1 Wrote: The chromeOS backup is what I was referring to. So that answers my question.

What I don't understand is that so much data is recoverable on the usb that it seems the only thing missing is the firmware backup. Would this be on a fat partition or would it be stuck on some ext4 partition or something? I have stuff coming up from years ago because this drive sees so little use, but not a trace of the firmware rom.

I'm pretty sure you would not have been able to use that drive for the firmware backup, the script likely would not handle a flash drive with 12 partitions unless the first was mountable. I guess you could check by manually mounting the first partition ( /dev/sd[x]1/ ).

(2014-07-07, 21:12)tret Wrote: [quote='Matt Devo' pid='1748837' dateline='1404757469']


[quote='tret' pid='1748767' dateline='1404750697']
Thanks Matt, do you happen to have any information (main thread, bug number, etc.) about the intel driver bug so I can keep track of it and watch for developments?

https://bugs.freedesktop.org/show_bug.cgi?id=78960

the solution right now is to run with hardware acceleration (VAAPI) disabled until the issue is fixed

(2014-07-08, 08:39)Mark the Red Wrote: Are you an owner of this kick-a$$ Chromebox XBMC setup like me (thanks again Matt)?

Do you have a gorgeous HDTV but noticed the blacks seem washed out?

Have you tried all the settings within XBMC such as Settings - > System - > Video Output (Expert Settings)? Even after checking the full range 0-255 RGB box within XBMC the blacks just don't seem as inky as you once remember?

Have you now resigned yourself to video quality mediocrity forever?

Well now you can get that Intel HD Graphics inside your Celeron to give you 21st Century video output!

From root access of ssh terminal type this in (test it while watching a dark movie for maximum effect):

PHP Code:

xrandr --output HDMI1 --set "Broadcast RGB" "Full" 


If that Sin City gray blurry mess you were just watching now comes alive with film-like inky black goodness, congrats, you are now watching what the film studios intended ! (All credit to Hijinx at this thread https://communities.intel.com/thread/29420?start=60&tstart=0) :

Now this xrandr command is just a one time fix; to make this permanent follow the wiki link and do the following via ssh:

PHP Code:

echo "#!/bin/sh" > /storage/.config/autostart.sh && chmod +x /storage/.config/autostart.sh 


then edit the file:

PHP Code:

nano /storage/.config/autostart.sh 


and paste the

PHP Code:

xrandr --output HDMI1 --set "Broadcast RGB" "Full" 


code in, save and exit.

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

(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

(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?

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?

(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?

(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, 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

(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