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.
sleep 20Is 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.
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.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 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)
General
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.351I 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
I think you should be a little careful of the comment you just made re Kodiit will crash/freeze eventually (Kodi cannot be called stable in the modern sense)
The HARDWARE here is the issue, NOT Kodi.
OE, LE and Kodi are all VERY stable. (staying away from nightly and dev builds)
I am not bashing Kodi but there is nothing to be gained by exaggerating it's stability. If you use it for any length of time you will experience some crashes and freezes here and there.... we all know this and have experienced it.
I am not saying this to bash Kodi, my point is that it will crash eventually and if we are building systems for family/friends, we need to consider the outcome of a crash. What will they do? Can they ssh in to reboot it? Probably not. Can they initiate a safe shut down? No, Pi has no power button. So probably they will pull the power cord.
Then we need to consider that some hardware is more tolerant of sudden power loss. Raspberry Pi with very basic power regulation, booting from a low-grade TLC-flash SD card? I am afraid to say it will go corrupt pretty quickly. Then they will call you and say "hey, that Kodi box you built me....it seems to be 'broken' can you come and fix it?"
Again, I am not saying don't do it, but if you must choose Pi for someone else then guide them through the process of setting it up rather than do it yourself and just give them a finished system.
I don't know what you are doing to a RPi box to make it crash or whatever, but I don't have those experiences. Not in the last couple of years using Raspberry Pi's, or now during the testing of the next LibreELEC alpha/beta/stable builds. Things work fine with the official addons. If you are planning to also add the 'not so legal' addons, then yes you are on your own.
Should the bugs come from things that got altered, deleted or damaged by the user, then that's too bad. There is no real fix for stupidity. Make yourself an all-working setup on the micro sdcard, and then make a full backup of it. And if there is a problem, restore the backup.
Your experiences are not reflective of the OPs scenario because you are technically knowledgeable and by your own admission have been using/testing Raspberry Pi for years. You also presumably re-image your SD card on a semi-regular basis which masks of a lot of the corruption problems.
Remember that OP is not asking for a system for himself, he is asking to build it for someone else. If they cannot buy/build their own system, their technical expertise is probably not very high.
RPi is simply not a good choice for this scenario. It is not a stable consumer-oriented product. It is very prone to SD corruption. It doesn't even have a power button. If you build one for a non-techy person, it will crash/freeze eventually (Kodi cannot be called stable in the modern sense), they won't know how to safely reboot, they'll pull power, after they do this several times the SD card will corrupt, they'll call you to come fix it. What starts as a fun favor to someone will quickly turn into a hassle...
That's why I suggest to use something more stable, OR if you must choose R Pi, help them rather than just do everything for them and present them with a working system. This way they will learn the process to set it up and take responsibility for it's operation themselves.
I am speaking from experience of being the 'tech guy' for family and friends. What starts as a favor soon turns into an obligation or expectation, they just expect you to come over and fix stuff. how-can-i-get-out-of-being-my-familys-tech-repair-guy-or-girl