Posts by milhouse

    efa2: If you are using Berryboot then that is the source of your problem as it causes exactly this kind of update issue, and is one of the reasons why it is not supported. If you want to use a boot manager then use NOOBS or PINN, or ideally install LibreELEC directly to the SD card without a boot manager.

    What drivers are you expecting? I see several saa716x kernel modules in the latest #0111 build:

    Code
    NUC:~ # find /usr|grep saa716
    /usr/lib/kernel-overlays/base/lib/modules/4.14.13/kernel/drivers/media/pci/saa7164
    /usr/lib/kernel-overlays/base/lib/modules/4.14.13/kernel/drivers/media/pci/saa7164/saa7164.ko
    /usr/lib/kernel-overlays/driver.dvb.crazycat/lib/modules/4.14.13/updates/driver.dvb.crazycat/saa7164.ko
    /usr/lib/kernel-overlays/driver.dvb.crazycat/lib/modules/4.14.13/updates/driver.dvb.crazycat/saa716x_core.ko
    /usr/lib/kernel-overlays/driver.dvb.crazycat/lib/modules/4.14.13/updates/driver.dvb.crazycat/saa716x_dvb.ko
    /usr/lib/kernel-overlays/driver.dvb.crazycat/lib/modules/4.14.13/updates/driver.dvb.crazycat/saa716x_ff.ko
    /usr/lib/kernel-overlays/driver.dvb.crazycat/lib/modules/4.14.13/updates/driver.dvb.crazycat/saa716x_hybrid.ko
    /usr/lib/kernel-overlays/driver.dvb.hauppauge/lib/modules/4.14.13/updates/driver.dvb.hauppauge/saa7164.ko

    Current 4.14.y based Milhouse builds include the crazycat etc. drivers - these drivers are not currently enabled in 4.15-rc releases.

    browseable and writeable are missing the "e". So if you follow directions and edit it to be /storage/.config/samba.conf samba will not work unless you add those "e"s.

    Actually, browsable and writable are accepted synonyms for "browseable" and "writeable" in Samba, so without the "e" these properties do work as expected.

    However, I will correct this in master by adding the missing "e" if only to be consistent as we include the "e" in [global] but not the individual shares, and also because the spelling with "e" is the documented property rather than just a synonym.

    It appears the spelling without the "e" is favoured by US English, which may explain the dual support.

    Installed LibreELEC on a RPi2 myself.

    I can see that these /proc/sys/kernel/sched_*_granularity_ns files are (unfortunately) not available on this kernel...

    (The kernel have not been compile with the corresponding CONFIG option to export this)

    I enabled CONFIG_SCHED_DEBUG=y and rebuilt with kernel 4.14.10 and Linus Torvalds patch:

    Code
    rpi22:~ # grep -H . /proc/sys/kernel/sched_*_granularity_ns
    /proc/sys/kernel/sched_min_granularity_ns:2250000
    /proc/sys/kernel/sched_wakeup_granularity_ns:3000000

    If you wish to test this build I can upload it.

    I've uploaded a new build, #0108b, which is based on 4.14.10, no commits reverted, but includes a new patch from Linus Torvalds (email).

    RPi / RPi2 / Generic

    It would be good for everyone affected by this DVB issue to test this new build, but in particular X86_64 (Generic) users as I get the impression the kernel developers would prefer results from X86_64 systems due to the Raspberry Pi using a non-standard USB host controller driver. Any USB traces etc. would best come from X86_64 systems to eliminate RPi differences etc.

    Edit: This is the patch: DP2

    The kernel is detecting RTL8192DE hardware, but the in-kernel rtl8192de driver is crashing.

    You could try blacklisting the rtl8192de driver:

    Code
    echo "blacklist rtl8192de" >/etc/modprobe.d/blacklist-rtl8192de.conf

    and then rebooting to see if it detected any other WiFi hardware (eg. rtl3090).

    Failing that, try a 4.15.0 test build (with and without /etc/modprobe.d/blacklist-rtl8192de.conf) to see if there's any change in the rtl8192de driver behaviour.

    If all else fails, my advice would be to invest in a pair of Homeplug 500-AV devices, but if you really must use WiFi then buy a cheap (preferably non-Realtek based) USB WiFi dongle.

    i'm pretty sure i got it right, its the option that changes the tv refresh rate to mach the video

    see your post mentioning it here: Intel Apollo Lake

    Ah, so that's what you're on about.

    The mixed up channels and lack of audio in early LE8.2 test builds due to the HBR patches were the primary reason those patches did not ship with official LE8.2 - "Adjust refresh rate to display" may have been implicated as one possible cause but there was never any point investigating further as backporting the HBR patches to the older 4.11.y kernel was clearly a bad idea.

    The HBR patches in LE9.0 (with a more recent kernel) are working fine and to the best of my knowledge "Adjust refresh rate to display" is not causing any issues.

    read thread after thread and all the post that actually did not help, YES I know samba 1 is NG, this does not stop the fact that many users are in the dark.

    Since fresh installs of Windows 10 disable SMB1 support, and also no longer allow anonymous access to shares, did you try leaving the LibreELEC Server min/max protocol as default SMB2/SMB3, and simply enable "Use Samba Password authentication" then set a suitable username/password? That should have worked.

    Re-enabling SMB1 is simply bad advice when the client is Windows 10.

    I am not sure why bringing up a security concern has been responded with such a negative reaction?

    Maybe because passwords being stored in the clear (by Kodi) is nothing new - it's always done that. Choose an account that is suitable for the data being shared, and don't use the admin account to share your movies.

    Nothing has changed here as far as LibreELEC is concerned so I'm not sure why you consider LibreELEC security to now be "diminished".

    pass through for dolby digital and dts work fine with "adjust display refresh rate" on, but the HD-audio only passes through if its set to off, or at least the last time i checked it was that way.

    Are you confusing "Adjust display refresh rate" with "Sync playback to display"? Enabling the latter will disable audio passthrough - this is by design. The refresh rate setting should have no effect on passthrough, HBR audio or not.

    So I take it that you agree that these changes should be reverted at least until 9.0?

    There are no changes to revert. The way it is in 8.2.2 is how it's going to be from now on (with the exception that in 9.0 you will be able to change the root password).

    Most of this mess is caused by Microsoft. The latest Samba 4.x releases no longer support anonymous access to Windows shares and now require authenticated access (regardless of SMB protocol), while Microsoft are also disabling anonymous access in new installs of Windows 10, so either way anonymous access to Windows shares is history. Authenticated access is the future.

    SMB1 should be disabled everywhere as it is an actively exploited security risk. Disabling SMB1 has consequences, as network browsing is dependent on SMB1. Not much anyone can do about this right now, but just be assured you're better off without SMB1.

    If you're concerned about entering a clear text password - which I agree is a valid concern - then create a low privileged Windows user to protect access to the share, and don't use your main PC user account.

    e.g. don't go backwards for most, for the apperance of security.

    Generally speaking, LibreELEC 8.2.2 is the most secure version of LibreELEC (and certainly any other *ELEC) released so far. Which is not to say it is without security problems - it's not perfect - but it has certainly not gone backwards in any way, and the security changes are far from cosmetic.

    What has happened is that some gaping security holes within your network (which you might call "features") are no longer supported, and you now need to correctly configure your Windows shares in such a way (ie. with a user account) so that they will continue to work in this wonderful, new and more secure world.

    Nothing will be reverted. Embrace the change.