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 - popcornmix - 2013-12-26 (2013-12-26, 20:24)xbs08 Wrote: Could the mce be sending input signals much to fast for the rpi to keep along? Not really. The architecture of the xbmc gui means that the scrolling speed is fixed (although influenced by the remote), and cover art is decoded asynchronously and displayed if ready in time. It depends on the library display mode you are using whether the jpegs will show when scrolling fast. I find I can scroll at full speed in fanart view, and every cover is visible (but not the larger fanart backgrounds). The "wall" views tend to show some covers. Some of the views with lots of text (e.g. low-list I think), I see no covers. If you reduce the resolution of the cached artwork, you'll have a better chance of seeing more. The artwork should appear soon after stopping, or when scrolling slowly. This is all normal and occurs on all xbmc platforms. A really fast PC with fast disk may be able to show every cover and fanart, but if it doesn't keep up then that's not a problem. RE: OpenELEC Testbuilds for RaspberryPi Part 2 - xbs08 - 2013-12-26 Yes, using fanart view, artwork appears as soon as scroll stops and fanart loads instantly also after that. This is not really a problem it's just that I find it a "bit odd" that the artwork doesn't "act" the same depending on the remote used. No biggie thanks for your time and explanations. RE: OpenELEC Testbuilds for RaspberryPi Part 2 - ntadej - 2013-12-27 (2013-12-26, 14:45)popcornmix Wrote:(2013-12-26, 11:34)ntadej Wrote: My 1080i channels via tvheadend are still detected as 4K and not playable every time. I can provide a sample recording of one of those channel if it helps. (Not sure if it is related to Raspberry Pi or general XBMC.) I've updated tvheadend to latest version and there are no improvements, just size seems to be detected correctly. I have a sample recording for 1080i channel that fails (fails playing live or recording). http://tano.si/tmp/xbmc/hdsample.mkv RE: OpenELEC Testbuilds for RaspberryPi Part 2 - tuxen - 2013-12-27 (2013-12-23, 17:38)TBCdevil Wrote: @tuxen very good info. Looks like local USB drives are best avoided for proper use. Sorry I think you missed the point. Which is Database writes or random small writes. I'd sacrifice 25 Mhz over the added database write speed in a heartbeat. And I had to clock down no matter if I used a 1.8" hdd as now or a USB 3 stick, USB 2 was slow at database writes, 3 faster, but the 1.8 hdd the fastest so I choose that. Its over 100 percent extra performance when measuring db operations, the 25Mhz you will never notice. Samba from a PC to RPi is also extremely fast 7-8 MB/sec when mounted as a windows drive. All my movies are on the drive so 2watt and a self powering down hdd is surely better than sharing from a noisy power hungry PC? Uses less power than a NAS even. But thanks RE: OpenELEC Testbuilds for RaspberryPi Part 2 - tuxen - 2013-12-27 (2013-12-23, 19:48)allan87 Wrote:(2013-12-23, 10:54)tuxen Wrote: but it says a lot about where the bottleneck lies; the sdcard memory technology so anything that can speed this up without breaking any stability is more than welcome IMHOMy own experience with a class 10 card v. USB was different. I could not discern any difference in the speed of the interface between the two (navigating was very acceptable in both). If you read my post you will see that on 512MB boards and gpusplit of max 132MB the operating system plus openELEC is running completely from ram so GUI performance and likes are the same. Furthermore if you have a bigger gpusplit and its loaded from the sdcard you still won't see much difference because the SYSTEM is read only again no write operations can take place in system. But I'm not talking about sequential read speed here, its pretty equal. I'm not talking about overclocking either. I know i mixed it a bit together but I'm talking about write operations exactly as documented here with fs2fs. I'm saying in my experience a modern USB 3 stick or harddrive will give you the same or higher small READ/WRITES to the database(s) a tremendous boost in write rates than ext4 on any sdcard STORAGE partition. The storage PARTION is write able and holds your databases, again I'm not saying the GUI will fly but depending on what addons you use and you library operations in most cases the system overall will seem faster. If just using a simple addons without metadata such as xml lists or naviups, or another simple listings addon with no metadata or fill your library with a new tv-shows I agree not much speed can be gained switching to a faster storage media. Apart from the overclock trick some use because they have corruption with their sdcard at to high speeds. And I totally agree with you on the sdcard's plus specific pi can lead to corruption. I'm highly aware of the experiences some have. Believe me I fiddled around with this issue ALOT I think I tested 50+ sdcard's and 50 USB sticks. Ofcause there where bad apples (needed squeezing or adjustment) and one even seemed to burn out, but the majority had no corruption errors at all so ofcause I chose a few of them (only around 7 where dodgy and some same as fully working ones). I would choose another path though if I had the problem and clock down until the sdcard was stable to. But overclocking away, speed won't matter much if you use USB 2 memory sticks no, because the rely on almost the same memory technology as sdcard's. Move to a good USB 3 stick (closer to SSD technology) or a harddrive and database operations will be insanely faster, as high or higher than the numbers we see with f2fs. I have plenty of data to support this if it can be of any help? I work at a place where they produce these things for other labels. Hence the abundance of components. RE: OpenELEC Testbuilds for RaspberryPi Part 2 - tuxen - 2013-12-27 (2013-12-26, 20:24)xbs08 Wrote: Just tried gpu_mem 136M (CPU gets 111M) and it seems to have a positive effect during fast scrolling. I can scroll as fast as I like and the fanart is already loaded, again storage db operations moved to a small iPod HD 1,8". For example if I press page down 1 or 10 times in a row, all fanart and covers for next page are already loaded?! OpenELEC 3.2.4, result has been the same since before 3.0. RE: OpenELEC Testbuilds for RaspberryPi Part 2 - tuxen - 2013-12-27 (2013-12-25, 05:22)maratonomak Wrote: How about an advancedsettings.xml for the best performance ?Its already included in your image, look in /usr/share/xbmc/system/ this advancedsettings.xml is trimmed for the release and is loaded before the /userdata/ advancedsettings.xml file. Any changes to existing settings or adding of settings is loaded afterwards and will be appended or changed to the value set in the /userdata/ file. Rbej has a very few extra options you probably want to set but otherwise I recommend don't create it if you do not need it, again one is already provided. Check your logfile to help see how it works. (2013-12-24, 22:18)sraue Wrote: a bit OT: :-) Thanks and merry Christmas to you Stephan. And ofcause a big thanks for the best media center software solution out there from me and everyone I personally know who tried it. RE: OpenELEC Testbuilds for RaspberryPi Part 2 - tuxen - 2013-12-27 xbs08: ahh.. how odd. RE: OpenELEC Testbuilds for RaspberryPi Part 2 - postdeath - 2013-12-27 F2FS on my USB was amazing for the first few days, but my OpenELEC is at a complete crawl at the moment, it's a nightmare to use. RE: OpenELEC Testbuilds for RaspberryPi Part 2 - xbs08 - 2013-12-27 Just lost my settings (F2FS) when RPi hanged RE: OpenELEC Testbuilds for RaspberryPi Part 2 - postdeath - 2013-12-27 (2013-12-27, 20:22)xbs08 Wrote: Just lost my settings (F2FS) when RPi hanged I'm getting that a lot - I backed up guisettings.xml to the desktop and copy it back over whenever it screws up. Edit: What is the easiest way to back up my USB in Windows without making an image of the drive? RE: OpenELEC Testbuilds for RaspberryPi Part 2 - xbs08 - 2013-12-27 If you just want the xbmc instalation use winscp and backup .xbmc folder. There's also a xbmc backup addon that I ran every week. RE: OpenELEC Testbuilds for RaspberryPi Part 2 - maratonomak - 2013-12-28 (2013-12-27, 17:03)tuxen Wrote: How about an advancedsettings.xml for the best performance ?Its already included in your image, look in /usr/share/xbmc/system/ this advancedsettings.xml is trimmed for the release and is loaded before the /userdata/ advancedsettings.xml file. Any changes to existing settings or adding of settings is loaded afterwards and will be appended or changed to the value set in the /userdata/ file. Rbej has a very few extra options you probably want to set but otherwise I recommend don't create it if you do not need it, again one is already provided. Check your logfile to help see how it works. MashUp has the option to add Tuxens advancedsetting along with Mikey1234 and 0 cache advancesetting.xml. I'm currently using Rbej's, but i've tried the other 3 as well. I can't notice any difference . Currently I'm on Rbej's build (Frodo) using his advancesettings.xml. Just trying to improve as much as I can Thank you ! RE: OpenELEC Testbuilds for RaspberryPi Part 2 - allan87 - 2013-12-28 (2013-12-27, 16:34)tuxen Wrote: But overclocking away, speed won't matter much if you use USB 2 memory sticks no, because the rely on almost the same memory technology as sdcard's. Move to a good USB 3 stick (closer to SSD technology) or a harddrive and database operations will be insanely faster, as high or higher than the numbers we see with f2fs.Are you saying that, as a class, usb3 sticks have faster memory? If not, I don't see how there would be a benefit over USB2, as the pi' USB interface is usb2, so the faster interface would not help. RE: OpenELEC Testbuilds for RaspberryPi Part 2 - User 186112 - 2013-12-28 (2013-12-28, 05:52)allan87 Wrote:USB 3.0 sticks have much faster memory and controllers. Even in usb 2.0, they are faster then regular usb 2.0 sticks.(2013-12-27, 16:34)tuxen Wrote: But overclocking away, speed won't matter much if you use USB 2 memory sticks no, because the rely on almost the same memory technology as sdcard's. Move to a good USB 3 stick (closer to SSD technology) or a harddrive and database operations will be insanely faster, as high or higher than the numbers we see with f2fs.Are you saying that, as a class, usb3 sticks have faster memory? If not, I don't see how there would be a benefit over USB2, as the pi' USB interface is usb2, so the faster interface would not help. I noticed noticeble speedups in using xbmc using a ext4 formatted 16GB usb 3.0 Sandisk Extreme stick. |