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 - prae5 - 2013-11-29 I can add these builds to my buildbot / create a folder on the CDN that i used for xbmcnightlybuilds.com if it helps? i.e could do similar to what i'm doing for the RetroPlayer builds and make a folder similar to: http://cdn.us.serverst.at/xbmcnightlybuilds.com/OpenELEC-RetroPlayer/ RE: OpenELEC Testbuilds for RaspberryPi Part 2 - xbs08 - 2013-11-29 Sorry if this a stupid question but I did search and couldn't find it... How can I change the subtitle download language in the latest MilhouseVH build? It only shows [eng] subs available for download in opensubtitles. FOUND IT! Settings > Videos > Subtitles facepalm RE: OpenELEC Testbuilds for RaspberryPi Part 2 - evanspae - 2013-11-29 (2013-11-28, 18:41)popcornmix Wrote:(2013-11-28, 18:37)evanspae Wrote: As previously mentioned the time to start playing an HD Television recording is showing a tremendous improvement, but alas I am now getting a drift of lipsync of approx 500ms over a 2hr period? As mentioned above this is playback of pre recorded .ts file on a well established system. This and other files plays fine on other xbmc clients (mainly 12.2 Frodo builds) both on PCs and stable raspberrypi openelec 3.2.3. There are not reception or file errors and it is a new problem on latest build. I RE: OpenELEC Testbuilds for RaspberryPi Part 2 - popcornmix - 2013-11-29 (2013-11-29, 13:24)evanspae Wrote: As mentioned above this is playback of pre recorded .ts file on a well established system. This and other files plays fine on other xbmc clients (mainly 12.2 Frodo builds) both on PCs and stable raspberrypi openelec 3.2.3. There are not reception or file errors and it is a new problem on latest build. If you seek to the end, is the sync off by the same amount as if you'd played from the beginning, or does seeking fix the sync? Can you upload a file that has this problem and send me a link? The smaller the better, although in this case the drift may only be visible in a large file. (Google drive is a good way of hosting a large file). RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Reddog999 - 2013-11-29 @MilhouseVH I know this is a big ask but how difficult/time consuming would it be for you to recompile your last build based on Linux 3.10.xx - I will understand your reluctance if this is not practical. My reason for asking this is that with all the latest dev builds (except for Rbej's builds), the GPIO ir receiver does not work and I believe I have found that the culprit may be the Linux version. I have tried at least a dozen different builds and my results are: All official Openelec builds (e.g. 3.1.6, 3.1.7, 3.2.3) work - they use Linux version 3.10.xx All Rbej Frodo and Gotham builds work - he uses version 3.10.xx Chris Swan builds: all builds up to 13/9/13 (build version r15595) work - uses Linux version 3.10.xx all builds from 14/9/13 (build version r15889) do not work - uses Linux version 3.11.xx Your builds using Linux version 3.12.xx do not work Of course it could be a Frodo/Gotham thing but since Rbej's Gotham releases use Linux version 3.10.xx that work, I believe it is more likely to be a driver problem that is packaged with the Linux kernel. My other post gives some more information. If I was a more able person I would make my own build but sadly I don't have the knowledge or the tools to do this. RE: OpenELEC Testbuilds for RaspberryPi Part 2 - zeus[x] - 2013-11-29 Hi, sorry about this dumb question, but google din't helped me mutch. What are, is any, the main differences from the different builds of MilhouseVH and Rbej? Can someone give some highlights about how this process works? Thanks! RE: OpenELEC Testbuilds for RaspberryPi Part 2 - allan87 - 2013-11-29 I'll take a crack at providing some basic info (relevent as of November 29, 2013) in response to your question. - rbej does frodo and gotham builds. You can search for info about the differences between gotham (xbmc pre-alpha 13) and frodo (xbmc 12). - rbej bases his builds (frodo and gotham) on openelec 3.x - the release versions of openelec 3.x use frodo - the recent gotham builds by others (mostly Milhouse) have been based on openelec 4.x - rbej has not done a new gotham build for over a month. He indicated that there is an issue with 3.2.x that has prevented him from making newer builds. - Rbej indicated (and it makes sense) that builds based on stable openelec (3.x) will be more stable and have fewer issues than builds based on openelec 4.x (which is very much in development. - Rbej's latest gotham build, since it is over a month old, will not have the newest refinements/commits/PRs/enhancements/bug fixes AND new bugs. Another way of looking at it: The most notable improvements made over the past month relate to speed/efficiency/performance. So, I would say: - Rbej gotham: very stable, fewer bugs; - Newer builds: faster, more bugs, but working very well for many people. RE: OpenELEC Testbuilds for RaspberryPi Part 2 - MrNice - 2013-11-29 Hi allan87, As you are very aware of builds and I don't want to disturb the package builders, I have a question: I'd like to have CECAnyway in a build, as I don't have a CEC TV but a monitor (DVI). Is it possible that a package builder include CECAnyway in a near futur build? How they choose the next feature to add? I am ready to help to test for debug. Thanks RE: OpenELEC Testbuilds for RaspberryPi Part 2 - allan87 - 2013-11-29 Sorry, I don't really know that much. My information is largely from following this thread. RE: OpenELEC Testbuilds for RaspberryPi Part 2 - zeus[x] - 2013-11-30 Dear allan87, thanks for your great answer! RE: OpenELEC Testbuilds for RaspberryPi Part 2 - unclejoe01 - 2013-11-30 (2013-11-28, 02:24)MilhouseVH Wrote: New OpenELEC Gotham build on dropbox. is it possible to run this off of NFS file Share? RE: OpenELEC Testbuilds for RaspberryPi Part 2 - allan87 - 2013-11-30 Bug? I have not been able to install add-ons with the recent build. It says "working", the text by the add-on says "downloading 0%", but both indicators soon disappear and then its back to square 1. RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Milhouse - 2013-11-30 (2013-11-28, 23:36)goRt Wrote: Hi, (2013-11-29, 06:55)Leopold Wrote: @MilhouseVH If you could put your builds into the same Dropbox folder and share the url to the folder then I can add it to the add-on. I've found your builds to be a big improvement over the latest OpenELEC release so it would be great if you could do that. delinend has kindly set me up on his server at the following url: http://netlir.dk/rbej/builds/index.php?dir=MilhouseVH/ and I'll be pushing my infrequent releases to that folder rather than continue with dropbox. If you want to update the addon to reference this folder, fine with me. (2013-11-30, 03:41)unclejoe01 Wrote: is it possible to run this off of NFS file Share? Don't see why not. (2013-11-30, 04:32)allan87 Wrote: Bug? I have not been able to install add-ons with the recent build. It says "working", the text by the add-on says "downloading 0%", but both indicators soon disappear and then its back to square 1. Anything in your debug log? RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Milhouse - 2013-11-30 (2013-11-29, 16:57)Reddog999 Wrote: @MilhouseVH Not likely, no - I'm more interested in publishing and testing upcoming fixes and new features rather than create custom builds that resolve specific issues like this. You should really work with the OpenELEC developers to try and resolve the issues that remain with the current 3.12.x kernel - if/when a patch becomes available I'll include it in my build. Have you tried copying a 3.10.x kernel to the latest Gotham build - does it work? RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Milhouse - 2013-11-30 Unfortunately I don't have any non-Pi Gotham system to compare this with, but the height/width properties of cached artwork are not always being written to Textures13.db. I've compared this with an OE Frodo x86 system and the height/width is consistently stored in the cache (whether cached via the GUI or http). However on the Pi, the height/width for local artwork is not being stored, but it is being stored for remote artwork (not sure why - maybe part of the daily re-hashing process?) It isn't a problem (as far as I can tell), but presumably these height/width fields serve some sort of purpose and it's strange that the Pi* doesn't appear to be populating them consistently, is there maybe a problem or omission in the OMX thumbnail creation pipeline? For instance on Gotham/Pi: Code: rpi512:~ # ./texturecache.py s zombieland And on Frodo/x86: Code: OpenELEC:~ # ./texturecache.py s zombieland The third and fourth fields are the height and width - on Gotham they're both 0000 for the local artwork. Can anyone confirm what height/width properties you get for freshly cached artwork on Gotham/x86? * It could be a Gotham problem and not Pi specific, I simply can't tell right now. |