Posts by trent

    They have removed the 3 sync options. Previously sync playback to display and passthrough could co-exist if you choose dupe/drop audio packets.

    A developer removed this code because he didn't use it personally so now it is just a single 'sync playback to display' toggle and if you choose this toggle then passthrough is disabled.

    Hi,
    I am experiencing an issue where LE sometimes boots with broken network connectivity ('wait for network' setting does not help).

    So I need to manually put a delay into the boot process, it seems to help.

    I use the following autostart.sh and this works to give me a delay... but it's just a blank screen with mouse cursor.

    Code
    sleep 20

    Is there any way to display an image (eg the LE or Kodi splash screen) for the duration of the delay instead of this blank screen with cursor ?

    Thanks

    Maybe try resetting your TV to defaults. Or check if TV has firmware update available.

    Also check your TV settings, the simplest solution is often the most likely. This should be done while the R Pi is playing because most TVs have separate picture settings per source.

    Code
    The triluminos feature means the TV has a 10 bit panel and a wide color gamut option. When turned on, that option will result in more saturated color. Having it off give more natural color.

    As I expected, the protocol is a version of SMB 1.

    I don't know exactly what features each 1.x dialect brings but for sure it is stuck with all the SMB 1 stuff causing low performance and high CPU utilization. 16-bit data size etc.

    I believe Kodi and LE uses Samba 3.6.x which was the first version of Samba to add 'basic support' SMB 2.0. Basic support is their term, so this support may only be partial, maybe that's why it is not working. Samba is currently on v 4.5.0 but I believe there is some technical reason why Kodi/LE cannot go above 3.6.x yet.

    At the end of the day I don't think it's fair nor realistic to expect Samba to be as fast or efficient as the native Windows implementation. But for sure performance can get a little better when Samba is eventually bumped.
    Roadmap - SambaWiki

    The "server" is you Windows 10 that's the samba versión thats mater. Kodi is just a client like Libreelec.

    The client and server negotiate the SMB version based on what each one supports. In this example, when using Kodi on any platform other than Windows, Kodi tells the server that it wants a SMB 1.0 connection because that's all it can support.

    Hi,
    In all Generic builds of LE 8.0 Alpha so far (including LibreELEC-Generic.x86_64-7.90.007), I experience temporary video corruption on some (not all) seeks - chapter skips and so forth. The corruption goes away after a couple of seconds, most likely when new keyframe comes. Sometimes it occurs even when starting a video from the beginning. It is not a deal-breaker, just a bit ugly.

    Problem does not occur in LE 7.0 nor can I recall it happening in any OE build going back several years.

    I suspect the cause is either the Nvidia Legacy driver (changed from LE 7) or perhaps some change in how Kodi 17 does seeks.

    Hardware:
    Atom 230 CPU, Nvidia Ion1 GPU (with 512MB allocated)
    2x1GB ram

    It happens with most H.264 videos I have tried. Mediainfo for the one in log:
    (in this particular playback instance I do a lot of seeks but the corruption only occurs 2-3 times)

    forum.libreelec.tv/core/attachment/548/


    Is the 'Wait for network' option enabled in the Settings Addon, just to make sure you the network connect up during boot time?

    "The use of homeplug may be a factor in the problem". It can indeed. Some even perform worse than a wireless connection.

    Yes, 'wait for network' is enabled. It makes no difference and the 'waiting for network' dialogue lasts only 1-2s before boot continues.

    Regarding this feature - what does LE do to verify network connectivity? Does it ping an outside address? Is it possible for me to create some kind of more thorough check of connectivity before proceeding with boot?

    When I say my homeplugs may be part of the problem - I refer to their 'wake up' procedure rather than general performance. The performance when operational is fine and I regularly watch full BD (40Mbps) with no stuttering. But upon boot I believe they take some seconds to wake up, talk to each other, negotiate PHY rate, decide who is master etc, and establish a connection. So knowing that LE experiences problems if it boots before the network is ready, I have a hunch that perhaps this wake up procedure might be causing the problem.

    The fact that the problem is instantly fixed with a LE reboot suggests to me that LE is the main problem, although it is definitely possible that the homeplugs are a factor. If they were not 100% 'ready' by the time LE booted, could LE be 'stuck' in some degraded network mode?

    Hello,
    I have this problem with LibreElec Jarvis x86-64 running on an Atom/Ion system: sometimes (maybe 1 in 10 boots) my HTPC boots up with very laggy network connectivity.

    I use 'update library on startup' and upon hitting the Kodi homescreen it is immediately apparent that there is a problem - a library scan which normally takes 5-10s can take several minutes. If I try to play a video file (stored on local network and accessed via SMB) it will just freeze or hang for several minutes...maybe it will reach the playback screen but stutter immensely.

    It seems like it is booting with severely broken or severely slow network connectivity - although that is just my impression of the problem, I cannot say for sure if this is what is happening.

    A reboot fixes the problem, it comes back up with normal connectivity.

    The problem also occured with OpenELEC 6.0 and some previous versions, I can't recall exactly how far back it goes.

    I know there is a known problem where Kodi boots too fast, before the network is ready. However I use the 'wait for network' option in LE and it makes no difference. It proceeds past this 'waiting for network' dialogue in 1-2s.

    My system is an Atom230/Ion system, connected to my LAN via homeplug adapter. The use of homeplug may be a factor in the problem - perhaps they take some seconds to 'wake up' and establish link rate - but I have another Atom/Ion LE system also connected via identical homeplug and this system is 100% stable, for several years it has never experienced this problem.

    In the attached log it occurs at the boot around 20:34 on Sep 27th

    Does this describe any known issues?

    Thanks