Kodi Community Forum

Kodi Community Forum > Support > General Support > Linux > LibreELEC Testbuilds for x86_64 (Kodi 19.0)
Full Version: LibreELEC Testbuilds for x86_64 (Kodi 19.0)
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70

Milhouse

2019-06-04, 17:27
(2019-06-04, 02:54)asavah Wrote: [ -> ]@SirMacke It's a known kernel bug.
https://bugzilla.kernel.org/show_bug.cgi?id=203643
it also affects some bluetooth headsets.
@Milhouse
If you want to fix this in your builds there are 2 ways to tackle this
1) revert https://github.com/torvalds/linux/commit...c0ea458265
or
2) apply this (not merged upstream yet) patch https://lore.kernel.org/linux-bluetooth/...n.org/T/#u

The latter reportedly fixed the issue with sixaxis but fails to fix the issue with headsets, the safest way atm IMO is the revert.

@asavah Thanks, but the commit you suggest reverting first appeared in 5.1.1 and isn't in 5.0.y until 5.0.15 (the last 5.0.y kernel for these builds is 5.0.13) but the problem being reported by @SirMacke is apparently with 5.0.10 (#0427). Unfortunately it's a vague confirmation so I can't be sure as he's not sure, and I don't have the time to look into vague reports.

If the bad build number is confirmed/certain then sure, I can spend some time trawling through whatever changed.

@SirMackie all you need to do is test #0426 and #0427 - if you confirm #0426 works and #0427 does not then that's something for me/others to go on, but unfortunately if you're not sure of the build numbers I don't have the time for a potentially wild goose chase.

Milhouse

2019-06-04, 17:36
(2019-06-03, 13:55)lusephur Wrote: [ -> ]Just updated from may 19th daily to June 2nd. My external usb drive formatted to exfat is not recognised. (the other drives formatted to fat32,ntfs,ext4 are.) Exfat drive has been checked with chkdsk and gives no errors, is recognised on other machines (antiquated windows machine and a more recent laptop running manjaro with linux 5.0.20.
Reflashing back to may 19th and drive is again recognisable.
Currently in the midst of moving, have no time to check where the regression occurred. Hopefully it's a simple fix.

I appreciate you're in the middle of a move but testing #0529 and #0530 and confirming which is working/not working would help - I bumped the version of fuse and fuse-exfat in #0530.

If both are working (or not working) then I'll need you to pin down the breaking build by testing the builds between #0519 and #0602 - I don't have exfat drives to test with.

With a broken build (ideally #0603) please connect your exfat drive and then run journalctl -a | pastebinit and post the link so I can see what error is being reported (if any).

Milhouse

2019-06-04, 22:38
New LibreELEC.tv Matrix build #0604: Generic
(Supercedes previous build)

SHA256 Checksum: c676bf3bb2f84ae7c1ba7a0d2883a1b08a9a01b9c2f307ee97922d6e8e13cfb1 (Generic)

text:
# uname -a

Linux NUC 5.1.7 #1 SMP Tue Jun 4 21:16:04 BST 2019 x86_64 GNU/Linux



# lsb_release

LibreELEC (Milhouse): devel-20190604211523-#0604-g5d2f206 [Build #0604]



# Kodi version

Kodi (19.0-ALPHA1 Git:75c1d6b). Platform: Linux x86 64-bit

Based on tip of LibreELEC.tv master (5d2f206, changelog) and tip of XBMC master (75c1d6b, changelog) with the following modifications: Build Highlights:
  1. New 5.1.7 kernel
  2. xf86-video-nvidia: update to xf86-video-nvidia-430.14
Build Details:
  1. XBMC:
    • support AVCHD format disk/image/folder (PR:16131, 1 commit, 3 files changed)
  2. Additional commits/pull requests/changes not yet merged upstream:
    • Updated: [env] PR:3540 (perma): linux (RPi/Generic/Allwinner): update to linux-5.1.7
    • Added: [env] PR:3543 (perma): xf86-video-nvidia: update to xf86-video-nvidia-430.14

Milhouse

2019-06-04, 23:00
(2019-06-04, 17:27)Milhouse Wrote: [ -> ]@asavah Thanks, but the commit you suggest reverting first appeared in 5.1.1 and isn't in 5.0.y until 5.0.15 (the last 5.0.y kernel for these builds is 5.0.13) but the problem being reported by @SirMacke is apparently with 5.0.10 (#0427). Unfortunately it's a vague confirmation so I can't be sure as he's not sure, and I don't have the time to look into vague reports.

If the bad build number is confirmed/certain then sure, I can spend some time trawling through whatever changed.

@SirMackie all you need to do is test #0426 and #0427 - if you confirm #0426 works and #0427 does not then that's something for me/others to go on, but unfortunately if you're not sure of the build numbers I don't have the time for a potentially wild goose chase.

This RPi post suggests that Bluetooth issues were first seen in #0514 which - in the case of RPi - corresponds with the introduction of kernel 5.1.1 (updating from 5.1.0). This is why I'm a bit anal about bug reports being accurate rather than vague with regard to working/not working build numbers! Smile

In kernel 5.1.1 there are four new Bluetooth related commits:

https://github.com/torvalds/linux/commit...228e50cce7
https://github.com/torvalds/linux/commit...0c11a503a1
https://github.com/torvalds/linux/commit...4522ae806b (as suggested by @asavah)
https://github.com/torvalds/linux/commit...b44ec4d3d3

For x86_64 we switched to 5.1.1 with #0512.

@SirMacke it would be worth testing #0511 and #0512, and confirming if the same Bluetooth working/not working behaviour is seen there.

I'll upload a build later this evening with the commit suggested by @asavah reverted.

Milhouse

2019-06-04, 23:56
Weekly Linux 5.2-rc3 build #0604x: Generic

Known issues:
text:


No dvb-latest or crazycat drivers

Temporary bluez build hack

Milhouse

2019-06-05, 00:17
(2019-06-03, 15:38)SirMacke Wrote: [ -> ]Issue since #0427 I think.
Using a Playstation 3 Bluetooth remote to my Intel NUC running LibreElec + Kodi native.
From #0427 (I guess, did not check version before upgrade) I can no longer connect the remote.
It has always been connected automatically before, but now it is disconnected.
It cannot be paired any more.
"Pair, connect" only gives a Bluetooth Input/Output error.
Backing to a version before this and the remote works again.

Tried the onboard Bluetooth and an old DLink USB-dongle. Same issue.

Log:
http://ix.io/1KOr

@SirMacke can you test build #0604b: Generic - it has this BT kernel commit reverted.

SirMacke

2019-06-05, 12:01
(2019-06-04, 23:00)Milhouse Wrote: [ -> ]
(2019-06-04, 17:27)Milhouse Wrote: [ -> ]@asavah Thanks, but the commit you suggest reverting first appeared in 5.1.1 and isn't in 5.0.y until 5.0.15 (the last 5.0.y kernel for these builds is 5.0.13) but the problem being reported by @SirMacke is apparently with 5.0.10 (#0427). Unfortunately it's a vague confirmation so I can't be sure as he's not sure, and I don't have the time to look into vague reports.

If the bad build number is confirmed/certain then sure, I can spend some time trawling through whatever changed.

@SirMackie all you need to do is test #0426 and #0427 - if you confirm #0426 works and #0427 does not then that's something for me/others to go on, but unfortunately if you're not sure of the build numbers I don't have the time for a potentially wild goose chase.

This RPi post suggests that Bluetooth issues were first seen in #0514 which - in the case of RPi - corresponds with the introduction of kernel 5.1.1 (updating from 5.1.0). This is why I'm a bit anal about bug reports being accurate rather than vague with regard to working/not working build numbers! Smile

In kernel 5.1.1 there are four new Bluetooth related commits:

https://github.com/torvalds/linux/commit...228e50cce7
https://github.com/torvalds/linux/commit...0c11a503a1
https://github.com/torvalds/linux/commit...4522ae806b (as suggested by @asavah)
https://github.com/torvalds/linux/commit...b44ec4d3d3

For x86_64 we switched to 5.1.1 with #0512.

@SirMacke it would be worth testing #0511 and #0512, and confirming if the same Bluetooth working/not working behaviour is seen there.

I'll upload a build later this evening with the commit suggested by @asavah reverted. 
Hello, yes I just tested every kernel upgrade from 0426 and indeed the issue appears in #0512 and working fine in #0511

Fourweddings

2019-06-05, 14:39
Just did an update to #0604 after not updating for ~ 3 weeks in the milhouse 9.1 and I note that my exfat external USB drives are now not mounting. I have rolled back to #0504 (not sure exactly what version I was on before hand. But exfat is now working again, and I will test and find the release that it broke in.

I can confirm after testing that #0529 works with exfat. And #0530, #0531 and #0604 do not work with exfat.

Milhouse

2019-06-05, 16:57
(2019-06-05, 14:39)Fourweddings Wrote: [ -> ]Just did an update to #0604 after not updating for ~ 3 weeks in the milhouse 9.1 and I note that my exfat external USB drives are now not mounting. I have rolled back to #0504 (not sure exactly what version I was on before hand. But exfat is now working again, and I will test and find the release that it broke in.

I can confirm after testing that #0529 works with exfat. And #0530, #0531 and #0604 do not work with exfat.

Thanks, that gives me something to work on. A journalctl as requested would have been nice.

Milhouse

2019-06-05, 16:59
(2019-06-05, 12:01)SirMacke Wrote: [ -> ]Hello, yes I just tested every kernel upgrade from 0426 and indeed the issue appears in #0512 and working fine in #0511

OK same issue reported by the RPi user. Thanks.

lusephur

2019-06-05, 17:14
(2019-06-04, 17:36)Milhouse Wrote: [ -> ]
(2019-06-03, 13:55)lusephur Wrote: [ -> ]Just updated from may 19th daily to June 2nd. My external usb drive formatted to exfat is not recognised. (the other drives formatted to fat32,ntfs,ext4 are.) Exfat drive has been checked with chkdsk and gives no errors, is recognised on other machines (antiquated windows machine and a more recent laptop running manjaro with linux 5.0.20.
Reflashing back to may 19th and drive is again recognisable.
Currently in the midst of moving, have no time to check where the regression occurred. Hopefully it's a simple fix.

I appreciate you're in the middle of a move but testing #0529 and #0530 and confirming which is working/not working would help - I bumped the version of fuse and fuse-exfat in #0530.

If both are working (or not working) then I'll need you to pin down the breaking build by testing the builds between #0519 and #0602 - I don't have exfat drives to test with.

With a broken build (ideally #0603) please connect your exfat drive and then run journalctl -a | pastebinit and post the link so I can see what error is being reported (if any). 

Sorry for the delay in replying. Unfortunately, I can't test any versions as everything is packed up at present. It'll be a week or so before I can get access. Sorry.

Milhouse

2019-06-05, 21:34
(2019-06-05, 17:14)lusephur Wrote: [ -> ]Sorry for the delay in replying. Unfortunately, I can't test any versions as everything is packed up at present. It'll be a week or so before I can get access. Sorry.

OK thanks - I'm working on reproducing it. Seems to be a compatibility issue between libfuse and the latest fuse-exfat.

Milhouse

2019-06-05, 22:00
I'll be downgrading fuse-exfat from 1.3.0 to 1.2.8 (there wasn't a 1.2.9) as fuse-exfat-1.3.0 seems to have compatibility issues with libfuse-2.9.9 - fuse-exfat-1.3.0 includes changes in preparation for libfuse-3.x which don't appear to be backwardly compatible with libfuse-2.x.

And no, we can't yet upgrade to libfuse-3.x as fuse-exfat-1.3.0 doesn't actually build with libfuse-3.x! So, best to avoid fuse-exfat-1.3.0 for now until it fully aligns with libfuse-3.x.

Milhouse

2019-06-05, 22:54
New LibreELEC.tv Matrix build #0605: Generic
(Supercedes previous build)

SHA256 Checksum: 57982c16e4235ea5a731661cbfdc5851a128491edef9337c396f58fdb0d9c8de (Generic)

text:
# uname -a

Linux NUC 5.1.7 #1 SMP Wed Jun 5 21:22:17 BST 2019 x86_64 GNU/Linux



# lsb_release

LibreELEC (Milhouse): devel-20190605212134-#0605-g17cda55 [Build #0605]



# Kodi version

Kodi (19.0-ALPHA1 Git:75c1d6b). Platform: Linux x86 64-bit

Based on tip of LibreELEC.tv master (17cda55, changelog) and tip of XBMC master (75c1d6b, changelog) with the following modifications: Build Highlights:
  1. Downgrade fuse-exfat to 1.2.8 due to mounting issues (thanks @KrX3D, @Fourweddings)
  2. Revert kernel Bluetooth commit to fix PS3 pairing issues (thanks @asavah, @SirMacke)
Build Details:
  1. LibreELEC.tv:
    • buildsystem: cleanup (addons) and fix (linux) (PR:3531, 14 commits, 19 files changed)
    • linux: drop ati_remote.conf modprobe file (PR:3528, 1 commit, 1 file changed)
    • cleanup initramfs build, drop support for kernel modules in initramfs (PR:3523, 10 commits, 13 files changed)
  2. Additional commits/pull requests/changes not yet merged upstream:
    • Updated: [env] PR:3537 (perma): packages: mega bump
    • Updated: [env] PR:3540 (perma): linux (RPi/Generic/Allwinner): update to linux-5.1.7

Fourweddings

2019-06-06, 13:44
(2019-06-05, 22:00)Milhouse Wrote: [ -> ]I'll be downgrading fuse-exfat from 1.3.0 to 1.2.8 (there wasn't a 1.2.9) as fuse-exfat-1.3.0 seems to have compatibility issues with libfuse-2.9.9 - fuse-exfat-1.3.0 includes changes in preparation for libfuse-3.x which don't appear to be backwardly compatible with libfuse-2.x.

And no, we can't yet upgrade to libfuse-3.x as fuse-exfat-1.3.0 doesn't actually build with libfuse-3.x! So, best to avoid fuse-exfat-1.3.0 for now until it fully aligns with libfuse-3.x.

Hi @Milhouse, I can confirm #0605 is good for exfat now.
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70
Kodi Community Forum > Support > General Support > Linux > LibreELEC Testbuilds for x86_64 (Kodi 19.0)