v17 LibreELEC Testbuilds for x86_64 (Kodi 17.0) - Printable Version +- Kodi Community Forum (https://forum.kodi.tv) +-- Forum: Support (https://forum.kodi.tv/forumdisplay.php?fid=33) +--- Forum: General Support (https://forum.kodi.tv/forumdisplay.php?fid=111) +---- Forum: Linux (https://forum.kodi.tv/forumdisplay.php?fid=52) +---- Thread: v17 LibreELEC Testbuilds for x86_64 (Kodi 17.0) (/showthread.php?tid=269815) Pages:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
|
RE: LibreELEC Testbuilds for x86_64 (Kodi 17.0) - fritsch - 2016-08-26 Short term: Add more memory :-) There is a memory leak somewhere. Don't know perhaps LE wants to experience with zram :-) to at least gracefully exit / restart when kodi starts to eat memory. RE: LibreELEC Testbuilds for x86_64 (Kodi 17.0) - moontan77 - 2016-08-26 Ok thanks, was hoping somehow that kernel log pointing to source of leak RE: LibreELEC Testbuilds for x86_64 (Kodi 17.0) - Milhouse - 2016-08-26 We identified one OOM starting with build #0807 (it happens real quick on an RPi!). It's triggered by seeking when passthrough is enabled. There are a couple of audio-related PRs in #0807 that might be responsible: http://forum.kodi.tv/showthread.php?tid=269814&pid=2398048#pid2398048 RE: LibreELEC Testbuilds for x86_64 (Kodi 17.0) - Milhouse - 2016-08-26 (2016-08-26, 20:35)jan-g Wrote: @ Milhouse/Fritsch We switched to the newer 4.7 "schedutil" governor in the 4.7.2 bump (introduced build #0823), I wonder if that's causing more sluggish performance than the older ondemand governor? https://github.com/LibreELEC/LibreELEC.tv/pull/653/commits/910a3f1b904b26c535e1826f0987268b3e128336 I will revert the governor change in tonigh'ts build - let me know if it's worse/same/better. RE: LibreELEC Testbuilds for x86_64 (Kodi 17.0) - wizziwig - 2016-08-26 (2016-08-26, 19:41)fritsch Wrote: I think you should go the Ubuntu route for debugging this - I can build you whatever kernel you want, after you are ready and working with: http://forum.kodi.tv/showthread.php?tid=231955 Thanks for trying to help. I figured Ubuntu would have been the best approach as well. Unfortunately, the little mini-pc that I have hooked up to the buggy TV has very little storage (30GB SSD) that is mostly occupied by Windows 10. I was booting LibreElec from USB flash drive. I"ll try to figure something out to get more space on there. I've been running Ubuntu from a VirtualBox image on another PC in order to make my own LibreElec builds for testing. I was able to successfully test a few of my own ideas as well as some patches from Intel. Intel's patches didn't help (other than turning off 36-bit color support which I can easily do via custom EDID).. My own code changes did fix the audio bug with 36-bit color still enabled but left other issues that still need to be resolved (a/v clock mismatch causing frame skipping). I've dealt with HDMI configuration bugs on another embedded platform but the Intel hardware is a bit different and more complicated because of multiple pipes (HDMI, DP, etc.). Hardware documentation is also poor. I think the main reason many Intel bugs don't get fixed for years is because the end-users who report them are usually not developers and can't verify fixes. Building custom kernels, etc. is too much for most people so they just give up after reporting the bug. RE: LibreELEC Testbuilds for x86_64 (Kodi 17.0) - Milhouse - 2016-08-27 New LibreELEC.tv Krypton build #0826: Generic (Supercedes previous build) Code: # uname -a Based on tip of LibreELEC.tv master (a0e32078, changelog) and tip of XBMC master (a56be148, changelog) with the following modifications:
RE: LibreELEC Testbuilds for x86_64 (Kodi 17.0) - Milhouse - 2016-08-27 (2016-08-26, 20:35)jan-g Wrote: @ Milhouse/Fritsch Please compare #0823, #0825 and #0826 and see which you prefer. RE: LibreELEC Testbuilds for x86_64 (Kodi 17.0) - mglae - 2016-08-27 (2016-08-26, 22:28)Milhouse Wrote: We identified one OOM starting with build #0807 (it happens real quick on an RPi!). It's triggered by seeking when passthrough is enabled. There are a couple of audio-related PRs in #0807 that might be responsible: http://forum.kodi.tv/showthread.php?tid=269814&pid=2398048#pid2398048 Reverting - VideoPlayer: passthrough fixes (PR:10247, 1 commit, 1 file changed) fixes the OOM in my private LE build. RE: LibreELEC Testbuilds for x86_64 (Kodi 17.0) - fritsch - 2016-08-27 @wizziwig: Please check the nightly build, milhouse included the 8bpc patch chris wilson posted. RE: LibreELEC Testbuilds for x86_64 (Kodi 17.0) - jan-g - 2016-08-27 (2016-08-27, 00:15)Milhouse Wrote:(2016-08-26, 20:35)jan-g Wrote: @ Milhouse/Fritsch definitely #0826, speeds are back to normal. just to give you an idea about the speed differences, #825 15 sec. to bring up my Movie Db, vs #826 11 sec. (big Db 14K+) #825 4 sec to bring up LE configuration, vs #0826 less than a second. interesting reading about "Schedutil" and :p-states", as I understand it, if the "CPUFreq governor, Schedutil" isn't enabled, then the "Intel P-State CPU frequency scaling driver" is at play. While Schedutil is actively throttling my ancient (6 years+) Atom d525, p-state freq scaling has no effect on performance (isn't .throttling the freq.) Seeing that Scheduti is doing an overall better job than p-state, it's only a matter of time it will be activated in the kernel. So the big question is will Schedutil be always activated or is on demand activated the default. RE: LibreELEC Testbuilds for x86_64 (Kodi 17.0) - fritsch - 2016-08-27 p-state is not used on your Atom at all. And btw: Reverted: [env] PR:Commit:910a3f1: Generic/RPi2: Switch to schedutil CPUFreq governor (reverted: might result in sluggish performance) <- he reverted the schedutil change, which means p-state / or ondemand or whatever should be active for you again. RE: LibreELEC Testbuilds for x86_64 (Kodi 17.0) - Milhouse - 2016-08-27 What is your default governor in #0826, is it "ondemand" or "performance", or something else? Check with "cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor". It should be "ondemand", but my Revo (Atom D525) is using "performance" even though the default governor is configured as "ondemand". A Skylake-based NUC uses exclusively P-States rather than "schedutil" (when enabled) and enabling "schedutil" support should have no effect on more recent Intel hardware (as it will be ignored). So if your hardware supports P-States then you'll use P-States as your governor. Otherwise your hardware will use CPUFreq "schedutil". You can always change the governor by writing a value ("ondemand", "performance", "powersave") to "/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor", eg. "echo ondemand > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor". This could be added in autostart.sh if you prefer that governor, although if schedutil is resulting in more sluggish performance then we can consider dropping it (though in theory, this shouldn't be the case). RE: LibreELEC Testbuilds for x86_64 (Kodi 17.0) - Milhouse - 2016-08-27 schedutil change is now dropped. RE: LibreELEC Testbuilds for x86_64 (Kodi 17.0) - jan-g - 2016-08-27 (2016-08-27, 12:21)Milhouse Wrote: What is your default governor in #0826, is it "ondemand" or "performance", or something else? Check with "cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor". it's performance. I believe an ancient D525 has no advanced power savings whatsoever and as it has a Tdp of 14W there's no real need for it.. and if "schedutil change is now dropped" I'm a happy camper again. thanks. RE: LibreELEC Testbuilds for x86_64 (Kodi 17.0) - Milhouse - 2016-08-27 We'll try again with schedutil in 4.8. |