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
|
OpenELEC Testbuilds for RaspberryPi Part 2 - rbej - 2013-07-23 Updated Gotham Branch - updated firmware and kernel (3.10.2) - updated Xbmc 13 Gotham - new bussy spinner - avoid flushing fifos when audio/video fifos out of sync - fix the non-trivial dirty rectangle modes http://netlir.dk/rbej/builds/ http://lysin.me/rbej RE: OpenELEC Testbuilds for RaspberryPi Part 2 - matatr0n - 2013-07-23 thanks rbej for all your releases! RE: OpenELEC Testbuilds for RaspberryPi Part 2 - xbs08 - 2013-07-23 Yeah, thank you guys! RE: OpenELEC Testbuilds for RaspberryPi Part 2 - delinend - 2013-07-24 Thanks Rbej. Arr.. Can't get the NTP to Work, even when I type in a NTP server, in OpenELEC Configuration 0.1.25 :-( Any idea's ? RE: OpenELEC Testbuilds for RaspberryPi Part 2 - JoeSchmuck - 2013-07-24 (2013-07-24, 10:09)delinend Wrote: Thanks Rbej.This has been broken for me for the past 3 or 4 versions. I haven't figured a way around it. What bugs me is almost no one complaining about it so it must be working for some folks but not others. I always to a clean installation, maybe others are doing an upgrade or saving the configuration they have from a previous version and restoring it? RE: OpenELEC Testbuilds for RaspberryPi Part 2 - popcornmix - 2013-07-24 (2013-07-24, 11:19)JoeSchmuck Wrote: This has been broken for me for the past 3 or 4 versions. I haven't figured a way around it. What bugs me is almost no one complaining about it so it must be working for some folks but not others. I always to a clean installation, maybe others are doing an upgrade or saving the configuration they have from a previous version and restoring it? Yes, it's working for me, but I'm always updating from a version where ntp was working before. If anyone has this problem and can work out what the solution is, it would be helpful. RE: OpenELEC Testbuilds for RaspberryPi Part 2 - doveman2 - 2013-07-24 (2013-07-24, 11:19)JoeSchmuck Wrote:(2013-07-24, 10:09)delinend Wrote: Thanks Rbej.This has been broken for me for the past 3 or 4 versions. I haven't figured a way around it. What bugs me is almost no one complaining about it so it must be working for some folks but not others. I always to a clean installation, maybe others are doing an upgrade or saving the configuration they have from a previous version and restoring it? I upgraded from Frodo 12.1 to Gotham recently and NTP seems to be working for me, so maybe there's something left over from Frodo (on Storage) that's helping it work? MillhouseVH Wrote:Looks like it should be: Thanks but I tried WAIT_NETWORK_TIME=30 wait_for_inet_addr and it still doesn't mount for me. RE: OpenELEC Testbuilds for RaspberryPi Part 2 - doveman2 - 2013-07-24 I've been trying out some overclocks now that I seem to have got it stable at default I tried arm_freq=1000 core_freq=500 sdram_freq=600 over_voltage=6 but that hung after a small bit of linux boot text arm_freq=1000 core_freq=500 sdram_freq=500 over_voltage=6 went further but it seemed to show a lot more linux boot text than usual and ultimately hung after mounting the USB stick arm_freq=950 core_freq=450 sdram_freq=450 over_voltage=6 works OK, although I did get a phantom keypress loop almost straight away (in the shutdown menu). I've got initial_turbo=30 set, which if I recall correctly is meant to prevent the overclock from kicking in for a while during boot but I might have misunderstood. After booting and once the XBMC Home screen appears, the debug OSD shows the CPU is loaded (85%+) and the used RAM is changing rapidly for 27s before it stops and settles down to about 45%. This seems like a long time for it to stabilise and it's obviously going to be a bit laggy navigating during this time whilst the CPU is almost fully loaded already. Is this normal? I'm not doing any scans at startup or anything like that. Log here http://pastebin.com/ff9jxa9w (I pressed some buttons to mark once it had settled, at 11:48:15, which means that XBMC must have loaded the Home screen around 11:47:48) I uploaded the previous log, with Debugging disabled, here in case it's useful for comparison http://pastebin.com/DGf2xnri RE: OpenELEC Testbuilds for RaspberryPi Part 2 - doveman2 - 2013-07-24 Do core and sdram make much difference to XBMC? I understand arm is the main CPU so I'd expect that to make a difference to the speed of the GUI and doing tasks, etc but what does core do? RE: OpenELEC Testbuilds for RaspberryPi Part 2 - popcornmix - 2013-07-24 (2013-07-24, 14:14)doveman2 Wrote: Do core and sdram make much difference to XBMC? I understand arm is the main CPU so I'd expect that to make a difference to the speed of the GUI and doing tasks, etc but what does core do? core includes the L2 cache that the ARM uses, so does make a noticable difference. For arm speed, arm_freq is most important, then core_freq, then sdram_freq. RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Tander - 2013-07-24 Will update tonight and see how it goes. Thanks guys! RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Jönke - 2013-07-24 @sraue or popcormix Can you please take a look at my log http://xbmclogs.com/show.php?id=39243 Its from this build in this post http://forum.xbmc.org/showthread.php?tid=140518&pid=1468727#pid1468727 My problem is that channel change from a channel with ac3 audio to a channel with mpeg2 audio always fail. So channel change from channel with audio: Ac3->Ac3 , ok Ac3->mpeg2, not ok mpeg2->Ac3 , ok If i stop playback first mpeg2, ok RE: OpenELEC Testbuilds for RaspberryPi Part 2 - popcornmix - 2013-07-24 (2013-07-24, 19:28)Jönke Wrote: @sraue or popcormix Can you produce a sample file that shows the problem? RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Milhouse - 2013-07-24 (2013-07-24, 12:57)doveman2 Wrote: I've been trying out some overclocks now that I seem to have got it stable at default If you're bumping up your sdram_freq, you probably also want to increase your over_voltage_sdram to avoid memory corruption. RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Jönke - 2013-07-24 (2013-07-24, 19:36)popcornmix Wrote:(2013-07-24, 19:28)Jönke Wrote: @sraue or popcormix Ok maybe have to clarify that is live-tv i`m talking about. But here is 2 diffrent recording samle. One with ac3 audio and one with mpeg audio https://www.dropbox.com/sh/wazyaax5ak09044/dc8QiGQSmz |