•   
  • 1
  • 141
  • 142
  • 143(current)
  • 144
  • 145
  • 355
  •   
  Thread Closed
v18 LibreELEC Testbuilds for x86_64 (Kodi 18.0)
(2017-11-14, 12:53)HiassofT Wrote: ir-keytable -t
As I am also having the keyrepeat on my IR. (This is an original Microsoft remote model 1039 so it is most definetly in spec as they made the spec iirc).

my dmesg output is here http://sprunge.us/DNMX

Code:
LEDatarum:~ # ir-keytable
Found /sys/class/rc/rc0/ (/dev/input/event7) with:
Driver ite-cir, table rc-rc6-mce
Supported protocols: lirc rc-5 rc-5-sz jvc sony nec sanyo mce_kbd rc-6 sharp xmp
Enabled protocols: lirc nec rc-6
Name: ITE8708 CIR transceiver
bus: 25, vendor/product: 1283:0000, version: 0x0000
Repeat delay = 500 ms, repeat period = 125 ms

Out from ir-keytable -t
Code:
Testing events. Please, press CTRL-C to abort.
1510918507.602656: event type EV_MSC(0x04): scancode = 0x800f041e
1510918507.602656: event type EV_KEY(0x01) key_down: KEY_UP(0x0067)
1510918507.602656: event type EV_SYN(0x00).
1510918507.771347: event type EV_KEY(0x01) key_up: KEY_UP(0x0067)
1510918507.771347: event type EV_SYN(0x00).
1510918507.839795: event type EV_MSC(0x04): scancode = 0x800f041e
1510918507.839795: event type EV_KEY(0x01) key_down: KEY_UP(0x0067)
1510918507.839795: event type EV_SYN(0x00).
1510918508.008017: event type EV_KEY(0x01) key_up: KEY_UP(0x0067)
1510918508.008017: event type EV_SYN(0x00).
1510918517.114511: event type EV_MSC(0x04): scancode = 0x800f041f
1510918517.114511: event type EV_KEY(0x01) key_down: KEY_DOWN(0x006c)
1510918517.114511: event type EV_SYN(0x00).
1510918517.281356: event type EV_KEY(0x01) key_up: KEY_DOWN(0x006c)
1510918517.281356: event type EV_SYN(0x00).
1510918517.351397: event type EV_MSC(0x04): scancode = 0x800f041f
1510918517.351397: event type EV_KEY(0x01) key_down: KEY_DOWN(0x006c)
1510918517.351397: event type EV_SYN(0x00).
1510918517.521348: event type EV_KEY(0x01) key_up: KEY_DOWN(0x006c)
1510918517.521348: event type EV_SYN(0x00).
1510918518.726906: event type EV_MSC(0x04): scancode = 0x800f0421
1510918518.726906: event type EV_KEY(0x01) key_down: KEY_RIGHT(0x006a)
1510918518.726906: event type EV_SYN(0x00).
1510918518.894698: event type EV_KEY(0x01) key_up: KEY_RIGHT(0x006a)
1510918518.894698: event type EV_SYN(0x00).
1510918518.963597: event type EV_MSC(0x04): scancode = 0x800f0421
1510918518.963597: event type EV_KEY(0x01) key_down: KEY_RIGHT(0x006a)
1510918518.963597: event type EV_SYN(0x00).
1510918519.131358: event type EV_KEY(0x01) key_up: KEY_RIGHT(0x006a)
1510918519.131358: event type EV_SYN(0x00).
1510918520.007200: event type EV_MSC(0x04): scancode = 0x800f0420
1510918520.007200: event type EV_KEY(0x01) key_down: KEY_LEFT(0x0069)
1510918520.007200: event type EV_SYN(0x00).
1510918520.174684: event type EV_KEY(0x01) key_up: KEY_LEFT(0x0069)
1510918520.174684: event type EV_SYN(0x00).
1510918520.244202: event type EV_MSC(0x04): scancode = 0x800f0420
1510918520.244202: event type EV_KEY(0x01) key_down: KEY_LEFT(0x0069)
1510918520.244202: event type EV_SYN(0x00).
1510918520.411352: event type EV_KEY(0x01) key_up: KEY_LEFT(0x0069)
1510918520.411352: event type EV_SYN(0x00).
1510918523.638190: event type EV_MSC(0x04): scancode = 0x800f0422
1510918523.638190: event type EV_KEY(0x01) key_down: KEY_OK(0x0160)
1510918523.638190: event type EV_SYN(0x00).
1510918523.807930: event type EV_KEY(0x01) key_up: KEY_OK(0x0160)
1510918523.807930: event type EV_SYN(0x00).
1510918523.875179: event type EV_MSC(0x04): scancode = 0x800f0422
1510918523.875179: event type EV_KEY(0x01) key_down: KEY_OK(0x0160)
1510918523.875179: event type EV_SYN(0x00).
1510918524.044801: event type EV_KEY(0x01) key_up: KEY_OK(0x0160)
1510918524.044801: event type EV_SYN(0x00).

It started showing up when kernel his 4.14 if memory serves right.
@laric thanks a lot for the info!

As a workaround please run "ir-ctl -t 100000" (eg add it to autostart.sh) for now.

I'm currently doing some tests with this proposed upstream fix: https://patchwork.kernel.org/patch/10062139/

This patch seems to improve the repeat issue, but from my tests (using a rc-5 remote with gpio-ir-recv on RPi) it looks like we might still get repeated button events on short presses with 4.14 where it worked fine on 4.13. The fix should be in today's testbuild, then I'd like to ask you to do some more tests.

The underlying issue is a bit complicated and related to timeout handling in the kernel ir receiver code. Your remote (and quite probably also the logitech harmony remotes) is working fine, the issue is triggered by the rather long default idle timeout (200ms instead of usual 125ms) of the ite-cir receiver in combination with a kernel change in timeout handling (164ms instead of 250ms).

I'll investigate this further and discuss it with upstream.

so long,

Hias
(2017-11-17, 14:34)HiassofT Wrote: @laric thanks a lot for the info!

As a workaround please run "ir-ctl -t 100000" (eg add it to autostart.sh) for now.

I'm currently doing some tests with this proposed upstream fix: https://patchwork.kernel.org/patch/10062139/

This patch seems to improve the repeat issue, but from my tests (using a rc-5 remote with gpio-ir-recv on RPi) it looks like we might still get repeated button events on short presses with 4.14 where it worked fine on 4.13. The fix should be in today's testbuild, then I'd like to ask you to do some more tests.

The underlying issue is a bit complicated and related to timeout handling in the kernel ir receiver code. Your remote (and quite probably also the logitech harmony remotes) is working fine, the issue is triggered by the rather long default idle timeout (200ms instead of usual 125ms) of the ite-cir receiver in combination with a kernel change in timeout handling (164ms instead of 250ms).

I'll investigate this further and discuss it with upstream.

so long,

Hias
 Thanks that works.
If my post helped you then there is a nice "Thank user" button on the bottom of the post.
New LibreELEC.tv Leia build #1117: Generic
(Supercedes previous build)

SHA256 Checksum: b613358bc335c1fbd93efe7729fc8bf25cd30464d40a6f1e8aa9da5b456e311a (Generic)

Code:
# uname -a
Linux NUC 4.14.0 #1 SMP Fri Nov 17 21:05:52 GMT 2017 x86_64 GNU/Linux

# lsb_release
LibreELEC (Milhouse): devel-20171117210343-#1117-gbc964ac [Build #1117]

# Kodi version
(18.0-ALPHA1 Git:9a8d03a). Platform: Linux x86 64-bit

Based on tip of LibreELEC.tv master (bc964ac, changelog) and tip of XBMC master (9a8d03a, changelog) with the following modifications: Build Highlights:
  1. kodi: start separating render loop from main thread
  2. Include remote control timeout fix for 4.14
  3. pvr.argustv re-enabled
Build Details:
  1. LibreELEC.tv:
    • ntfs-3g_ntfsprogs : fix build. (PR:2230, 1 commit, 1 file changed)
    • atk : bump to 2.27.1 (PR:2216, 1 commit, 2 files changed)
  2. XBMC:
    • [win32] fixed CAESinkFactoryWin::GetDefaultDeviceId (PR:13055, 1 commit, 1 file changed)
    • start separating render loop from main thread (PR:13043, 2 commits, 39 files changed)
    • fix aml after pr13043 (split renderloop) (PR:13056, 1 commit, 2 files changed)
    • [python-api] InfoTagVideo additional methods (PR:13019, 5 commits, 3 files changed)
    • Fix Back button in Android TV Remote Control app (PR:13049, 4 commits, 14 files changed)
    • [win10] fix compiling test suite (PR:13057, 1 commit, 3 files changed)
    • [filesystem/samba] - support for non-default smb ports (#8931) (19a099c)
  3. pvr.argustv:
    • support PVR API 5.7.0 changes (PR:75, 1 commit, 5 files changed)
  4. Additional commits/pull requests/changes not yet merged upstream:
    • Updated: [env] compare (perma): linux: update to linux-4.14.1-preliminary
    • Updated: [env] PR:2228 (perma): kodi: safe mode
    • Added: [pkg] compare (perma): add safe mode text (service.libreelec.settings)
    • Added: [pkg] PR:74 (perma): [depends] bump jsoncpp to 1.8.3 (pvr.argustv)
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
(2017-11-17, 14:34)HiassofT Wrote: @laric thanks a lot for the info!

As a workaround please run "ir-ctl -t 100000" (eg add it to autostart.sh) for now.

I'm currently doing some tests with this proposed upstream fix: https://patchwork.kernel.org/patch/10062139/

This patch seems to improve the repeat issue, but from my tests (using a rc-5 remote with gpio-ir-recv on RPi) it looks like we might still get repeated button events on short presses with 4.14 where it worked fine on 4.13. The fix should be in today's testbuild, then I'd like to ask you to do some more tests.

The underlying issue is a bit complicated and related to timeout handling in the kernel ir receiver code. Your remote (and quite probably also the logitech harmony remotes) is working fine, the issue is triggered by the rather long default idle timeout (200ms instead of usual 125ms) of the ite-cir receiver in combination with a kernel change in timeout handling (164ms instead of 250ms).

I'll investigate this further and discuss it with upstream.

so long,

Hias
Hi, after last update - it fixed problem with my logitech harmony remote with right and left arrow, stops the double moving. But with up arrow it has new problem - up and down moving with up one press of remote. With settings on harmony remote sw - repeating commands on 1, problem stops. But, with 1 is moving with arrows on menu not so smooth...
The problem with PS3 controllers getting stuck on second player is corrected, i dont know what version has the correction but it working now. The motion sensor from the PS3 controller no long takes the first player position.
when will the Intel Audio DTS fixes reach this build? They are included to the escalade builds. With [b]Milhouse [/b]builds my dts tracks are broken again. But in the escalade builds TVHeadend is broken ... how at least i need a newer version of it and i dont know how to grab...

https://forum.libreelec.tv/thread/9832-i...ugh-patch/

thx
(2017-11-17, 09:25)TimoJ Wrote:
(2017-11-15, 22:57)TimoJ Wrote:
(2017-11-14, 23:13)HiassofT Wrote: Create a file /storage/.config/udev.rules.d/70-input-repeat.rules with the following content:
Code:
ACTION=="add", SUBSYSTEM=="input", KERNEL=="event[0-9]*", GOTO="start"
GOTO="end"
LABEL="start"

# don't change eventlircd device settings
ATTRS{name}=="eventlircd", GOTO="end"

# increase repeat delay to 750ms, use 200ms repeat period
RUN+="/usr/bin/ir-keytable --delay=750 --period=200 --device=$devnode"

LABEL="end"
Change the delay and period parameters of ir-keytable to your likings. Note that this will affect all input devices of your system.

so long,

Hias           

It's not working/changing keyboard parameters. Is there a way to run this in command line and see what it says?        

Nothing seems to help. I also tried with copied and modified 70-input-repeat.rules file from usr/lib/udev/rules.d but still the same. I guess all this doesn't change keyboard repeat rate and there is still some other setting for it? Or is there a bug and LibreELEC is not using/detecting .rules files from /storage/.config/udev.rules.d ? Any way to verify this?     

Looks like the udev rule works but Kodi just ignores keyboard settings that are made there. I put there 750ms to both and then figured out that usb-flirc.tv_flirc-if01-event-kbd  is event4.
They typed
Kodi:~ #  ir-keytable --delay=750 --period=200 --device=/dev/input/event4
Repeat delay = 750 ms, repeat period = 750 ms
Changed Repeat delay to 750 ms and repeat period to 200 ms


So there is 750 value but it has no effect, also using ir-table command via command line has no effect. Are keyboard repeat/delay values hardcoded to Kodi?
New LibreELEC.tv Leia build #1118: Generic
(Supercedes previous build)

SHA256 Checksum: 82bbfe15ae74b48a1020e90e2304c4a5cdeb8141c4ee9c3dd48dd03c95a4e5c3 (Generic)

Code:
# uname -a
Linux NUC 4.14.0 #1 SMP Sat Nov 18 21:04:46 GMT 2017 x86_64 GNU/Linux

# lsb_release
LibreELEC (Milhouse): devel-20171118210319-#1118-gd14656c [Build #1118]

# Kodi version
(18.0-ALPHA1 Git:e00238a). Platform: Linux x86 64-bit

Based on tip of LibreELEC.tv master (d14656c, changelog) and tip of XBMC master (e00238a, changelog) with the following modifications: Build Highlights:
  1. Minors
Build Details:
  1. LibreELEC.tv:
    • scripts/mkimage: use uuid for partitions on RPi (PR:2234, 1 commit, 1 file changed)
    • slice: patch bcm2708-rpi.dtsi so emmc uses /dev/mmcblk0 (PR:2233, 1 commit, 2 files changed)
  2. XBMC:
    • RetroPlayer: Cache/pre-compile output shaders (PR:12929, 2 commits, 12 files changed)
    • [JSON-RPC]Fix wrong playback order for smartplaylists, playlists and upnp (PR:13059, 1 commit, 2 files changed)
  3. pvr.argustv:
    • [depends] bump jsoncpp to 1.8.3 (PR:74, 1 commit, 4 files changed)
  4. Additional commits/pull requests/changes not yet merged upstream:
    • Updated: [pkg] compare (perma): add safe mode text (service.libreelec.settings)
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
(2017-11-18, 19:12)Krautmaster Wrote: when will the Intel Audio DTS fixes reach this build? They are included to the escalade builds. With [b]Milhouse [/b]builds my dts tracks are broken again. But in the escalade builds TVHeadend is broken ... how at least i need a newer version of it and i dont know how to grab...

https://forum.libreelec.tv/thread/9832-i...ugh-patch/

thx

All Intel HBR (High BitRate audio) patches are present in these builds as the patches were accepted upstream in the 4.14 kernel. There are no more patches to add at this time. DTS tracks are not HBR, and without details nobody knows what you mean by "DTS tracks are broken again".
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
yeah sry for that. Retested it and DTS works, had file with old metadata in kodi and the actual file played back had no audio track. Should have checked the logs and info ^^ - thought its the same like in march this year once i could not get HD audio to work with that kaby nuc. Thx for the information
My monologue continues: why xset command is not included in LibreELEC builds? Is it possible to add it to @Milhouse builds?
I just tested my older installation of Kodi with Linux 16.04 and there xset command is available and it actually works and changes Kodi's keyboard rate and delay.
(2017-11-18, 20:06)TimoJ Wrote: Looks like the udev rule works but Kodi just ignores keyboard settings that are made there. I put there 750ms to both and then figured out that usb-flirc.tv_flirc-if01-event-kbd  is event4.
 Sorry for leading you onto the wrong track, changing the event device repeat setting can't work.

It looks like the only way to configure repeat settings in xorg (other than via xset) is to use the -ardelay and -arinterval parameters. Unfortunately there doesn't seem to be an easy way to specify xorg parameters in LE, but you can try this hack:

copy /usr/lib/systemd/system/xorg.service to /storage/.config/system.d
edit the "ExecStart=/usr/bin/xorg-launch..." line and add repeat parameters (eg "-ardelay 5000 -arinterval 1000" for 5 seconds delay and 1 second repeat interval)

so long,

Hias
(2017-11-19, 14:00)HiassofT Wrote:
(2017-11-18, 20:06)TimoJ Wrote: Looks like the udev rule works but Kodi just ignores keyboard settings that are made there. I put there 750ms to both and then figured out that usb-flirc.tv_flirc-if01-event-kbd  is event4.
 Sorry for leading you onto the wrong track, changing the event device repeat setting can't work.

It looks like the only way to configure repeat settings in xorg (other than via xset) is to use the -ardelay and -arinterval parameters. Unfortunately there doesn't seem to be an easy way to specify xorg parameters in LE, but you can try this hack:

copy /usr/lib/systemd/system/xorg.service to /storage/.config/system.d
edit the "ExecStart=/usr/bin/xorg-launch..." line and add repeat parameters (eg "-ardelay 5000 -arinterval 1000" for 5 seconds delay and 1 second repeat interval)

so long,

Hias      

This method works, thank you!
Now that I was able to slowdown the keyboard, I also noticed that in movie listing Kodi is not always scrolling at line speed. Instead, if you keep button pressed when it gets to the bottom or top of the visible movie list, it starts to jump at page speed. However, this doesn't happen in tv-series or music listing. Is this a bug or feature? I think it wasn't always like this, at least not in Kodi 16. Is there a way to disable this "hyperspeed" feature?
Hello! This is my first post on this forum, so hello everyone!
Few days ago i had idea, of connecting some little PC under my TV (old LCD TV without smart or wifi or anything, even no usb).
I choosed Intel NUC DC3217IYE. I bought the cheapes remote, that got USB receiver.
TV is connected with NUC thru HDMI port. I also connected external USB CD/DVD RW to play some old discs.
My main goal was to play music extracted from CD's into flac format thru the home network.
Intel NUC is connected with netkwork by ethernet cable. And everything worked great except Netflix.
That is why i moved from stable build into this testbuilds.
Netflix is working, and YouTube too. Also i can play my flac/mp3 files correctly.
But 1 thing became broken.
My remote stop working, when i leave device alone and not using it for some time.
Not very ling, i wasn't for 6 minutes, when i came back, buttons on remote didn't work at all. And the receiver didn't respond with LED flashes on pressing buttons (which it does when it's working correctly).
Even when i start NUC from zero, and just do not touch it for few minutes, remote stop responding.
There was no this problem with stable release.
I disabled lirc, but it didn't helped.

Can anyone suggest me what can i do about it?
Here are some info:
 # uname -a
Linux TV-Player 4.14.0 #1 SMP Sat Nov 18 21:04:46 GMT 2017 x86_64 GNU/Linux

# lsb_release
LibreELEC (Milhouse): devel-20171118210319-#1118-gd14656c [Build #1118]

 # lspci
00:00.0 Host bridge: Intel Corporation 3rd Gen Core processor DRAM Controller (rev 09)
00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09)
00:16.0 Communication controller: Intel Corporation 7 Series/C216 Chipset Family MEI Controller (rev 04)
00:19.0 Ethernet controller: Intel Corporation 82579V Gigabit Network Connection (rev 04)
00:1a.0 USB controller: Intel Corporation 7 Series/C216 Chipset Family USB Enhanced Host Controller (rev 04)
00:1b.0 Audio device: Intel Corporation 7 Series/C216 Chipset Family High Definition Audio Controller (rev 04)
00:1c.0 PCI bridge: Intel Corporation 7 Series/C216 Chipset Family PCI Express Root Port 1 (rev c4)
00:1c.2 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 3 (rev c4)
00:1d.0 USB controller: Intel Corporation 7 Series/C216 Chipset Family USB Enhanced Host Controller (rev 04)
00:1f.0 ISA bridge: Intel Corporation QS77 Express Chipset LPC Controller (rev 04)
00:1f.2 SATA controller: Intel Corporation 7 Series Chipset Family 6-port SATA Controller [AHCI mode] (rev 04)
00:1f.3 SMBus: Intel Corporation 7 Series/C216 Chipset Family SMBus Controller (rev 04)
02:00.0 Network controller: Broadcom Limited BCM43228 802.11a/b/g/n

Here is full dmesg: dmesg on pastebin
LibreELEC on Intel NUC DC3217IYE (click to find my uname, lsb_release, lspci, lsusb and dmesg info).
  •   
  • 1
  • 141
  • 142
  • 143(current)
  • 144
  • 145
  • 355
  •   
  Thread Closed
 
Thread Rating:
  • 24 Vote(s) - 4.5 Average



Logout Mark Read Team Forum Stats Members Help
LibreELEC Testbuilds for x86_64 (Kodi 18.0)4.524