I’ve already reported on the problem of the unusual lag time associated with skipping forward or back in a video in another thread. In this thread I’ll mention all of the other issues, big and small, that my testing of 8.95.006 over the last day or so has revealed.
From my perspective there are two serious problems, and also four minor ones…
(CoreELEC-specific) – Video calibration settings are not preserved across power cycles. This problem is apparently independent of the skin being used. This problem is not present in LibreELEC 8.95.005 for/on x86. (This is important for people like me who, sadly, have flatscreens with built-in overscan that cannot be disabled.)
(LibreELEC/CoreELEC) – Starting up play for DVD ISO rips is annoyingly slow for non-local media. My setup is as follows: FreeBSD server running NFS and exporting volumes containing DVD ISO rips to local network. This equipment is in one room along with an ASUS RT-AC56U which speaks to a Linksys WUMC710 (on 5MHz) which is one wall and about 15 feet away. The WUMC710 is in turn hardwired to Beelink Mini MX III and/or x86 HTPC (Zotac Zbox BI320). This WiFi connection has been clocked using iperf at over 230Mbps, and is very stable. Exported NFS volumes are mounted to the LibreELEC/CoreELEC boxes using Kodi’s in-built NFS. When using my ancient version of OpenELEC (v5.0.8 / Kodi 14.2) startup for DVD ISO rips residing on the NFS remote volumes is essentially instantaneous. Likewise, when using recent vintage beta versions of both LibreELEC (on x86) and CoreELEC (on AML S905) along with locally connected external USB media, startup when playing DVD ISO rips is near instantaneous. The problem arises only with recent vintage LibreELEC/CoreELEC (8.95.005/8.95.006 respectively) when playing DVD ISO rips present on remote mounted NFS volumes via the setup described above. In this case, starting up the playback of an NFS-mounted DVD ISO rip results in a lag time of as much as 30 seconds, for the x86/LibreELEC case, and as much as 47 seconds for the CoreELEC/S905 case. These startup delays are both noticeable and annoying, and are clearly a regression relative to earlier versions. (I will of course be reporting this issue also to the LibreELEC folks.)
(LibreELEC/CoreELEC) – Power off is very slow. My ancient copy of OpenELEC (5.0.8) powers off on my x86 box is just a second or two. Power off using LibreELEC 8.95.005 on the same box now takes as much as 21 seconds. Power off of my Beelink Mini MX III using CoreELEC 8.95.006 takes as much as 15 seconds before the box actually powers off. This is clearly also a regression, as least relative to the ancient version of OpenELEC that I have been using.
(CoreELEC) – Just after I had adjusted the Timezone Country in the menus, the system sort of went bonkers. The screen blinked repeatedly and I heard the “wisking” sound-effect repeatedly, as if I was holding down some remote control button, which I wasn’t. Fortunately, this only lasted for about 15-20 seconds. Before I could even reach over to pull the power cord, it stopped, and the system behaved entirely normally thereafter. (I am guessing that this was some sort of a difficult-to-reproduce timing issue, aka a “fluke”, that may not be easily reproducible, but I felt that I should report it anyway.)
(LibreELEC/CoreELEC) – I use the Confluence skin. Always have and always will. It used to be the case that from any position on the main bar of the main (home?) menu on Confluence, it was possible to click down twice and thus get the power options button highlighted. It now appears that some clever fellow decided to change this traditional behavior for no apparent reason, other than to mess with people who have been accustomed to this interface for years already. Now, going down twice highlights the star button in the lower left hand corner. I have never even known what that button was for (and never had a reason to care) so I clicked on it. After that, the right 1/3 of my screen was overlaid with darkness. Maybe this is useful in some obscure way, but I really wish that people/developers would refrain from diddling things in the interface unnecessarily. It’s like as if someone decided to switch the locations of the brake and gas pedals in your car. Who thought that this would be a Good Idea?
(CoreELEC) – When the power options button is clicked in the home screen for the current skin, on LibreELEC the result is what it has always traditionally been, i.e. the power options menu comes up with “Power Off” already highlighted. In CoreELEC, the power options menu come up alright, but nothing is pre-selected. I hope that this cane be reverted to the previous and traditional behavior (of pre-selecting Power Off).
The first two issue above are deal-breakers for me, and I plan to continue using my crusty old (but trustworthy) OpenELEC 5.0.8 until these issues/regressions get fixed. The other four issues described above are only minor quibbles, but as I am not able to devote time to helping do any development on any *ELEC I felt that the lest I could do to help out would be to write this testing report and mention everything odd that I saw.
Sorry to follow-up on myself, but I just realized that I left out one detail regarding issue #2 – the slow start-up when playing non-local DVD ISO rips – and this detail may perhaps be important.
In the case of my ancient OpenELEC that I’ve been using on my x86 HTPC, I had configured the underlying Linix OS to do the NFS mounts. Perhaps that has something to do with why that’s so fast. Perhaps the real problem here is that Kodi’s in-built NFS implementation is not so hot, and perhaps it is what is slowing things down.
This is a known issue, but I don’t think it has been thoroughly investigated, yet. Search the forum, there are a couple of threads about it.
Can’t help with this one. I’m using FTP shares, and don’t have any issues browsing anything, but I don’t have any ISO rips. It’s also very likely that this is a Kodi issue. I suggest you double check with Windows/desktop Linux Kodi.
Ancient OpenELEC probably uses a much older kernel. It’s possible that fixes/additions/other changes over the years have made it shut down slower. I never timed this, but I don’t see how this is a real issue.
Probably a fluke, if it can’t be reproduced consistently.
The default button when clicking down is a skin change, it’s out of our control, and isn’t even Kodi related per-se. You can change it back if that bothers you so much. Undo the change in this PR: https://github.com/xbmc/skin.confluence/pull/32
If you use Live TV or use CE for music, you might want to update to the latest version of the skin. Just download as zip from github, and install it manually.
I don’t have that problem with neither Confluence nor Estuary. After a clean reboot Power off system is selected.
Well, it seems that my supposition was correct. There’s something… some aspect of Kodi’s in-built NFS implementation… that just doesn’t play well with DVD ISO rips.
I just now tried the same tests using the OS-level NFS mounting process described here and instead of taking over 30 second to start up playback, it takes between 2 and 4 seconds, depending on the specific ISO involved.
I guess I’ll have to report this formally to the Team Kodi. An order of magnitude difference in performance between their built-in NFS implementation and Linux’s is a bit too much to ignore.
One comment about 1.:
What TV model do you have?
Almost all tv’s have this option and sometimes it difficult to find it. And you need to change it sometimes for each resolution and each refresh rate.
Calibration is OK for non digital connection, but use it for hdmi is not good
Regarding your NFS problem… there is a dedicated NFS add-on. Try with and without it to see if that makes any difference. Also, your server, do you use NFS 2 or 3? TCP or UDP? What blocksize?
Yes. Sorry. I misspoke. I have been testing with CoreELEC 8.95.3 (verified) and LibreELEC 8.90.005 (verified).
Losing the video calibration across power cycles is a definite CoreELEC-specific bug, and yes, several others have reported it also. In my testing, this bug is not present in LibreELEC 8.90.005. (Is there an official CoreELEC bug tracker someplace that I should be creating a formal bug report on? If so, and if someone would kindly direct me to that…)
As I now know, the slow start-up when playing DVD ISO rips is due entirely to Kodi’s built-in NFS client, which is apparently highly sub-optimal, relative to the one in the Linux kernel. I will be mentioning this to the Kodi folks. Until it this gets fixed I will certainly not be using Kodi’s built-in NFS client and will instead be using actual Linux NFS mounts, which are apparently dramatically more efficient, at least in certain specific instances.
The slow power-off issue is just a minor nit, but I will mention it to the LibreELEC folks, as this issue seems to affect LibreELEC also. (Obviously, this is a totally minor issue.)
This was apparently a one-time fluke. I cannot reproduce. Thus I just chalk it up to “sunspots”.
Yes. Somebody on Team Kodi apparently decided that this new behavior is friendlier than the original behavior. There’s no accounting for taste. Thanks for letting me know.
I just saw this again, but sometimes it happens and sometimes it doesn’t. I’ll try to pin down what causes it to happen and/or what causes it not to happen. In any case, it is a totally minor and insignificant issue.
Now that I have a simple work-around for the slow-NFS issue, there are really only two things keeping me from dumping my x86 HTPC and switching over to the S905/Beelink with CoreELEC:
a) Loss of video calibration across reboots / power cycles. (Yes, the calibration is lost across both power cycles and simple reboots. I just checked.)
b) The approximately 1.5 second stall that occurs just after skipping forward/back while playing essentially any video of essentially any type.
Neither of the above two problems are present in LibreELEC 8.90.005 on x86.
I will file formal bug reports on both of these if someone will just kindly point me at the place where I should do so.
I’ve also noted very slow KODI shutdown across all OS’es in the last few nightlies. Could be anything from hanging worker threads to database queries, unfortunately, and thus difficult to debug.
I’ve got stuff going on with the kids tonight, however…
The overscan issue. There are a couple ways to adjust the overscan and preserve it across power cycles. I should have time tomorrow to either write an easy to follow howto guide / and or fix the existing functionality of the video calibration.
The shutdown issue. I believe is an issue with kodi.
The TV is a Panasonic TC-P50X60. Manufacture date June 2013. I got this dirt cheap from BestBuy a few years ago. They had discounted it heavily to try to get rid of it. This was the very last plasma ever sold by my local BestBuy. After that, everything they sold was and has been LCD/LED/OLED, etc. (Plasma is dead! Long live plasma!)
Anyway, trust me, I have been around and around and around on the overscan issue with this TV, and seriously, it cannot be disabled. (It does a 2.5% overscan on each edge, top, bottom, left and right.) This was a “budget” model Plasma from Panasonic, and some nitwit engineering manager @ Panasonic thought that a good way to make a budget model to complement the rest of their lineup was to take one of their normal models and just willy-nilly start hacking off certain parts of the firmware. So they hacked out the “feature” of being able to disable the overscan, and also, they hacked out the menu item that let the user set the timezone. Thus my TV is perpetually in EST/EDT even though I am in PST/PDT. It’s not an issue unless I am using the TV’s built-in tuners, which I never do. (I have a Tivo.)
Everyone who is in favor of sending idiot engineering managers to GitMo please raise your hand.
Also, your server, do you use NFS 2 or 3? TCP or UDP? What blocksize?
rpcinfo shows that my NFS server supports both NFS 2 and NFS 3. I do not know how to find the answers to your other questions. If you instruct me how to do that, I will find the additional answers and report back.
I reported something similar quite some time ago, and have since decided through testing that it is a Kodi shutdown issue. This might well be a result of the newer Kodi requiring a longer time to shut down.
My server (8.95.3), with Kodi disabled, shuts down very quickly, but the client machine takes a much longer time. Both are Tanix Tx3 mini.
Maybe test shutting down Kodi first to see how much time that takes?
I will add my own emphasis on the video calibration settings not being saved. This is an important bug and i dont understand why the developers arent addressing it after so many people have reported it. YES i know there are workarounds with the tv settings but they are workarounds: the bug is still a bug.
One important bit of information about this bug: only the 60Hz video calibration settings are lost after reboot. All the others are saved ok. So RonBaby, you might try using any othe other resolutions as the default of the GUI. Even the 59.9 works ok.
That being said if you can’t get your display to not apply an overscan, and you have the same overscan on all sides, you can also use settings/interface/zoom to make the gui fit within the visible area on the screen.
Go to Settings/System/Display: Select refresh rate = 60Hz
Go to Video Calibration: Make any change. For example change subtitle position from default of 1042 to 1000.
Reset Box, go to video calibration: Whatever changes you made are lost
However if in first step you select another refresh rate, e.g. 24Hz or 59.9Hz, then after reset the changes are not lost.
I don’t think this will be fixed in the nightly builds if the developers don’t acknowledge the existence of this bug. The bug has existed since the beginning of CoreElec.
Ok, well I did set 60Hz in my tests. I actually tried this multiple times, with each refresh rate. Same results each time.
I bumped the edges in by 50px and put the sub titles up the screen and it stayed that way after a reboot.
Only difference with my setup is I’m using a 720p display. I’ll grab another sd card, do a fresh install and try it on a different display so I can try different resolutions as well.
