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 - 2014-01-31 (2014-01-31, 01:01)cognitive alien Wrote: I'm new to this but looks like something weird with lircd hogging loads of cpu How do you know it's lircd hogging the cpu? Make sure you don't have any scrolling text on the display, that will keep the CPU busy. (2014-01-31, 02:01)sunwarming Wrote: The other issue is when a menu or something in loading in openelec in the bottom right corner comes up "Processing" or "working" and a white wheel comes up next to it, but the wheel isn't moving like in xbmc 12. It is static and looks like the PI has frozen, but it hasn't in reality. See here. There is a solution, to use an animated GIF, but the OpenELEC build system doesn't play nice with binary patches so for the time being (as this is a development build, and a working spinner isn't something I consider critical, given the alternative) I've just disabled the CPU-intensive animation in my builds. RE: OpenELEC Testbuilds for RaspberryPi Part 2 - delinend - 2014-01-31 (2014-01-31, 04:16)tuxen Wrote: Just a thought; are you sure your laptop can output 25p? Not many gfx cards can. Hi tuxen. Yes, my laptop is a Lenovo X1, with an onboard Intel HD Graphics 3000. And no problem to select 24 and 25p output on it. But I can only select this in 1920x1080 resolution. Not in other resolutions :-) RE: OpenELEC Testbuilds for RaspberryPi Part 2 - delinend - 2014-01-31 Thanks to @popcornmix and @Milhouse The new r17182 works flawless, on all my framerate content now :-) RE: OpenELEC Testbuilds for RaspberryPi Part 2 - tuxen - 2014-01-31 Edit: ups things move fast here.. (2014-01-31, 05:36)nola mike Wrote: Kind of a dumb question, but I'm trying to use stable releases the easy way--saw that I can just dump the tar file in the .update folder, but I can't seem to find it?http://wiki.openelec.tv/index.php/Updating_OpenELEC You have to extract the .tar and put the files from the folder "target" to the folder ".update" on openELEC and reboot. 7zip, winrar, tar , etc can extract the files. You should be able the reach .update via. Samba \\openelec\update or using winscp, make sure display hidden files is enabled if using the latter. If you still can't find it create it "mkdir /storage/.update" via ssh or use winscp again. A . in front of the file/folder means that its hidden, so a normal "ls" won't list it, you can you the option "ls -a" to display it. Hope you got a few general pointers. RE: OpenELEC Testbuilds for RaspberryPi Part 2 - cognitive alien - 2014-01-31 (2014-01-31, 05:41)MilhouseVH Wrote: Load average: 5.35 5.02 3.36 3/96 403There you go tried to sort out the formatting better I saw a constant 100% cpu on screen usage, went to PC, putty in, did top and lircd is using 72.2% cpu, rebooted and it went back to normal I got a few PIs and just started overclocking etc so will do some more testing over the weekend Quick q for the gurus, I got a few folders which contain ripped DVDs ie lots of different files in there, how can I configure to just 'play the folder'? Or another workaround? Cheers PS formatting still not right, doing my head in now lol RE: OpenELEC Testbuilds for RaspberryPi Part 2 - sunwarming - 2014-01-31 (2014-01-31, 05:41)MilhouseVH Wrote:(2014-01-31, 02:01)sunwarming Wrote: The other issue is when a menu or something in loading in openelec in the bottom right corner comes up "Processing" or "working" and a white wheel comes up next to it, but the wheel isn't moving like in xbmc 12. It is static and looks like the PI has frozen, but it hasn't in reality. Thank you for the answer! I'll leave it as you have configured it, it's better to have a good performance from the PI than having a wheel turning. Thanks! RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Milhouse - 2014-01-31 (2014-01-31, 12:19)cognitive alien Wrote: I saw a constant 100% cpu on screen usage, went to PC, putty in, did top and lircd is using 72.2% cpu, rebooted and it went back to normal That's not lircd, that's xbmc.bin. Any number of things could cause xbmc.bin to consume CPU - an addon running in the background, or text scrolling in the GUI, are typical causes of high CPU. PS. Use code tags. RE: OpenELEC Testbuilds for RaspberryPi Part 2 - cognitive alien - 2014-01-31 (2014-01-31, 12:39)MilhouseVH Wrote:(2014-01-31, 12:19)cognitive alien Wrote: I saw a constant 100% cpu on screen usage, went to PC, putty in, did top and lircd is using 72.2% cpu, rebooted and it went back to normal well this is a fresh install so could it be the 'news' scrolling at the bottom of the screen and how do I inhibit it? yes sorry about code tags, was in a hurry to try and condense the post, doh RE: OpenELEC Testbuilds for RaspberryPi Part 2 - xbs08 - 2014-01-31 IMO rpi builds should come with RSS disabled by default. http://wiki.xbmc.org/index.php?title=RSS_ticker RE: OpenELEC Testbuilds for RaspberryPi Part 2 - popcornmix - 2014-01-31 (2014-01-31, 13:06)xbs08 Wrote: IMO rpi builds should come with RSS disabled by default. IMO it should. I submitted a PR with this change in, but it wasn't accepted. sraue (openelec maintainer) was against it, as openelec has a custom RSS feed. I use an advancedsetting.xml (with MySql settings in), so I just add: Code: <lookandfeel> and no RSS (you don't even get the option in the gui). RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Milhouse - 2014-01-31 (2014-01-31, 12:59)cognitive alien Wrote: well this is a fresh install so could it be the 'news' scrolling at the bottom of the screen and how do I inhibit it? yes sorry about code tags, was in a hurry to try and condense the post, doh System -> Settings -> Appearance -> Skin -> Show RSS news feeds [enable/disable] (2014-01-31, 13:06)xbs08 Wrote: IMO rpi builds should come with RSS disabled by default. What's actually quite bad is that the default Settings level of "Basic" doesn't allow the RSS feed to be disabled - the user has to switch to Standard level first, then the "Show RSS news feeds" option becomes visible. I would be content to leave RSS enabled by default on the Pi assuming the GUI setting to disable it is visible by default (it's easy enough to change), but hiding this option is just going to lead to a lot of unnecessary grief for first-time users. Really bad decision IMHO. (2014-01-31, 13:32)popcornmix Wrote: IMO it should. I submitted a PR with this change in, but it wasn't accepted. That's unfortunate, and I really can't see the logic of imposing the RSS feed on users when it impairs the user experience to such an extent that the first thing any user will do is switch it off. But now with the option being hidden by default it's going to result in a lot of new users having a really poor experience, and not knowing how to resolve it. That makes absolutely no sense to me, and it's not in OpenELECs interest either as users will blame OpenELEC for the awful performance, and maybe switch to a different distribution, or blame the Pi and buy more expensive hardware (or give up entirely). (2014-01-31, 13:32)popcornmix Wrote: I'll probably drop this into the next release. It's not really something I want to do, as when the user returns to stock releases they'll be faced with the RSS feed again, but it may be better than nothing. RE: OpenELEC Testbuilds for RaspberryPi Part 2 - RichG - 2014-01-31 I often come across posts by people who have tried OpenElec on the Pi and found the performance to be too poor. I'm sure quite a few of these bad experiences will be down to this crazy RSS feed. Unfortunately, to a new user it's not going to be at all obvious why or how to 'fix' it. I too think this should be disabled by default. RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Milhouse - 2014-01-31 (2014-01-31, 14:03)MilhouseVH Wrote: What's actually quite bad is that the default Settings level of "Basic" doesn't allow the RSS feed to be disabled - the user has to switch to Standard level first The RSS option should be visible for all setting levels in future builds. That's half the problem solved... RE: OpenELEC Testbuilds for RaspberryPi Part 2 - LehighBri - 2014-01-31 (2014-01-28, 00:53)popcornmix Wrote:(2014-01-28, 00:25)LehighBri Wrote: Nailed it! I just tried millhouse's latest build in the next post that includes this fix and EDL support works again in omxplayer. Man you're fast... thanks so much for this. Really appreciate the attention to this. So that solves my issue... maybe allen87 should try this too?? Thanks again popcornmix. Are there any plans to submit an official PR to XBMC to get this out of newclock3 and into the XBMC master branch? It's by no means critical, just curious. RE: OpenELEC Testbuilds for RaspberryPi Part 2 - popcornmix - 2014-01-31 (2014-01-31, 15:45)LehighBri Wrote: Thanks again popcornmix. Are there any plans to submit an official PR to XBMC to get this out of newclock3 and into the XBMC master branch? It's by no means critical, just curious. Yes. Merge windows are first ten days of each month, so starts tomorrow. I'll go through newclock3 and submit PRs for any confirmed improvements. Technically this EDL one is a bug fix, so could be accepted outside of a merge window. Should be submitted within new few days. |