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-22 (2013-12-21, 21:01)postdeath Wrote: Is anyone else seeing Pi lockups after leaving video on pause for an extended (15min+) length of time? If it is streaming from an internet site, then it will be too high a cache buffer. The cache keeps expanding while paused and you will crash when memory is exhausted. RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Cy4n1d3 - 2013-12-22 I'm playing local files here, it also doesn't matter if it's 720p, 1080p, DTS, AC3. The last lines in log before crash are: Code: 11:55:48 276.983948 T:3044516368 DEBUG: OnKey: 230 (0xe6) pressed, action is Pause What's interesting though: it's not the whole RPi crashing, it looks more like a 'hotboot' where only the xbmc interface gets re-initialized. I'm going mild overclock here, but it does not look like total freeze like I know it from overclocking desktop pcs so I guess that's not the problem. €dit: it seems to be related to overclocking in my case. As soon as I pause playback, cpu utilization goes up to 100% (is that intended?) and stuff freezes sooner or later. I removed all overclocking-related things from my config and now the 'hot-reboots' are gone. RE: OpenELEC Testbuilds for RaspberryPi Part 2 - dhead - 2013-12-22 I don't know if something changed in the kernel/firmware but with the latest MilhouseVH image I'm getting the best results ever with dvb-t dongle connected directly to the Pi. On my previous tests (latest probably about 2 months ago) with all the tuners I've tried I got bad results (I've a nice collection because of the Pi). Today I've tried a generic RTL2832 device, Ezcap WandTV (IT9135 based) and a Generic It9135 device (don't have time to test all my devices). I had no issues with the first two but the third acted horribly (as usual) and this is a device that I use 24x7 on my regular pvr server. Anyway, I just thought this is related to the development builds, I probably need to find time to test all my usb dvb-t collection with the Raspberry Pi on standard distribuition set a PVR server only and start a new thread but darn I'm too lazy. RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Milhouse - 2013-12-22 (2013-12-22, 14:40)dhead Wrote: I don't know if something changed in the kernel/firmware but with the latest MilhouseVH image I'm getting the best results ever with dvb-t dongle connected directly to the Pi. If you pay attention to the OpenELEC github you'll see that the kernel is updated very frequently... Code: ae306f2 2013-12-21 16:53:03 +0100 linux: update to linux-3.12.6 Problems will come, and problems will go. Sometimes in a matter of days... So in the last two months there have been many changes, not least the kernel and firmware. RE: OpenELEC Testbuilds for RaspberryPi Part 2 - doveman2 - 2013-12-22 Talking of kernel/firmware updates, I realised the other day that I've been running my remote receiver and tuner plugged into the second half of my hub (it's seven ports, with four of them cascaded off the first chip internally). Several months ago, these ports were unusable, so I think something must have been changed in the kernel to fix this, which is cool With the recent build, I can start a channel from the EPG normally again but there's some new bugs which are causing some entries in the EPG to be blank (it seems to be long programmes which are near the end, maybe 75% and the text showing the title is missing, so maybe the bug is that these titles are "sticking" at the start time of the programme and not being shifted to still show when the EPG current time is near the end of the programme). It's also allowing me to go backwards in the timeline to the start of the day, whereas before it would stop at the current time and bring up the popup menu instead. Also, the advancedsettings.xml tweak below that makes clicking OK start the programme instead of showing the Info and then having to select Switch to this Channel isn't working with this build, which is a bit of a pain. <pvr> <showepginfoonselect>false</showepginfoonselect> </pvr> EDIT: This tweak is working again now. Not sure why it wasn't earlier but nevermind RE: OpenELEC Testbuilds for RaspberryPi Part 2 - javaboyuk - 2013-12-22 Guys Having issue with latest MilHouse and rbej bulid when playing Blu-ray image or .mkv file. The image will freeze at just over 54 mins (about half way) for both builds on the iso image and I have proven the issue with Popcornmix on 2 cut down .mkv files of that period. I was then given a new start.elf file called start_dts.elf that I installed. If I use the start_dts.elf file from Popcornmix (see post from popcornmix .here ) then the mkv files nolonger freeze but there is a slight frame jump at arround the old frame freeze point (tested with rbej build) However the iso file will crash xbmc about 2 minutes in on the Milhouse build, I have some logs of that for: So this is the debug with the xbmc restarting at the end. 100655 On the rbej build the picture will do sort of a fast "catchup" of ~1 sec about 4 secs before the old freeze point with the iso file. Thanks RE: OpenELEC Testbuilds for RaspberryPi Part 2 - TBCdevil - 2013-12-23 I think it's worth noting that f2fs can be best tested on bottleneck areas of the pi. Areas where there are lots of cpu and disk io is compacted into one task like the full library scan. We could split them up into a first scan and an update. Scans can be done over nfs shares or local but need to be noted. Also note when you're using USB or sd. The test itself should be something like scan 50 movies so everyone has similar results. RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Swifty - 2013-12-23 @TBCdevil - Exactly what I was thinking, more accurately I have been wondering if it would help with the PVR feature as that does a bunch of EPG reads / writes everytime XBMC fires up (which for ~120 channels can take a while on the Pi) Will hopefully get some time to do a bit of testing with that over the next few days.. RE: OpenELEC Testbuilds for RaspberryPi Part 2 - tuxen - 2013-12-23 (2013-12-18, 19:49)gummibaum Wrote:(2013-12-18, 11:18)xbs08 Wrote: Interesting benchmarks... Actually.. Speaking of the system itself, depending on the situation alot more writing occurs and not so much read to the sdcard, if you have a 512MB board and set your gpusplit to max 132MB or the normal 128MB the entire SYSTEM image ie. archlinux plus XBMC is run entirely from ram. That leaves the plugins and the library functions. Many addons gather metadata and caches it in a database nowadays (plus all the art thumbs constantly created) this means the first time the addon bumps into a media file it needs to gather metadata for the item and write it to the "cache" database used for this. Read speeds are about the same so reading the metadata back is not really a bottleneck, so you might waste more time gathering metadata. And from this perspective and ofcause which addons used it actually means that it is slower overall. At least for me. Its exactly the same when scanning media for the library(s) for example let me give you a rough example: My library has around 500 movies and around 15 tv-shows they are located on a external self powered 3TB harddrive connected directly to the RPi. Anyway, on a class 10 sdcard it took well over 2hours+ if not more to scan it, and I don't know how long to extract the movie info and make thumbs afterwards. Database file is only ~5MB. Switching to a fast USB3 stick and the scan took around 20mins! About as fast as my PC. Consistantly. Not only that, browsing my media afterwards the fanart and covers where now loaded instantly, literary as fast as I can move the "cursor" up and down, no more waiting 1/2 a sec to 1 or two. I realize this has nothing to do with file systems, 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 IMHO. I am overclocked though at 1025/500/500/+4 and force_turbo=1 its been running like that for almost a year now and I never had any sdcard corruption problems I hear about now and then, setting anything higher just makes it crash or not boot. Funny thing is when I switched to USB storage I actually had to clock down 25Mhz because it was drawing more power, setting overvolt higher than +4 didn't help. I have 2 RPi's, one from UK and one from China both 512MB (I had 256MB board also but donated it to a friend), oh and 2 cl10 sdcard's, and 1 cl6. All combos give same results and overclocking limits (settings) are the same, no.#1 runs runs latest official OE, no.#2 RPi runs raspbian btw. At the moment the XBMC RPi uses a 1.8" harddrive, raspbian a 32GB Kingston mini sdcard. This is just sharing my experience thanks for reading if you did Hope some of it is useful. Rgds tuxen RE: OpenELEC Testbuilds for RaspberryPi Part 2 - xbs08 - 2013-12-23 Before doing the scan test export your library or it will fetch from inet. RE: OpenELEC Testbuilds for RaspberryPi Part 2 - TBCdevil - 2013-12-23 Hey guys, I will also try to plan some tests after Christmas. To busy atm. Please document your tests as good as possible. I'll make a spreadsheet of all the findings. RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Doktor-X - 2013-12-23 i'm using latest OpenELEC "Gotham-RPi.arm-devel-20131220135623-r16601-g3ded391" and have storage on usb 2.0 flash drive formated to f2fs file system but for some unknow reason my setting constantly restart itself RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Koloss - 2013-12-23 f2fs is buggy - i have the same problem with f2fs RE: OpenELEC Testbuilds for RaspberryPi Part 2 - xbs08 - 2013-12-23 After a proper shutdown/reboot? RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Koloss - 2013-12-23 It's crash and after a reboot the settings are lost. I have a problem in one movie - in one position the movie hangs always! When i switch before do english audio DTS( no HD MA) the movie running with no problem. On windows pc with XBMC i have no problem. Quote:ID : 2 |