Guest - Testers are needed for the reworked CDateTime core component. See... https://forum.kodi.tv/showthread.php?tid=378981 (September 29) x
  • 1
  • 40
  • 41
  • 42(current)
  • 43
  • 44
  • 553
Linux ChromeBox Kodi E-Z Setup Script (LibreELEC/Linux+Kodi) [2017/02/21]
(2014-07-11, 01:54)Mark the Red Wrote: Just got my new IR receiver in. Now my wife and I are living the dream! A couple of remote commands are not intuitive to program, but it works fantastically! Thanks again Matt!

I read Yuri's post earlier, but has anyone figured out to have an IR command remote power this thing on from sleep / hibernate mode? It's really no big deal, just a curiosity.

Finally, I just would very much like to give Matt a very sincere and deserved thank you for all your help on this thread and for pioneering this HT solution. This $210 4GB XBMC box (+ IR receiver) exceeds my wildest expectations as to performance and value. It boots in like 4 seconds. Streams HD via WIFI effortlessly and makes my TV look capital "P" pimp with the Ace skin. You are a great man!

appreciate the kind words Smile

the IR resume issue is a Linux/USB3 issue. Something in kernels 3.14+ broke it, since it worked in 3.13 IIRC. Right now, something is causing the USB3 controller to disconnect all devices prior to suspend, which prevents them from being able to wake the system from suspend. This is one of two major outstanding issues (the other being Intel VAAPI bugs which prevent us from being able to use hardware acceleration), and one I'm continuing to work on.
Reply
If that is the case Matt, would a temporary custom compile of openelec with kernel 3.13 have a working suspend/resume? Or would such a thing even be possible without breaking many other things that now rely on the new kernel?
Reply
(2014-07-11, 05:09)jsp1 Wrote: If that is the case Matt, would a temporary custom compile of openelec with kernel 3.13 have a working suspend/resume? Or would such a thing even be possible without breaking many other things that now rely on the new kernel?

that's what I'm working on currently. OpenELEC 4.0.x started off with kernel 3.14, so not sure what dragons await trying to use an older kernel. I'm testing newer kernels first just in case it's already been fixed.
Reply
(2014-07-10, 21:15)Mark the Red Wrote:
(2014-07-10, 06:10)jsp1 Wrote: 1. I was experiencing a degree of black crush using the 'full rgb' xrandr command. (I failed to perceive this without patterns, with them it was quite clear)
2. I was not getting a properly calibrated image leaving everything as is (default).
3. I do get a perfectly calibrated image by using xrandr full rgd + limited output option from within xbmc.

If I check the limited range option after the xrandr command it defaults to the original washed out greyed image.

My TV is a Samsung PN59D8000. I have the color space calibrated via 10p white balance which may explain why my TV is somewhat abnormal in this matter. However, Samsung TV's are no small percent of the market share either...

Apparently the issue is complicated and hardware dependent, in any case it was a combination of both the fix you posted and the info from furii that did the job in my case. My television supports calibration by 100 point IRE, it is quite adjustable but it also has some sort of IPS panel in which blacks are not a strong point. Certainly, it takes more fiddling about to get satisfactory results than all these beautiful plasma screens the rest of you are working with. Anyway, with available test patterns everyone should be able to find the right combo for their needs, even if that is just the default setting. In any case...I am thankful to everyone involved for continuing to share contributions that further improve the box.

(2014-07-11, 05:12)Matt Devo Wrote:
(2014-07-11, 05:09)jsp1 Wrote: If that is the case Matt, would a temporary custom compile of openelec with kernel 3.13 have a working suspend/resume? Or would such a thing even be possible without breaking many other things that now rely on the new kernel?

that's what I'm working on currently. OpenELEC 4.0.x started off with kernel 3.14, so not sure what dragons await trying to use an older kernel. I'm testing newer kernels first just in case it's already been fixed.

Cool, you are always working on new treats for us Big Grin. If you ever want a guinea pig for some beta testing I'd be happy to (try) and help. Thanks for keeping at it, I have never seen someone try so tirelessly strive to fix every problem for any other kit I own. After waiting months for a simple fix from big corporations with a full dev team it is really amazing to see how much you accomplish in such a short amount of time. Every time I get frustrated with my chromebox you give me a new reason to appreciate it. Like Mark, I'd like to take a moment to just say (for like the hundredth time) how much I appreciate your efforts.
Reply
I don't know if this is meaningful or not. On my desktop running Fedora 20 with kernel 3.15.4-200, I am able to wake the system up from sleep with a USB keyboard connected to a USB3 port.
Reply
(2014-07-11, 18:12)YellowDog Wrote: I don't know if this is meaningful or not. On my desktop running Fedora 20 with kernel 3.15.4-200, I am able to wake the system up from sleep with a USB keyboard connected to a USB3 port.

sleep, or S3 suspend? Hold [ALT] then hit the power button on taskbar, then pause button. That will put it into suspend, and see if you can wake it up. I know the default Fedora kernel (3.11.x) is good, trying to figure out now where it broke so I can identify and revert the commit which is causing the issue
Reply
(2014-07-11, 18:15)Matt Devo Wrote:
(2014-07-11, 18:12)YellowDog Wrote: I don't know if this is meaningful or not. On my desktop running Fedora 20 with kernel 3.15.4-200, I am able to wake the system up from sleep with a USB keyboard connected to a USB3 port.

sleep, or S3 suspend? Hold [ALT] then hit the power button on taskbar, then pause button. That will put it into suspend, and see if you can wake it up. I know the default Fedora kernel (3.11.x) is good, trying to figure out now where it broke so I can identify and revert the commit which is causing the issue

Wakes from both 'Sleep' & 'Hibernate'. I'm running KDE, not too sure what back end command is being used, I'm just choosing those commands on the menu. For my system Hibernate works flawlessly, with Sleep the X server gets wonky, just a blank screen happens on USB2 & USB3 wake. But the system is definitely being waken up. I can ssh in after sleep and do a reboot to reset the X server issue.
Reply
(2014-07-11, 19:07)YellowDog Wrote: Wakes from both 'Sleep' & 'Hibernate'. I'm running KDE, not too sure what back end command is being used, I'm just choosing those commands on the menu. For my system Hibernate works flawlessly, with Sleep the X server gets wonky, just a blank screen happens on USB2 & USB3 wake. But the system is definitely being waken up. I can ssh in after sleep and do a reboot to reset the X server issue.

edit: looks like it's an OpenELEC configuration issue. I'm compiling a custom build now which (hopefully) will resolve the issue
Reply
(2014-07-11, 19:10)Matt Devo Wrote:
(2014-07-11, 19:07)YellowDog Wrote: Wakes from both 'Sleep' & 'Hibernate'. I'm running KDE, not too sure what back end command is being used, I'm just choosing those commands on the menu. For my system Hibernate works flawlessly, with Sleep the X server gets wonky, just a blank screen happens on USB2 & USB3 wake. But the system is definitely being waken up. I can ssh in after sleep and do a reboot to reset the X server issue.

edit: looks like it's an OpenELEC configuration issue. I'm compiling a custom build now which (hopefully) will resolve the issue

and fixed. update will go up later tonight. Will just require a manual OE update for anyone already set up.
Reply
(2014-07-12, 02:34)Matt Devo Wrote:
(2014-07-11, 19:10)Matt Devo Wrote:
(2014-07-11, 19:07)YellowDog Wrote: Wakes from both 'Sleep' & 'Hibernate'. I'm running KDE, not too sure what back end command is being used, I'm just choosing those commands on the menu. For my system Hibernate works flawlessly, with Sleep the X server gets wonky, just a blank screen happens on USB2 & USB3 wake. But the system is definitely being waken up. I can ssh in after sleep and do a reboot to reset the X server issue.

edit: looks like it's an OpenELEC configuration issue. I'm compiling a custom build now which (hopefully) will resolve the issue

and fixed. update will go up later tonight. Will just require a manual OE update for anyone already set up.

+1 Can confirm that it works beautifully on my box with a FLIRC.
Reply
(2014-07-12, 02:34)Matt Devo Wrote:
(2014-07-11, 19:10)Matt Devo Wrote:
(2014-07-11, 19:07)YellowDog Wrote: Wakes from both 'Sleep' & 'Hibernate'. I'm running KDE, not too sure what back end command is being used, I'm just choosing those commands on the menu. For my system Hibernate works flawlessly, with Sleep the X server gets wonky, just a blank screen happens on USB2 & USB3 wake. But the system is definitely being waken up. I can ssh in after sleep and do a reboot to reset the X server issue.

edit: looks like it's an OpenELEC configuration issue. I'm compiling a custom build now which (hopefully) will resolve the issue

and fixed. update will go up later tonight. Will just require a manual OE update for anyone already set up.

This getting committed to the official build?
Reply
(2014-07-12, 06:04)jsp1 Wrote:
Matt Devo Wrote: and fixed. update will go up later tonight. Will just require a manual OE update for anyone already set up.

This getting committed to the official build?

Yes. It requires the use of a custom OpenELEC build, since their default configuration is to disable any USB3 controllers prior to suspend. Until I can convince them to change their config, anyway. But the custom build will be part of the script, as well as available for anyone to manually update an existing setup
Reply
(2014-07-12, 02:34)Matt Devo Wrote: and fixed. update will go up later tonight. Will just require a manual OE update for anyone already set up.

Brilliant Cool
Reply
(2014-07-12, 06:32)Matt Devo Wrote: Yes. It requires the use of a custom OpenELEC build, since their default configuration is to disable any USB3 controllers prior to suspend. Until I can convince them to change their config, anyway. But the custom build will be part of the script, as well as available for anyone to manually update an existing setup

Awesome! Thank you once again.
Reply
(2014-07-12, 15:26)YellowDog Wrote: Brilliant Cool

(2014-07-12, 15:58)jsp1 Wrote: Awesome! Thank you once again.

script updated to use my custom OpenELEC build w/USB wake enabled, vs standard OpenELEC build.

wiki updated with instructions, link to update to custom OpenELEC build.

wiki updated with recommended hardware upgrades/accessories.
Reply
  • 1
  • 40
  • 41
  • 42(current)
  • 43
  • 44
  • 553

Logout Mark Read Team Forum Stats Members Help
ChromeBox Kodi E-Z Setup Script (LibreELEC/Linux+Kodi) [2017/02/21]37