[Matt Devo]

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?

I'm not sure what you're referring to by "original ChromeOS update"

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.

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.

---

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

that's a backup of your original ChromeOS install (on the internal HDD) and does not contain a backup of your stock firmware unless you created on manually.

my script simply reads the current firmware (off the chip) and writes it to a file called 'stock-firmware.rom' on the first partition of the selected/inserted USB drive

[jsp1]

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.

[tret]

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.

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.

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?

[Matt Devo]

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/ ).

[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

[tret]

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!

[jsp1]

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/ ).

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.

[Matt Devo]

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.

the MAC address would only be an issue if you had two ChromeBoxes using the same default MAC, but as you said not an issue for a new box.

the hardware ID is actually stored in another section of the firmware, and is relevant only to ChromeOS.

Unfortunately, we're at the mercy of Intel to fix this particular rendering bug.

[teki4u]

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!

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

[Mark the Red]

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/294...0&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!

[noggin]

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/ ).

[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

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?

---

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?

[infobank]

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?

[fritsch]

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.

[jmhenry5150]

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/294...0&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!

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

[Matt Devo]

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

[Mark the Red]

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.