Posts by trent
-
-
Is the target drive the same one that LE is installed to?
Or are you using a secondary drive? If so what format etc? -
There is no such option (anymore) in current Kodi builds AFAIK?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.
-
Thanks for info. I'll boot into something else to check.
-
Hello,
I have LibreELEC Generic x86 7.90.008 installed on a Seagate 2.5" HDD.How can I view the smart data for this drive ?
Thanks
-
Shiro, I am copying files to LE 7.9.008 from a Win10 machine via gigabit lan and getting approx 90-105MB/s
-
It did not seem to do anything but thanks for the suggestion.
A shorter sleep value would be nice but because it's a sporadic issue (occurs maybe once per 1-2 weeks) it's easier to start high and work backwards.
-
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.
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.
-
Can you plug the RPi into another TV to see if the problem is isolated to your Bravia?
-
You're better off testing, and then if necessary reporting this issue against, one of my testbuilds: LibreELEC Testbuilds for x86_64 (Kodi 17.0)This sort of issue needs to be seen by fernetmenta, and he's unlikely to be reading this forum.
Okay, will do.
-
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 -
Check what SMB protocol the transfer is occurring via. Most likely SMB 1.0
-
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 ramIt 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)
Code
Display MoreGeneral Unique ID : 177756097807476557198521264533524135091 (0x85BA944399705BB48E3990FEA82F3CB3) Complete name : L:\array\Movies 4\movie (2016)\movie.mkv Format : Matroska Format version : Version 4 / Version 2 File size : 7.94 GiB Duration : 2h 2mn Overall bit rate : 9 292 Kbps Encoded date : UTC 2016-10-18 00:35:45 Writing application : mkvmerge v8.3.0 ('Over the Horizon') 64bit Writing library : libebml v1.3.1 + libmatroska v1.4.2 DURATION : 02:02:22.176000000 NUMBER_OF_FRAMES : 229443 NUMBER_OF_BYTES : 587374080 _STATISTICS_WRITING_APP : mkvmerge v8.3.0 ('Over the Horizon') 64bit _STATISTICS_WRITING_DATE_UTC : 2016-10-18 00:35:45 _STATISTICS_TAGS : BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES Video ID : 1 Format : AVC Format/Info : Advanced Video Codec Format profile : [email protected] Format settings, CABAC : Yes Format settings, ReFrames : 5 frames Codec ID : V_MPEG4/ISO/AVC Duration : 2h 2mn Bit rate : 8 654 Kbps Width : 1 920 pixels Height : 808 pixels Display aspect ratio : 2.40:1 Frame rate mode : Constant Frame rate : 23.976 fps Color space : YUV Chroma subsampling : 4:2:0 Bit depth : 8 bits Scan type : Progressive Bits/(Pixel*Frame) : 0.233 Stream size : 7.24 GiB (91%) Writing library : x264 core 148 r2705 3f5ed56 Encoding settings : cabac=1 / ref=5 / deblock=1:0:0 / analyse=0x3:0x133 / me=umh / subme=7 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=0 / chroma_qp_offset=-2 / threads=18 / lookahead_threads=3 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=2pass / mbtree=1 / bitrate=8654 / ratetol=1.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40 / aq=1:1.00 Language : English Default : Yes Forced : No DURATION : 02:02:22.138000000 NUMBER_OF_FRAMES : 176035 NUMBER_OF_BYTES : 7938620453 _STATISTICS_WRITING_APP : mkvmerge v8.3.0 ('Over the Horizon') 64bit _STATISTICS_WRITING_DATE_UTC : 2016-10-18 00:35:45 _STATISTICS_TAGS : BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES Audio ID : 2 Format : AC-3 Format/Info : Audio Coding 3 Mode extension : CM (complete main) Format settings, Endianness : Big Codec ID : A_AC3 Duration : 2h 2mn Bit rate mode : Constant Bit rate : 640 Kbps Channel(s) : 6 channels Channel positions : Front: L C R, Side: L R, LFE Sampling rate : 48.0 KHz Compression mode : Lossy Stream size : 560 MiB (7%) Language : English Default : Yes Forced : No Menu 00:00:00.000 : en:00:00:00.000 00:08:26.548 : en:00:08:26.548 00:16:11.637 : en:00:16:11.637 00:32:38.290 : en:00:32:38.290 00:42:16.367 : en:00:42:16.367 00:52:22.264 : en:00:52:22.264 00:59:50.629 : en:00:59:50.629 01:12:05.530 : en:01:12:05.530 01:22:34.449 : en:01:22:34.449 01:33:00.950 : en:01:33:00.950 01:40:33.319 : en:01:40:33.319 01:47:38.994 : en:01:47:38.994 01:52:32.663 : en:01:52:32.663 01:55:41.351 : en:01:55:41.351
-
I would look at an Intel NUC personally, although maybe wait for the new Apollo Lake ones which (I believe) have HEVC Main 10 decoding.
-
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