[n2vwz]

My feelings are that if the Generic X86 Build does not work correctly with Intel Graphics platforms (i.e. ChromeBox, NUC), there should be a separate release for Intel Graphics devices similar to the releases for Raspberry Pi, WeTek and and others where the Generic release is not fully functional.

TV: your job
GPU-driver: LibreELEC's job
kodi: Output full range if Use Limited not ticked, output limited range if use Limited is ticked <- done, implemented working.

According to this, the responsibility for providing a functional GPU-driver for Intel Graphics platforms would fall upon LiberELEC. I searched their forum and didn't find any mention of the black level problem. The Intel GPU black level problem needs to be brought to their attention.

Before LibreELEC's existance, I do know that the Intel GPU black level issue was reported by several people on the OpenELEC forum. OpenELEC, however, never acknowledged the problem or responded to the posts. The issue was completely ignored. It appeared like nobody was home over at OpenELEC.

[moontan77]

For as long as I can remember i've had a memory leak problem with krypton builds where kodi would just freeze completely eventually and before that would happen I would see through the system info screen that one cpu was pinged to 100% while most of the 2gb ram would be used up (but after boot the CPU' usage would be in the single digits and ram usage would be ~300mb).

I'm using an asus chromebox and a recent milhouse build. I have a large channel list in tvheadend (pvr client only on this box) so possibly related.

The log itself is 10mb probably due to so many pvr debug entries. Is there anyone i can PM a link to this log that can look at it?

[n2vwz]

again a noob question :/ Do I have to create the autostart.sh file by myself cause I can't find it. I guess it shoud be in /storage/.config?

Yes, you'll need to create it if it doesn't exist. The filename is: /storage/.config/autostart.sh

Is it acceptable to drop the "autostart.sh" file into the "LIBREELEC/Configfiles Share" folder from a networked windows machine?

[Milhouse]

Is it acceptable to drop the "autostart.sh" file into the "LIBREELEC/Configfiles Share" folder from a networked windows machine?

Should work, yes.

[Milhouse]

New LibreELEC.tv Krypton build #0810: Generic
(Supercedes previous build)

Code:

# uname -a
Linux NUC 4.7.0 #1 SMP Thu Aug 11 01:17:16 BST 2016 x86_64 GNU/Linux

# lsb_release
LibreELEC (Milhouse) - Version: devel-20160811011521-#0810-gf808232 [Build #0810]

Based on tip of LibreELEC.tv master (f808232f, changelog) and tip of XBMC master (fc55b02f, changelog) with the following modifications:

• Includes FernetMenta "VideoPlayer" patches
  
• Includes latest kodi-platform master (c8188d82)
  
• Includes latest libcec master (62b8520c, ahead +15)
  
• Includes latest libnfs master (fac3a954, ahead +34)
  
• Includes latest p8-platform master (041a8c6c, ahead +1)
  
• Includes latest addons: inputstream.mpd (7898a672, +13), inputstream.rtmp (7bf2298e), inputstream.smoothstream (b63ecbb4, +3), peripheral.joystick (5d67d15f, +3), pvr.argustv (e536f32e), pvr.demo (01c68c88), pvr.dvblink (20e1ccb4), pvr.dvbviewer (7a7ead36), pvr.filmon (efd379b8), pvr.hdhomerun (a71e816d), pvr.hts (66dcb89f), pvr.iptvsimple (21e91a5f), pvr.mediaportal.tvserver (72452b9d), pvr.mythtv (d10d210b), pvr.nextpvr (32b3c2ff), pvr.njoy (b5d65655), pvr.pctv (12d8baf1), pvr.stalker (5f440e00, +4), pvr.vbox (f38f82f0), pvr.vdr.vnsi (98673d3a, +1), pvr.vuplus (4f2ad621), pvr.wmc (979c37db)
  
• Includes commits from xbmc/master, ahead +2 (FernetMenta)
  
• Exclude [env] kodi-999.99-PR10164-add-aetempo-filter.patch: Merged upstream
  
• Exclude [env] kodi-999.99-PR10206-recursive-remove.patch: Merged upstream
  
• Exclude [env] kodi-999.99-PR10211-videoplayer-fix-handling-of-progressive-content-in-rendermanager.patch: Merged upstream
  
• Exclude [env] kodi-999.99-VideoPlayer_Fix_build_after_dropping_deinterlacing_mode.patch: Merged upstream
  
• Exclude [env] libcec-PR208.patch: Merged upstream
  
• Include [env] patch: Add kodi binary addons (pvr, adsp, other)
  
• Include [env] patch: curl: bump 7.50.1 (sync with kodi 17b1)
  
• Include [env] patch: Don't build ADSP addons
  
• Include [env] patch: expat: Bump to 2.2.0
  
• Include [env] patch: ffmpeg: Bump to 3.1.2-Krypton-Beta1 (6da2f5f)
  
• Include [env] patch: kodi: sync appliance.xml after xbmc/PR10201
  
• Include [env] patch: init: mount per-client boot/disk if available & configured
  
• Include [env] patch: Bump included addon versions to prevent online updates
  
• Include [env] patch: Add experimental splash video for RPi
  
• Include [env] patch: HACK: Disable multiple PVR addons during migration. Always enable inputstream.* and os.*
  
• Include [env] PR:535: init: Add upgrade check to avoid incompatible upgrades [RFC,WIP]
  
• Revert [env] 46b9b7b3: rtmpdump (Reason: use newclock5 bump)
  
• Include [pkg] 441217d8: logging: Add microsecond timer to log messages (kodi)
  
• Include [pkg] patch: [skin.estuary] Hide watched items on home (kodi-theme-Estuary)
  
• Include [pkg] PR:8645: [video] Add season/TV show artwork to episodes/seasons even if they have their own fanart.
  
• Include [pkg] PR:8824: videodb: fix smart playlists not honoring "Show empty TV shows" setting.
  
• Include [pkg] PR:8922: [guiinfo] extend ranges for listitem properties
  
• Include [pkg] PR:10157: [WIP] Double the backslash in mysql in case we're in 'LIKE'
  

Build Highlights:

1. Minors
   

Build Details:

1. XBMC:
   • Haptics and Controller power-off (PR:9663, 8 commits, 52 files changed)
     
   • [cmake] Modernize find modules and show less verbose output (PR:10256, 5 commits, 50 files changed)
     
   • rbp: Fix up settings group for supportmvc (PR:10268, 1 commit, 1 file changed)
     
   • [PVR] Guide window: Fix selcting channel via channel number input, if… (PR:10267, 1 commit, 1 file changed)
     
   • [PVR] Reset ischannelpreview flag when pvr stream gets closed. Fixes trac#16840. (PR:10264, 3 commits, 3 files changed)
     
   • [cmake/packaging/android] Fix packaging of Python PIL (PR:10271, 1 commit, 1 file changed)
     
   • [PVR] CDirectoryProvider now supports async PVR startup. Fixes favori… (PR:10248, 8 commits, 16 files changed)
     
   • [cmake] Addons cleanup (PR:10257, 6 commits, 21 files changed)
     
   • player: guiinfo, fix typo in case PLAYER_IS_TEMPO (b629c651)
     
   • [cosmetic] whitespace: fix extra newlines (89d175ba)
     
2. inputstream.mpd:
   • Use 64-bit integer for timestamp (aba30506)
     
   • fixed some mpd situations (c69be0b2)
     
   • Merge branch 'fixes' (73b9836c)
     
   • Merge branch 'master' of https://github.com/mapfau/inputstream.mpd (7898a672)
     
3. peripheral.joystick:
   • Rumble and controller power off (PR:43, 3 commits, 13 files changed)
     

[n2vwz]

Is it acceptable to drop the "autostart.sh" file into the "LIBREELEC/Configfiles Share" folder from a networked windows machine?

Should work, yes.

The autostart.sh patch doesn't seem to be working.

I just updated to #0810
I then screen scraped intel-fullrange.sh from your link, pasted it into a text file using notepad, renamed it to autostart.sh and then dropped it into the Config Share folder.
After rebooting, I toggled the limited range setting. The background went from too bright to brighter. I left the box unchecked.
I went to the moving square test pattern. The background was not black. It should be!

I rolled back to #0730. The background on the moving square test pattern background was black as it should be.

I'm not a programmer, but I know enough about programming to be dangerous. I'm thinking that the problem might be a Unix/Linux Ownership or Permissions issue with autostart.sh There hasn't been any discussion regarding permission settings or how to set them correctly.

Is there a detailed HowTo available on installing this patch? Without detailed instructions, installing a patch will be a struggle for anybody without a programming background.

BTW, autostart.sh was still present after rolling back. Apparently, it does not get wiped out in the process of doing an update.

[Milhouse]

Did I mention the hack is unsupported? Pretty sure I did. Yep, I did.

If you're not able to install it then don't install it, just be patient.

[jjslegacy]

Is it acceptable to drop the "autostart.sh" file into the "LIBREELEC/Configfiles Share" folder from a networked windows machine?

Should work, yes.

The autostart.sh patch doesn't seem to be working.

I just updated to #0810
I then screen scraped intel-fullrange.sh from your link, pasted it into a text file using notepad, renamed it to autostart.sh and then dropped it into the Config Share folder.
After rebooting, I toggled the limited range setting. The background went from too bright to brighter. I left the box unchecked.
I went to the moving square test pattern. The background was not black. It should be!

I rolled back to #0730. The background on the moving square test pattern background was black as it should be.

I'm not a programmer, but I know enough about programming to be dangerous. I'm thinking that the problem might be a Unix/Linux Ownership or Permissions issue with autostart.sh There hasn't been any discussion regarding permission settings or how to set them correctly.

Is there a detailed HowTo available on installing this patch? Without detailed instructions, installing a patch will be a struggle for anybody without a programming background.

BTW, autostart.sh was still present after rolling back. Apparently, it does not get wiped out in the process of doing an update.

Can you run the script manually? Does it work? I assume it needs to be made executable like: chmod +x intel-fullrange.sh assuming you are in the right directory.

[Milhouse]

autostart.sh doesn't need to be executable.

autostart.sh does need to be in Unix file format - creating and copying the file via Windows likely means the file is in Windows file format unless you specifically created the file using an editor that supports the Unix file format.

[Milhouse]

Can you run the script manually? Does it work? I assume it needs to be made executable like: chmod +x intel-fullrange.sh assuming you are in the right directory.

If he had command line access we wouldn't be having this conversation...

I really don't want to sound like a complete arsehole but further discussion of the unsupported hack is really a waste of time and just noise. Anyone not able to make it work should start a separate thread, or wait.

[n2vwz]

autostart.sh doesn't need to be executable.

autostart.sh does need to be in Unix file format - creating and copying the file via Windows likely means the file is in Windows file format unless you specifically created the file using an editor that supports the Unix file format.

-rwxr-xr-x 1 root root 725 Aug 10 20:54 autostart.sh

Making it executable didn't help. I have a Unix editor at work. I will give that a try tomorrow.

[Milhouse]

@n2vwz managing Linux boxes is so much easier with ssh. Just install PuTTY. Maybe ssh access should be a prerequisite for testing these builds.

[Eureka]

Run the following 2 commands in ssh:

Code:

wget -q http://nmacleod.com/public/libreelec/intelhack.sh -P/storage/.config
echo "sh /storage/.config/intelhack.sh &" >> /storage/.config/autostart.sh

You only need to run it once. It will survive an upgrade. It's not a supported solution (so won't be added to the first post) - this is just a hack and you'll want to remove it if/when a supported solution is implemented.

Isn't this the easy way to do it? The hardest part of this for me was remembering the name of Putty, which I hadn't used in a while, to ssh in.

(Oops, yeah, what he said.)

[n2vwz]

@n2vwz managing Linux boxes is so much easier with ssh. Just install PuTTY. Maybe ssh access should be a prerequisite for testing these builds.

I do have PuTTY installed and did ssh into the chrome box. I did solve the problem. After opening autostart.sh with vi, I found ^m characters at the end of each line. It was the windows editor that caused the problem. I deleted the ^m characters, saved, and rebooted. The black levels are back where they should be.

I avoided ssh initially because I dreaded the use of vi. The last time I used it was in 1994. It's much easier to drop the file into a folder.

That being said, I noticed another new "Feature?" that was not present in #0708, but appeared sometime before #0730 and is still present in #0810.
The behavior of step forward and step back has changed:

Previously, you could move forward or backward in time rapidly by holding down the left or right arrow.
Now, pressing the arrow and releasing causes a single step in time to take place. Holding the arrow down causes Kodi to jump from step mode to fast forward mode instead of smooth continuous stepping.

Has anybody else noticed this? Is there a way to restore the previous behavior?

[Milhouse]

There will be a supported fix for the Intel limited range in tonight's #0811 build, enabling limited range as the default for Intel GPUs only, so I really wouldn't waste any more time fiddling about with the hacked solution (which will need to be removed once #0811 is installed).

Details: https://github.com/LibreELEC/LibreELEC.t...-239092154