Posts by milhouse

    This sounds like a hardware fault.

    Presumably it's not the PSU if you've tried 4 different makes/models.

    Have you tried different SD cards (maybe the one you are using is fake, and results in corrupt installations?)

    Or the board itself is faulty - there are some "faulty" Pi3B+ models in circulation (a very small number, which seem to have marginal silicon which is under investigation by the RPi developers), so you may want to consider returning it to your retailer for replacement.

    Before you do send it back, try writing LibreELEC 8.2.5 to your SD card, then open config.txt and add the following settings at the bottom of the file:

    Code
    arm_freq=1200
    over_voltage=2
    sdram_freq=450
    over_voltage_sdram=4
    sdram_schmoo=0x02000020

    and see if that improves things (this isn't a fix, but would be a strong indicator that your board has marginal silicon).

    Yeah, the banned addons don't help.

    However kodi isn't crashing accroding to journalctl (the crash log you uploaded dates from January) so there is no obvious reason why Kodi is freezing - I would suggest renaming /storage/.kodi to /storage/.kodi.bak and rebooting - this will allow Kodi to start with a clean folder and without any addons. If that doesn't work then I would suggest trying with a new SD card.

    The RPi does have a history of destroying SD cards - fortunately those days are long behind us. Now, when an SD card dies the RPi is no better/no worse than any other device - SD cards (in fact, all Flash-based storage) does have a finite lifetime.

    Depends on your needs. Does it have to be x86?

    Until the dust settles, and Intel fix their new platform, or AMD get their act together with cheap NUC-type systems (and LibreELEC ship a more recent kernel supporting all of this new hardware), you may be better off with a cheap ARM based system.

    If you don't need 4K then get a Raspberry Pi 3+. If you do need 4K then there are slightly more expensive ARM systems that should work.

    I'd send it back. Intel stuff just seems to be getting worse with each generation, unfortunately.

    If you do decide to get a Ryzen APU system you'll also need a recent 4.16.y/4.17.y kernel, so using the latest AMD or Intel hardware with LibreELEC is currently a bit of a challenge and you'll need to find suitable community builds.

    Or use a different operating system, such as Windows (which may also work better with your Gemini Lake, as that's all Intel seem to support these days).

    1) Gemini Lake systems seem to have a few issues. Your audio/video issues may be fixed in a future kernel, you could try a community build from escalade based on 4.16.y/4.17.y but my Milhouse builds will be on 4.14.y for the foreseeable future.

    2) Yes, kodi stores the username/password in clear text. It's not ideal, so if you're concerned just use an account that only has very limited access to your media files - ie. don't user your main admin account. If necessary create a new user account with read-only access to your media files.

    As for the Emby Samba issues, I can't really help as I don't know anything about Emby - I'm not even sure what Samba libraries Emby is using. Does Emby support SMB2?

    About the sensitive information, I don't think so - kodi redacts most sensitive information from their log files. I don't think we include in the zip any files that will include credentials. Nobody is likely to hack you based on the contents of the log files.

    The warning about http is a recent change in Kodi 18 which is being addressed - no need to worry about that.

    So you're saying this started out of the blue?

    Do you have a crash log? Run "cat /storage/.kodi/temp/kodi_crash.log | pastebinit" and paste the link.

    it could be disk corruption, can you also run "journalctl -a| pastebinit" and "df -h | pastebinit" and post the links.

    Christ - some standardization amongst the OS vendors would make life a lot frickin easier for devs and end users alike. That's just wild chewitt.

    Yes! You get it! :)

    That's why we've tried to signpost the Samba changes in each release as best we could, and have been criticised for providing too much detail ("I don't want to read a wall of text"). We've been asked to post simple instructions but if it were possible to write "To get Samba working you need to do this, this and this, then sit back and relax", we would have. If we posted all the detail relating to Samba, most people would get a very severe headache (assuming they even read it!)

    Once you understand how much of a mess Samba really, truly, is, it's clear that simple configuration instructions *that can work for everyone* are literally impossible to write as what needs to be tweaked within the network depends entirely on the equipment that each user may have in their network.

    There's obviously Windows XP/Vista/7/8/10 and whatever protocol Microsoft are defaulting SMB to this week. There's Samba running on Linux/FreeBSD/Android, NAS and routers, which is often an ancient/insecure version such as Samba 3.6.y with maximum SMB2_02 support (and impossible to upgrade), or possibly 4.0 with SMB2_10, and maybe even 4.2 with SMB3_00. The more popular Linux distributions (eg. Ubuntu) haven't yet disabled SMB1 by default which leads to more interop compatibility issues when other vendors have disabled SMB1, but they should be doing so soon. And then there's whatever Apple call their half-baked Samba-like implementation on MacOS/iOS/tvOS. Getting all of this to work with a single, common protocol is... tricky.

    When *everything* worked with SMB1 life was so simple (but scary)!

    Maybe in a year or two when SMB2 is supported everywhere life will become a little easier (unless you own an Asus router, of course, in which case you should expect to get owned eventually).

    Many clients should by now be compatible with SMB2, and SMB2 is generally considered to be free of the security flaws that blight SMB1.

    It's probably worth pointing out that SMB2 isn't actually a specific protocol, it's (at least in the most recent versions of Samba, as provided by LibreELEC) a synonym/alias for the SMB v2.10 protocol, while "SMB3" is (currently) an alias for SMB v3.11 which is the latest version of SMB (there have been several versions of v3: SMB3_00, SMB3_02, SMB3_10).

    Samba v4.0 introduced SMB2_10 support, and pre-v4.0 Samba servers that only support SMB v2.00 or SMB v2.02 may not be accessible by a LibreELEC Kodi client using "client min protocol=SMB2" as the client will start connecting with SMB2 v2.10, which will fail. In such a case it will be necessary to manually configure "client min protocol=SMB2_02" (or SMB2_00) in /storage/.kodi/.smb/user.conf.

    It's also possible/likely that older versions of Samba (pre-v4.0) may use different values for the SMB2 alias, such as SMB2_00 or SMB2_02, and pre-v4.2 the SMB3 alias will not be supported at all.

    What I'm saying is that the precise "meaning" of "SMB2" and "SMB3" will depend on the version of the Samba client AND the version of the Samba server, as either one could have a different understanding of what each alias means, which could result in an inability to establish a connection. You gotta love Samba, it's such a mess...

    So anyway, just something to be aware of when setting SMB2/SMB3 all around, and you start getting weird results - try manually configuring a specific min/max protocol rather than using a potentially ambiguous alias.

    Also, don't be surprised if Mac OS gives you problems - the Samba server provided by Apple is known to have several issues.

    Actually Kodi min/max when set to None means Kodi client will support SMB1 through SMB3. Since having a client that still supports SMB1 (even if the server doesn't) is at risk of man-in-the-middle connection downgrade exploitation the longer term objective (LE9 etc.) should be for the default Kodi client min/max to become SMB2/SMB3 rather than SMB1/SMB3.

    TDown I don't know what the graphs represent, are you reading from or writing to the 3B+? If you are writing to the 3B+ then where is the data being written - if SD card, could that be the bottleneck?

    I have the following:

    RPi3+, SanDisk Extreme Plus (32GB), wired Gigabit ethernet, running latest Milhouse LibreELEC 9.0 build (Samba 4.8.0)

    Windows 7 PC with SSD, Gigabit Ethernet

    Both clients are connected into the same dumb/unmanaged 8-port GigE switch.

    I'm able to copy a video file from the RPi3+ SD card over Samba to the Win 7 PC at a sustained rate of about 42MB/s - this basically maxes out the 3B+ network connection, which is the bottleneck.

    q6HWkgm.png

    Copying the same file from the Win7 PC to the RPi3+ (to the SD card) copies the file at an average rate of about 30MB/s as now the SD card is the bottleneck (it can't write any faster than about ~25-27MB/s).


    8MGetAW.png

    I'm not sure how to fix the autostart script but just to reiterate what chewitt has said - providing wireless access for a wired client is not what the LibreELEC tethering facility is designed for. Your solution may work now, but it might also break in future if we add additional functionality which is not compatible with this unsupported tethering mode (for the record, we don't have any plans to change tethering - I'm just saying that we could!)

    If your TV has only a wired ethernet port and you want to connect it to your router then my advice would be to consider using Powerline/Homeplug adapters - they're cheap, fast, and can work very well - much better than WiFi - so long as your mains wiring is not too complicated (ie. multiple ring mains) or old.

    Try 8.2.5 which includes LAN driver and firmware fixes for 3B+.

    There are still remaining 3B+ LAN driver and stability issues which the RPi developers are aware of and actively working to fix. Hopefully these issues affect only a minority of users (those with unusual network VLAN/duplex/cable configurations, or 3B+ boards with slightly marginal RAM chips that may require a voltage bump) and will be fixed sooner than later in software when we will release an LibreELEC 8.2.6 update.