• 1
  • 104
  • 105
  • 106(current)
  • 107
  • 108
  • 187
v17 LibreELEC Testbuilds for x86_64 (Kodi 17.0)
what does "Speed + 1.000%" in PlayerDebug Screen means? Shouldnt it be "+ 0.000%"?
ASRock Beebox J3160 4GB RAM 120GB SATA SSD - Harmony Elite BT
Intel NUC Kit DN2820FYKH 4GB RAM 120GB SATA SSD - Harmony Smart Control BT
all @ Libreelec Testbuild
HP N54L @ Ubuntu 14.04.4 Minimal Server / MySQL DB
HP N40L @ Ubuntu 14.04.4 Minimal Server
Or "Speed x 1.000%".

What skin?
Aeon Nox 5
ASRock Beebox J3160 4GB RAM 120GB SATA SSD - Harmony Elite BT
Intel NUC Kit DN2820FYKH 4GB RAM 120GB SATA SSD - Harmony Smart Control BT
all @ Libreelec Testbuild
HP N54L @ Ubuntu 14.04.4 Minimal Server / MySQL DB
HP N40L @ Ubuntu 14.04.4 Minimal Server
“Key Repeat” is no longer functional on the Skip Forward and Skip Backward keys:

Left Arrow (←) and Right Arrow (→)

This problem affects USB Keyboards in addition to Remote Controls.

The problem started with build #0729 and continues with current builds. I believe that this is the result of recently added “Long-Press” features disabling “key repeat” for these two keys.

The Long-Press feature changes the key function from skip forward with auto-repeat to 2X fast forward (or Rewind). The feature was intended for low cost Android Boxes with low key count remote controls that do not have Fast Forward and Rewind keys.

Skip Forward and Skip Back with auto-repeat are important functions that should not have been eliminated by the inclusion of “Long-Press” code.

This is a request to restore the previous functionality by removing or provide a simple method of disabling “Long-Press” code.
(2016-08-17, 17:26)n2vwz Wrote: This is a request to restore the previous functionality by removing or provide a simple method of disabling “Long-Press” code.

Unlikely to be changed, to be honest. With my USB keyboard the old default behaviour is actually quite unusable (due to additive seeking) and you'll zip right to the start/end before you've managed to lift your finger from the keyboard, so I can see why the mapping has been altered.

However it's quite easy to create your own custom keyboard mapping in /storage/.kodi/userdata/keyboard.xml that will revert the change:
Code:
<keymap>
  <FullscreenVideo>
    <keyboard>
      <left mod="longpress"></left>
      <right mod="longpress"></right>
    </keyboard>
  </FullscreenVideo>

  <Visualisation>
    <keyboard>
      <left mod="longpress"></left>
      <right mod="longpress"></right>
    </keyboard>
  </Visualisation>
</keymap>
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.
(2016-08-17, 23:38)Milhouse Wrote:
(2016-08-17, 17:26)n2vwz Wrote: This is a request to restore the previous functionality by removing or provide a simple method of disabling “Long-Press” code.

Unlikely to be changed, to be honest. With my USB keyboard the old default behaviour is actually quite unusable (due to additive seeking) and you'll zip right to the start/end before you've managed to lift your finger from the keyboard, so I can see why the mapping has been altered.

However it's quite easy to create your own custom keyboard mapping in /storage/.kodi/userdata/keyboard.xml that will revert the change:
Code:
<keymap>
  <FullscreenVideo>
    <keyboard>
      <left mod="longpress"></left>
      <right mod="longpress"></right>
    </keyboard>
  </FullscreenVideo>

  <Visualisation>
    <keyboard>
      <left mod="longpress"></left>
      <right mod="longpress"></right>
    </keyboard>
  </Visualisation>
</keymap>

I previously tried something similar from an example in the keymap wiki:

Code:
<keymap>
  <global>
    <keyboard>
      <left mod="longpress"></left>
      <right mod="longpress"></right>
    </keyboard>
  </global>
</keymap>

This didn't work for me. Don't know why, but I'm very curious as to why it didn't.
I will try your version.

Quote:With my USB keyboard the old default behaviour is actually quite unusable (due to additive seeking) and you'll zip right to the start/end before you've managed to lift your finger from the keyboard, so I can see why the mapping has been altered.

I'm using a Flirc USB Receiver programmed with keyboard codes with a Popcornhour IR remote. The old behavior works quite well for me. The Keyboard timing is different from the from the remote. That may be the reason it didn't work well for you.
(2016-08-18, 00:19)n2vwz Wrote: This didn't work for me. Don't know why, but I'm very curious as to why it didn't.

Although you're applying your change globally, there are two window specific mappings that override your global setting and it's the window specific settings you need to remove (which is what my version does).

(2016-08-18, 00:19)n2vwz Wrote: I'm using a Flirc USB Receiver programmed with keyboard codes with a Popcornhour IR remote. The old behavior works quite well for me. The Keyboard timing is different from the from the remote. That may be the reason it didn't work well for you.

I'm guessing the change has been made because the old auto-repeat left/right behaviour on a *real* keyboard (rather than an emulated device) is basically unusable.
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.
New LibreELEC.tv Krypton build #0817: Generic
(Supercedes previous build)

Code:
# uname -a
Linux NUC 4.7.0 #1 SMP Wed Aug 17 22:58:53 BST 2016 x86_64 GNU/Linux

# lsb_release
LibreELEC (Milhouse) - Version: devel-20160817225656-#0817-g81237d7 [Build #0817]

Based on tip of LibreELEC.tv master (81237d78, changelog) and tip of XBMC master (0300eae4, changelog) with the following modifications: Build Highlights:
  1. Minors
Build Details:
  1. LibreELEC.tv:
    • spotify-connect-web: rework (PR:616, 1 commit, 7 files changed)
    • kodi/Intel: Various improvements from fritsch (PR:573, 4 commits, 6 files changed)
    • webgrabplus: add user defined pre/post processing (PR:617, 1 commit, 3 files changed)
    • scripts/mkimage: set real volume label on system partition (PR:626, 1 commit, 1 file changed)
    • emby: update and enable optional platform specific hardware transcoding (PR:612, 4 commits, 8 files changed)
    • chromium: add xdotool (PR:597, 2 commits, 3 files changed)
    • multimedia-tools: add alsamixer, bump mpg123 and squeezelite (PR:620, 4 commits, 5 files changed)
    • imagemagic: udpate to 6.9.5-5 (PR:630, 1 commit, 1 file changed)
  2. XBMC:
    • [Language] - added a second label "Input" in the context of input dev… (PR:10301, 1 commit, 2 files changed)
    • Settings: make Peripherals a Standard setting, not Advanced (PR:10302, 1 commit, 1 file changed)
    • [darwin] - fix ssl access from python addons (PR:10108, 11 commits, 17 files changed)
    • TextureManager: We still need to free textures when playing video (PR:10305, 1 commit, 1 file changed)
    • Fix defect in CID 142067 and CID 142228 (PR:10303, 2 commits, 2 files changed)
  3. xbmc/master (FernetMenta):
    • New commits in this build:
      • VideoPlayer: fixes for rewind (608b20f5)
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.
(2016-08-18, 00:38)Milhouse Wrote:
(2016-08-18, 00:19)n2vwz Wrote: This didn't work for me. Don't know why, but I'm very curious as to why it didn't.

Although you're applying your change globally, there are two window specific mappings that override your global setting and it's the window specific settings you need to remove (which is what my version does).

(2016-08-18, 00:19)n2vwz Wrote: I'm using a Flirc USB Receiver programmed with keyboard codes with a Popcornhour IR remote. The old behavior works quite well for me. The Keyboard timing is different from the from the remote. That may be the reason it didn't work well for you.

I'm guessing the change has been made because the old auto-repeat left/right behaviour on a *real* keyboard (rather than an emulated device) is basically unusable.

Your version is working for me. It takes about 5 seconds to for the progress bar cursor to move from beginning to end on a 1 hour program with a continuous key press. There is time to fine tune the cursor position before the jump takes place. Perhaps a menu parameter to set the auto repeat rate would be useful for keyboard users.
(2016-08-17, 14:23)john.cord Wrote: Aeon Nox 5

Report it there then.
New LibreELEC.tv Krypton build #0818: Generic
(Supercedes previous build)

Code:
# uname -a
Linux NUC 4.7.0 #1 SMP Thu Aug 18 21:04:50 BST 2016 x86_64 GNU/Linux

# lsb_release
LibreELEC (Milhouse) - Version: devel-20160818210253-#0818-g44e3ae7 [Build #0818]

Based on tip of LibreELEC.tv master (44e3ae71, changelog) and tip of XBMC master (5ec77196, changelog) with the following modifications: Build Highlights:
  1. Minors
Build Details:
  1. LibreELEC.tv:
    • distro-tool: Fix error, improve performance (PR:631, 1 commit, 1 file changed)
    • packages: Fix legacy OE site URLs (PR:632, 1 commit, 3 files changed)
    • wireless-regdb: update to wireless-regdb-2016.06.10 (PR:633, 1 commit, 1 file changed)
  2. XBMC:
    • VideoPlayer: fixes for rewind (PR:10304, 1 commit, 5 files changed)
    • [estuary] Fix rebase error in #10293 (PR:10306, 1 commit, 1 file changed)
  3. inputstream.rtmp:
    • fixed: bump kodi.inputstream to v1.0.5 (9c05b8dd)
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.
(2016-08-17, 17:26)n2vwz Wrote: “Key Repeat” is no longer functional on the Skip Forward and Skip Backward keys:

Left Arrow (←) and Right Arrow (→)

This problem affects USB Keyboards in addition to Remote Controls.

The problem started with build #0729 and continues with current builds. I believe that this is the result of recently added “Long-Press” features disabling “key repeat” for these two keys.

The Long-Press feature changes the key function from skip forward with auto-repeat to 2X fast forward (or Rewind). The feature was intended for low cost Android Boxes with low key count remote controls that do not have Fast Forward and Rewind keys.

Skip Forward and Skip Back with auto-repeat are important functions that should not have been eliminated by the inclusion of “Long-Press” code.

This is a request to restore the previous functionality by removing or provide a simple method of disabling “Long-Press” code.

I agree and will revert this.
(2016-08-19, 13:12)FernetMenta Wrote:
(2016-08-17, 17:26)n2vwz Wrote: “Key Repeat” is no longer functional on the Skip Forward and Skip Backward keys:

Left Arrow (←) and Right Arrow (→)

This problem affects USB Keyboards in addition to Remote Controls.

The problem started with build #0729 and continues with current builds. I believe that this is the result of recently added “Long-Press” features disabling “key repeat” for these two keys.

The Long-Press feature changes the key function from skip forward with auto-repeat to 2X fast forward (or Rewind). The feature was intended for low cost Android Boxes with low key count remote controls that do not have Fast Forward and Rewind keys.

Skip Forward and Skip Back with auto-repeat are important functions that should not have been eliminated by the inclusion of “Long-Press” code.

This is a request to restore the previous functionality by removing or provide a simple method of disabling “Long-Press” code.

I agree and will revert this.
there must have been a reason for adding this feature, can it not be an option?
(2016-08-17, 00:10)john.cord Wrote: what does "Speed + 1.000%" in PlayerDebug Screen means? Shouldnt it be "+ 0.000%"?

(2016-08-17, 00:16)Hitcher Wrote: Or "Speed x 1.000%".

What skin?

(2016-08-18, 07:49)Hitcher Wrote:
(2016-08-17, 14:23)john.cord Wrote: Aeon Nox 5

Report it there then.

Its the same in Estuary because PlayerDebug Screen is not related to a Skin. My question is if this is a normal behaviour. My settings are so that every file should be played at its native Refresh Rate. I use Refresh Rate switching with "Sync Playback to Display" and "Audio Passthrough off"
ASRock Beebox J3160 4GB RAM 120GB SATA SSD - Harmony Elite BT
Intel NUC Kit DN2820FYKH 4GB RAM 120GB SATA SSD - Harmony Smart Control BT
all @ Libreelec Testbuild
HP N54L @ Ubuntu 14.04.4 Minimal Server / MySQL DB
HP N40L @ Ubuntu 14.04.4 Minimal Server
I think this is being fixed
https://github.com/xbmc/xbmc/pull/10310
  • 1
  • 104
  • 105
  • 106(current)
  • 107
  • 108
  • 187

Logout Mark Read Team Forum Stats Members Help
LibreELEC Testbuilds for x86_64 (Kodi 17.0)11