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 - RichG - 2013-10-18 Thats good - as long as I remember to toggle the write protect on update :-) RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Milhouse - 2013-10-18 (2013-10-18, 11:54)Johnkg Wrote: I still boot from NFS as I assumed it stopped SD card corruption and ran quicker. Is that no longer the case? Yes, booting via NFS can eliminate SD corruption, but so can disabling auto-update and using disk=NFS so that only /storage is mounted over NFS. However booting via NFS is never going to be the quickest option, unless you've got a really awful SD card. With auto-update disabled and booting from /dev/mmcblk0p1, should you want to try a manual update you can just drop the files in the Update folder and cross your fingers. When "booting" via NFS you've got to manually perform the update - copying the SYSTEM file to your NFS partition, and the rest of the files to your SD card, which could still corrupt itself unless you perform the update in your PC. Bottom line, there's no benefit to booting over NFS. (2013-10-18, 12:41)hudo Wrote: ** EDIT ** Nice idea, but the Pi has no way of reading the locked/unlocked status of the SD card as the pin isn't connected on the SD socket... (2013-10-18, 14:19)RichG Wrote: Does the System file ever get written to? As stated by trogggy, the primary SD partition will be written when updating OpenELEC. Normally this partition is mounted read-only, but will be mounted writable during the update, during which time corruption can - if you're unlucky - occur. If you want to eliminate the risk of SD card corruption, disable auto-update, boot from /dev/mmcblk0p1 with NFS, SMB or USB used for disk, and then update firmware on the SD card primary partition using only your PC... RE: OpenELEC Testbuilds for RaspberryPi Part 2 - allan87 - 2013-10-18 One of my Pis boots from a 128 MB SD card that is at least 10 years old. Storage is on USB. I don't see what benefit there is to a bigger or faster card if it is only read during boot up and only written to during an update, or if you edit the config or command files. I also don't see how corruption of the system partition could even be an issue. How is it going to be corrupted if is never being written to in everyday use? RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Milhouse - 2013-10-18 (2013-10-18, 16:22)allan87 Wrote: One of my Pis boots from a 128 MB SD card that is at least 10 years old. Storage is on USB. I don't see what benefit there is to a bigger or faster card if it is only read during boot up and only written to during an update, or if you edit the config or command files. Same here. (2013-10-18, 16:22)allan87 Wrote: I also don't see how corruption of the system partition could even be an issue. How is it going to be corrupted if is never being written to in everyday use? Obviously, not all Pi's are prone to corruption, but for those that are... If your only SD card partition is the primary boot partition, your only chance of corruption is while updating, or when modifying configuration files, as these are the only times the partition should be written to. Although it's unusual for the FAT partition itself to be corrupted, it's not unusual to see corrupt files written that render the device unbootable until the corrupt files are overwritten with working versions. However if you have both primary and /storage partitions on the SD card, it's quite likely that the /storage partition will be corrupted as it is first mounted, hence moving the /storage partition to NFS, SMB or USB to significantly reduce the risk of complete system failure due to corruption. Even cleanly unmounted /storage partitions have been corrupted when next mounted. I once wrote a method for detecting during OpenELEC boot when the SD card wasn't correctly initialised, it involved timing how long it would take to write a 1MB file to the FAT partition - it should normally take <1 second but there were times when it would take 10-15 seconds. I would have the Pi reboot itself when these abnormal IO times were detected and it eliminated corruption of both firmware (during any subsequent update) and of the secondary /storage partition whenever it was mounted. Not a nice solution by any means, but it worked pretty reliably. I've since given away that Pi which suffered from corruption, and my current Pi doesn't have any SD corruption problems... RE: OpenELEC Testbuilds for RaspberryPi Part 2 - stuCONNERS - 2013-10-18 is anyone experience rebooting issues without anything showing in the logs? Either a bug or my power supply went downhill between updates. im lucky if i can get a couple of hours between reboots. wonderered if it was my overclcock, so went back to 700 from 1150 and still the same, couple of hours and reboots for simply no reason RE: OpenELEC Testbuilds for RaspberryPi Part 2 - h.udo - 2013-10-18 Nop. Last time I experienced something similar was using a crappy Nokia charger. However, we need to know which OS flavor/revision you're using in order to help. RE: OpenELEC Testbuilds for RaspberryPi Part 2 - stuCONNERS - 2013-10-18 the last 2 builds for frodo in this thread, didnt happen when i used gotham either, not raspbmc, the reboot problem only seems to have appeared since october builds RE: OpenELEC Testbuilds for RaspberryPi Part 2 - RichG - 2013-10-18 (2013-10-18, 16:43)stuCONNERS Wrote: is anyone experience rebooting issues without anything showing in the logs? Either a bug or my power supply went downhill between updates. im lucky if i can get a couple of hours between reboots. wonderered if it was my overclcock, so went back to 700 from 1150 and still the same, couple of hours and reboots for simply no reason I had a simlar problem (RBEJ Gotham / Popcornhour Build) where XBMC would restart itself with no warning and occasionally reboot itself. It didn't seem to matter if it was playing a video or idle. This had been happening for a couple of weeks or so. After enabling logging I noticed that in a couple of occurances that the last thing logged was the OPENELEC.DEVUPDATE addon - which I uninstalled. The RPi has remained stable for the last three days since doing this so it looks like that may be the casue for my problem (no idea why). (2013-10-18, 16:10)MilhouseVH Wrote: If you want to eliminate the risk of SD card corruption, disable auto-update, boot from /dev/mmcblk0p1 with NFS, SMB or USB used for disk, and then update firmware on the SD card primary partition using only your PC... Good advice - thanks. I think I will go down this root next time I need to update. RE: OpenELEC Testbuilds for RaspberryPi Part 2 - allan87 - 2013-10-18 (2013-10-18, 16:10)MilhouseVH Wrote: … boot from /dev/mmcblk0p1 with NFS, SMB or USB used for disk...Is there a performance hit using NFS as opposed to USB? Raw transfer speed for NFS over fast ethernet (Pi does not have gigabit ethernet) would be slower than USB). RE: OpenELEC Testbuilds for RaspberryPi Part 2 - xbs08 - 2013-10-18 This is what I do for updating... rename config.txt to whatever, copy update files to update folder, reboot, let update finish, rename whatever to config.txt, reboot. RE: OpenELEC Testbuilds for RaspberryPi Part 2 - popcornmix - 2013-10-18 (2013-10-18, 12:38)rbej Wrote: Updated Frodo Branch Things to test: Black screen when switching channels with live tv Loud noise at start of playback when using amplification Seek hanging when deinterlace is enabled You can use the advancedsetting streamsilence (http://wiki.xbmc.org/?title=advancedsettings.xml) to keep hdmi audio active when playback stops. This should avoid the loss of a couple of seconds of audio at start of playback while receiver locks on, and is useful for music playback. Hopefully there will be a gotham build too.... RE: OpenELEC Testbuilds for RaspberryPi Part 2 - pimmelsack - 2013-10-18 Hi Popcornmix, i hope u can help me here is the log: http://xbmclogs.com/show.php?id=70647 I start an HD-Stream and after 1-2 Minutes, the Screen will get frozed for any sec. I hope you know what i mean ;-) RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Milhouse - 2013-10-18 (2013-10-18, 19:05)allan87 Wrote:(2013-10-18, 16:10)MilhouseVH Wrote: … boot from /dev/mmcblk0p1 with NFS, SMB or USB used for disk...Is there a performance hit using NFS as opposed to USB? Raw transfer speed for NFS over fast ethernet (Pi does not have gigabit ethernet) would be slower than USB). For booting? Not really, you're talking about a 100MB image being loaded into RAM. It might load a couple of seconds faster on USB, but that's it. Even when OpenELEC is unable to load the SYSTEM image into RAM, accessing the SYSTEM file from a slow SD card is not likely to be noticeably slower than accessing the same file over NFS or USB (thanks to OS file caching). You could put the SYSTEM file on USB, which will then mean auto-update is no longer an option, but I seriously doubt you'll notice any difference in terms of performance between SD, NFS and USB. Putting /storage on USB is a different matter as generally you want to access your thumbs etc. as quickly as possible, however NFS performance is still pretty good when mounting /storage. RE: OpenELEC Testbuilds for RaspberryPi Part 2 - allan87 - 2013-10-18 No, I wasn't referring to booting. Booting could take twice as long and I wouldn't care. To be clearer, is there a performance hit using NFS as opposed to USB for storage? RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Milhouse - 2013-10-18 (2013-10-18, 21:17)allan87 Wrote: No, I wasn't referring to booting. Booting could take twice as long and I wouldn't care. To be clearer, is there a performance hit using NFS as opposed to USB for storage? Yes, of course. NFS is going to be capped at ~11MB/s, USB can hit 25MB/s. However, the real world difference isn't likely to be so significant, but you will - in all probability - see a performance gain from USB over NFS. |