OpenELEC Testbuilds for RaspberryPi Part 2 - 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: Raspberry Pi (https://forum.kodi.tv/forumdisplay.php?fid=166) +---- Thread: OpenELEC Testbuilds for RaspberryPi Part 2 (/showthread.php?tid=184866) 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
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
|
RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Milhouse - 2013-09-01 (2013-09-01, 16:12)doveman2 Wrote: I thought when setting 128MB GPU on a 512MB RPi it automatically loaded SYSTEM into RAM but anyway, with Gotham I've been seeing around 300MB free. Can't say about the latest builds though as I've been running one a week or so old but have just upgraded to the latest so I'll check that later. Not just 128MB GPU, but yes, OpenELEC will, by default, load SYSTEM into RAM whenever it determines there is sufficient memory available (more than 102MB available, to be precise). On a 512MB Pi with 128MB GPU, there will be 382MB RAM available at boot. However I don't see a significant performance difference with SYSTEM loaded into RAM, so have opted to have more free memory by adding "noram" to cmdline.txt. If you are seeing 300MB free with Gotham, I've a sneaking suspicion you're not loading SYSTEM into RAM. A recent Gotham build (128MB GPU) with SYSTEM not loaded into RAM only has ~75MB free. If you have a file called /dev/SYSTEM then you are booting with SYSTEM loaded into RAM. RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Milhouse - 2013-09-01 (2013-09-01, 18:26)RichG Wrote: I'm running RBEJs latest Gotham build and 'top' is showing free memory of around approx 24MB after about 20hours of running. I've watched the memory usage as i've kicked of various things within XBMC, such as a backup (using the backup plugin) and playing various files and the free mem goes up and down between about 20MB and 35MB with no sign of issues, so I think this is just the Linux memory management using ram as a cache and free it up when needed. In Frodo there was always much more memory free, closer to 300MB. To go from 300MB free in Frodo, to ~36MB (or less in your case) in Gotham might suggest something isn't quite as it should be. Then again it may be down to caching, but it's still a rather large difference. I've just booted a Frodo build from 20 August, and with the XBMC GUI visible I have 325MB "free", which is 100MB more than a recent Gotham build. That alone is interesting, but could be accounted for by the increased level of caching in Gotham. However for free memory to drop as low as ~24MB (also add in the "buff" amount for the total free), which it never did in Frodo, is probably a cause for concern unless someone is able to categorically say it's not a problem. Since all the memory has been gobbled up by xbmc.bin though, it seems likely that it will be a problem, particularly when running other processes. Frodo (fresh boot, 325MB "free"): Code: Mem: 192092K used, 189912K free, 0K shrd, 29108K buff, 106332K cached Code: Mem: 347432K used, 34572K free, 0K shrd, 12076K buff, 71960K cached RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Trickname - 2013-09-01 Quote:Please test LiveTv Quote:I still can't get livetv to work correctly here too RE: OpenELEC Testbuilds for RaspberryPi Part 2 - rtenklooster - 2013-09-01 (2013-09-01, 18:44)rbej Wrote: Updated Gotham Branch Not working for me. It starts loading it says but then the screen flickers and it stops. (tvheadend) RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Milhouse - 2013-09-01 Just to demonstrate the boot memory difference between Frodo and Gotham, here's two such systems briefly playing the same HD movie, showing the free memory before/after: pastebin. RE: OpenELEC Testbuilds for RaspberryPi Part 2 - doveman2 - 2013-09-02 (2013-09-01, 22:01)MilhouseVH Wrote: Not just 128MB GPU, but yes, OpenELEC will, by default, load SYSTEM into RAM whenever it determines there is sufficient memory available (more than 102MB available, to be precise). On a 512MB Pi with 128MB GPU, there will be 382MB RAM available at boot. I do have /dev/SYSTEM and the debug OSD currently shows 296000/382000KB but free -m shows Code: OpenELEC:~ # free -m LiveTV (Mediaportal PVR) isn't working for me either on the 31/08 build and it takes a looong time to reboot or poweroff. EDIT: Reverted to the 18/08 build and both problems are fixed RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Milhouse - 2013-09-02 (2013-09-02, 01:42)doveman2 Wrote: I do have /dev/SYSTEM and the debug OSD currently shows 296000/382000KB but free -m shows When I talk about "free memory" I'm referring to the "-/+ buffers free" figure shown by the free command, which in your case is 66MB, so a lot lower than it would be with Frodo. This is the same as free+buffers from the "Mem" line above give or take a rounding difference, which should also be the same as free+buff+cached as reported by top. Ah OK, one thing I've just noticed is that "free" in Gotham is no longer reporting the cached memory amounts (see post #587 for comparison of the Frodo and Gotham "free" output). Maybe this could explain the difference, as the "buffers free" figure reported by free no longer includes cached memory when in Frodo it was included, and in fact cached memory is now treated in Gotham as a component of "buffers used" (both interpretations are technically correct, as cached memory should be made available to processes if/when required, but until then is used to improve file system performance however the method of reporting now used by Gotham is decidedly less useful). Maybe it's another kernel 3.10/procfs related change. I've updated my monitoring script to work around this difference, and will report back if the memory usage continues to appear unusual. Apologies for the (potentially) false alarm! Re: OpenELEC Testbuilds for RaspberryPi Part 2 - f1vefour - 2013-09-02 Anyone have a link for 2013.18.08 as rbej deleted it from the servers? RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Wanderlei - 2013-09-02 Dunno if its xbmc (3.0.6 official) but DTS audio I can hear a ever so faintly drop in volume for a millisecond every 10 or 15 minutes if the tv or amp decodes the audio but if I make the xbmc decode the sound is fine. I thought it might be the tv doing it when decoding audio but it occurs if the audio is passthroughed to the amp to decode as well, strange. RE: OpenELEC Testbuilds for RaspberryPi Part 2 - rbej - 2013-09-02 Updated Frodo Branch - updated FFmpeg (1.2.3) - updated firmware Fix for out of sync hdmi audio after pause Improved locking to hdmi display framerate http://netlir.dk/rbej/builds/ http://lysin.me/rbej RE: OpenELEC Testbuilds for RaspberryPi Part 2 - popcornmix - 2013-09-02 (2013-09-02, 07:38)Wanderlei Wrote: Dunno if its xbmc (3.0.6 official) but DTS audio I can hear a ever so faintly drop in volume for a millisecond every 10 or 15 minutes if the tv or amp decodes the audio but if I make the xbmc decode the sound is fine. It is impossible for xbmc to alter the volume when in passthrough mode (the encoded dts is passed through untouched). Therefore the issue is caused by the TV/receiver. RE: OpenELEC Testbuilds for RaspberryPi Part 2 - evanspae - 2013-09-02 (2013-09-01, 18:44)rbej Wrote: Updated Gotham Branch I'm affraid this build offers no improvements for me and in fact is worse than previous build ... The issue of overwriting of guisetttings on reboot still continues very problematic The new menu feature of changing pixel aspect ratio when playing a video works for video, but incorrect aspect ratio of home screen background and menu items still remain I am also not able to play broadcast .ts H264 recordings Live TV does not work I am reverting back to earlier version OpenELEC-RPi.arm-Rbej-Version-Gotham-Branch(25.08.2013).tar.bz2 hoping it wont crash! RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Wanderlei - 2013-09-02 (2013-09-02, 10:40)popcornmix Wrote:(2013-09-02, 07:38)Wanderlei Wrote: Dunno if its xbmc (3.0.6 official) but DTS audio I can hear a ever so faintly drop in volume for a millisecond every 10 or 15 minutes if the tv or amp decodes the audio but if I make the xbmc decode the sound is fine. Is it possible that it is a small gap in the audio stream being passed on not a drop in volume as such? RE: OpenELEC Testbuilds for RaspberryPi Part 2 - popcornmix - 2013-09-02 (2013-09-02, 11:07)Wanderlei Wrote: Is it possible that it is a small gap in the audio stream being passed on not a drop in volume as such? It may cause a gap in the audio, or a receiver resync. RE: OpenELEC Testbuilds for RaspberryPi Part 2 - rbej - 2013-09-02 Updated Frodo Branch http://forum.xbmc.org/showthread.php?tid=169674&pid=1497465#pid1497465 |