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.
Posts by milhouse
-
-
What drivers are you expecting? I see several saa716x kernel modules in the latest #0111 build:
CodeNUC:~ # 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.
-
I would actually need a kernel without Linus Torvalds patch and CONFIG_SCHED_DEBUG=y to perform the test I want.
Can you create+upload that for me?
Here's a link to #0109e: RPi2
#0109e is based on 4.14.10 (nothing reverted, no extra buffers commit, no Linus commit) with CONFIG_SCHED_DEBUG=y. This build also includes /usr/bin/perf in case that is useful.
-
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:
Coderpi22:~ # 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 tested the build from post #232 on Raspi3 with DVBSky S960. No artefacts or errors in the stream.
I think you mean post #242, right (the Linus Torvalds patch)?
Is anyone able to test #0108b on x86_64? jahutchi I think you have a Revo 3700 (Atom D525 quad core) - are you able to test this build?
-
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).
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
-
VDR server does not start with that build.
Any clues in the log? I'm doing this blind - I don't run VDR. Presumably the VDR issue is unrelated to the kernel patch.
-
I've uploaded a new build, #0107z, which is based on 4.14.10, no commits reverted, but includes the increased buffer patch suggested in this email.
Please test and report results - thanks!
-
The kernel is detecting RTL8192DE hardware, but the in-kernel rtl8192de driver is crashing.
You could try blacklisting the rtl8192de driver:
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.
-
Are these changes reset with an update of LibreELEC?
No, they remain in effect after an upgrade. To revert back to default simply delete /storage/.config/modprobe.d/8812au.conf and reboot.
-
-
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.
-
does this work with 'adjust display refresh rate' yet??
I don't have my crystal ball with me.
What problem is there with "adjust display refresh rate"?