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 - Jönke - 2013-10-05 Did a quick test and i got live tv running on that build but cpu use was near 100% all the time both on sd and hdtv 1080i. RE: OpenELEC Testbuilds for RaspberryPi Part 2 - FattyMcDirty - 2013-10-05 so.. which is actually the most stable and reliable build at the moment? (which is also fluid in gui..?) RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Koloss - 2013-10-05 All people says every USB-Stick is faster as a sd-karte: My test, Pi boot time, same latest rbej image: SD-Card, Sony SF16UX Class10 16GB SDHC : 28 seconds USB-Stick, Lexar® Echo ZX Backup Drive 8GB: 45 seconds RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Milhouse - 2013-10-05 Filesystems mounted from /dev/* or with LABEL=*/UUID=* will be automatically fsck'ed before being mounted. If you're using a large-ish USB, it will take a noticeable amount of time to be fsck'ed, and increase the time to boot the system. My 32GB USB3.0 memory stick takes a good 25 seconds to be fsck'ed. Not sure why your SD card should be so much quicker to fsck, perhaps you only had a small partition on it and not the full 16GB? Obviously, booting over NFS (or SMB) there's no delay due to fsck. Must admit I'm not seeing a huge win with USB compared to NFS, despite this particular USB being good for 25MB/s read and 13MB/s write rate - I think the 1080 fanartres and 720 imageres nullifies any benefit from improved IO. RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Koloss - 2013-10-05 I have to 2 same SD-Cards First Config, Only SD-Card:: My SD-Card: 125MB Fat 14.9GB Ext4 Second Config: SD-Card and USB-Stick: 125MB FAT A-Card USB-Stick 8GB Full Ext4 I use this mount with USB-stick: boot=/dev/mmcblk0p1 disk=/dev/sda1 ssh quiet RE: OpenELEC Testbuilds for RaspberryPi Part 2 - trogggy - 2013-10-05 (2013-10-05, 11:17)Koloss Wrote: All people says every USB-Stick is faster as a sd-karte: Boot speed is fairly irrelevant on a pi if you leave it on all the time. I've never measured, but I've used class 4 and class 10 sd cards, usb2 and usb3 sticks. My impression is that my usb3 sticks (transcend 8GB) are a lot quicker with menus / loading images than my class 10 sd card (sandisk 16GB). USB2 sticks (and I've tried a few) don't seem particularly quick. RE: OpenELEC Testbuilds for RaspberryPi Part 2 - theneverstill - 2013-10-05 (2013-10-04, 22:15)allan87 Wrote: "Indeed this is one of the drawbacks of handbrake / H.264 and trying to achieve the same quality as the original bluray"- why reencode it, then? If you like RF 20 then go for it. I'm glad that works for you. If you can point me to a guide to getting my RPi to consistently/stably play raw bluray isos then I will have no reason to encode. Until then, it is because most distros can handle H.264. RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Koloss - 2013-10-05 I order a new transcend in the next week USB 3.0 Transcend 780 8GB Stick Tested with 30sec scroll fanart My next test with 30sec(Automatic stop in 30 sec) scroll fanart USB-Stick vs. SD-Card: The USB-Stick stops later in the movie list, he is FASTER. My next test with usb-stick: I add this and reload my textures: <fanartres>720</fanartres> <imageres>512</imageres> All fanarts 512px and all fanarts are 720px, its ok! Tested with 30sec scroll fanart movies(Automatic stop in 30 sec), the result i stop in the same Movie with old and new settings! I cannot see a performance different to my old settings: This tweak has no effect! Sorry, @popcornmix. Next problem, i cannot install amber skin in this build, it is incompatible. Now i cannot see the skin do install it RE: OpenELEC Testbuilds for RaspberryPi Part 2 - hpbaxxter - 2013-10-05 (2013-10-05, 12:38)theneverstill Wrote: If you can point me to a guide to getting my RPi to consistently/stably play raw bluray isos then I will have no reason to encode. Until then, it is because most distros can handle H.264. You could just take the main m2ts stream of the bluray, for example, then only chapters are missing. It's usually around 33 GB and should play well on an overclocked rpi. Except for dolby truehd audio streams, but you can chose another audio stream. H.264 and VC-1 work, provided you have the licence. RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Koloss - 2013-10-05 Dolby true hd is now passthrought now runnind or downsampling do DD? RE: OpenELEC Testbuilds for RaspberryPi Part 2 - doveman2 - 2013-10-05 (2013-10-05, 02:30)trogggy Wrote: You could always put location / timezone info in an advancedsettings.xml. Saves setting up, and unless your pi is a regular traveller... I actually found a while back that I need to edit advancedsettings.xml and guisettings.xml with the correct Locale information for the correct time to show. So this was already done but I still had to reboot again after updating before the correct time would show. (2013-10-05, 09:17)Cassiel Wrote:(2013-10-02, 16:39)rbej Wrote: Updated Gotham Branch That's strange as SD LiveTV (Freeview, TVHeadend, TVH and USB tuner both on the RPi) works fine for me. I just can't skip through recordings. I don't think I've tested Shutdown but reboot doesn't work for me and just dumps me to a blank screen. RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Cassiel - 2013-10-05 (2013-10-05, 13:33)doveman2 Wrote:(2013-10-05, 02:30)trogggy Wrote: You could always put location / timezone info in an advancedsettings.xml. Saves setting up, and unless your pi is a regular traveller... Currently using TVHeadend on my NAS and H.264 Channels do work… I first thought it was a bandwidth problem of the USB WiFi adapter, but HD channels work great. Maybe deinterlacing is breaking the SD playback? RE: OpenELEC Testbuilds for RaspberryPi Part 2 - theneverstill - 2013-10-05 (2013-10-05, 13:13)hpbaxxter Wrote:(2013-10-05, 12:38)theneverstill Wrote: If you can point me to a guide to getting my RPi to consistently/stably play raw bluray isos then I will have no reason to encode. Until then, it is because most distros can handle H.264. Genius! I'll use tsmuxer to rip the main mpls (thankyou BDInfo) which will combine all of the necessary m2ts files in the right order, then use mkvmerge to throw the audio (using eac3to to give me the best hd pcm and also a downmixed stereo - converted from best audio on disk), chapters, and potential forced subs back in! Giving that a try now... RE: OpenELEC Testbuilds for RaspberryPi Part 2 - theneverstill - 2013-10-05 @hpbaxxter Thankyou! That worked wonderfully! Not only are my rip times cut TREMENDOUSLY but it appears as if the original video plays MUCH better than the encoded versions. My original test was with Iron Man 1 and this one was with Star Trek 2 (the new one).. so I know it isn't exactly an apples to apples comparison -- which is why I'm redoing iron man 1 as we speak. However, that being said, if you read my previous posts I was using 100% CPU and the buffer kept getting emptied out. Now, I am still using the 7.1 PCM audio, and still playing a 1080p movie, but here is the comparison: Different: Movie and therefore bitrates (Iron Man 1 vs Star Trek 2), resolution (1920x1088 vs 1920x1080), and filesize (50GB vs 35GB) Same: Both BDs, 7.1 PCM audio, standard clock rates (no overclock) Result: Star Trek 2 plays wonderfully and only uses ~70-75% CPU --- I'll post again when Iron Man 1 has been reripped and remuxed. RE: OpenELEC Testbuilds for RaspberryPi Part 2 - hpbaxxter - 2013-10-06 Glad that I could help, and thanks alan87 for the hint. Seems like exceptionally high bitrate is a problem and pcm just works fine, as filesize perfectly correlates to cpu usage ... as both films are 2h + a little, I presume that average bitrate and filesize correlate as well. Hopefully we are right and Iron Man will show better playback as well! |