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 - ijsbeer79 - 2014-03-19 Are the changes to bcm2835-bootloader only for 'new' SD cards, or are those also applied to the current working setups? Occording to the filename, it's only about new ones. Is this correct? https://github.com/OpenELEC/OpenELEC.tv/commit/81bdf9adb26f55c059d46f4136d0e719f313e0da RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Forage - 2014-03-19 Not sure if you are guys are actively monitoring the FIQ_FSM USB driver rewrite thread but today there was an update which might fix the network devices suddenly stop responding issue. I'm having that issue as well and it would be interesting to see if we can get rid of the "dwc_otg.fiq_fsm_enable=0" work-around now. RE: OpenELEC Testbuilds for RaspberryPi Part 2 - 606u - 2014-03-19 (2014-03-19, 16:55)popcornmix Wrote:Problems from this older post still stands with both -- PAPlayer and DVDPlayer. I've recorded a short clip to demonstrate the issue (the volume level is a bit low, tho): 24-bit, 44 kHz 5.1 sounds pretty bad: music is heard from front left channel all the time, center channel occasionally, the rest are mostly mute. Audio breaks every now and then, when garbled audio starts, moving cursor (in songs list) up and down fixes it for a short time (while cursor is sliding up or down), then it breaks again.(2014-03-19, 03:28)MilhouseVH Wrote: New OpenELEC Gotham build: #0319 With OXMPlayer 24-44 works fine, except, I believe, that center and front right are swapped, and rear left sounds like LFE. Higher frequencies interrupts with songs list visible, works fine on full screen, but should be noted, that audio is down-sampled to 48 kHz. I personally am quite happy with the progress made so far and the lack of multichannel audio is okay with me. It is exotic and unpopular enough and non-overclocked Pi is on the edge to keep up with decompression. I think it is a more realistic goal for a dedicated, GUI-less music player. Update: Setup: Pi -> HDMI to the Receiver -> HDMI to the display. RE: OpenELEC Testbuilds for RaspberryPi Part 2 - 606u - 2014-03-19 I want to report somewhat unusually high utilization when Official XBMC Remote for iOS is connected and on Now Playing screen -- 15 to 20% CPU utilization on the Pi just because of that. I suppose it is unnoticeable on a higher-performace hardware, such as a commodity PC, but it's quite noticeable on Pi. RE: OpenELEC Testbuilds for RaspberryPi Part 2 - popcornmix - 2014-03-19 (2014-03-19, 22:22)606u Wrote: I want to report somewhat unusually high utilization when Official XBMC Remote for iOS is connected and on Now Playing screen -- 15 to 20% CPU utilization on the Pi just because of that. I suppose it is unnoticeable on a higher-performace hardware, such as a commodity PC, but it's quite noticeable on Pi. Do you get the same effect with a different xbmc remote (e.g. xbmc commander?) Not sure there's much we can do if the remote is just sending messages continuously, but it might be worth mentioning on the XBMC remote forum. RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Milhouse - 2014-03-19 @606u: turn on debug log (wiki), specifically JSON logging, and I'm pretty sure the reason for increased load will become clear. Unfortunately some smartphone remotes are just not that smart... RE: OpenELEC Testbuilds for RaspberryPi Part 2 - 606u - 2014-03-19 (2014-03-19, 22:42)MilhouseVH Wrote: @606u: turn on debug log (wiki), specifically JSON logging, and I'm pretty sure the reason for increased load will become clear. Unfortunately some smartphone remotes are just not that smart...Here it is. RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Milhouse - 2014-03-20 (2014-03-19, 23:15)606u Wrote:(2014-03-19, 22:42)MilhouseVH Wrote: @606u: turn on debug log (wiki), specifically JSON logging, and I'm pretty sure the reason for increased load will become clear. Unfortunately some smartphone remotes are just not that smart...Here it is. Pretty much as suspected, the remote control app is spamming the client with JSON requests several times a second, most likely to maintain it's own state (what's playing, seek positiion etc.). Most (if not all of these) JSON requests are completely unnecessary, as the app could get the same information via JSON notifications without spamming the client. Code: 23:06:29 62.758083 T:2667574352 DEBUG: JSONRPC: Incoming request: {"method":"Player.GetProperties","id":-472574362,"jsonrpc":"2.0","params":{"playerid":1,"properties":["percentage","time","totaltime","partymode","position","canrepeat","canshuffle","repeat","shuffled","canseek"]}} Note how there are two separate threads (T:2667574352 and T:2794067024) on the Pi both responding to JSON requests, suggesting that you have the same app running on two iOS devices and that when you start playing a movie on the XBMC client the app on each device goes into overdrive spamming the XBMC client with JSON requrests just to maintain it's own internal state. If you add this app to a third iOS device... well, you can see the problem, eventually you won't be able to play movies! There's an Android app (Yatse) that does the same, it's ridiculous. My advice would be to uninstall this garbage and find a smarter app... (2014-03-19, 21:45)ijsbeer79 Wrote: Are the changes to bcm2835-bootloader only for 'new' SD cards, or are those also applied to the current working setups? Yes, it would be for when creating a new installation from scratch, it will have no effect when updating an existing installation. RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Milhouse - 2014-03-20 New OpenELEC Gotham build: #0320b (Supercedes previous build) Code: # uname -a Based on tip of XBMC master (33133a5, changelog) and tip of OpenELEC master (e57e1bc, changelog) with the following modifications:
FIQ FSM has been updated, please re-enable and re-test if you were experiencing problems. Removing any dwc_otg.* options from cmdline.txt should be sufficient to re-enable FIQ FSM. This may resolve issues for those that were losing their network connection.
RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Milhouse - 2014-03-20 Updated last build with addition of Python package regex. RE: OpenELEC Testbuilds for RaspberryPi Part 2 - denz - 2014-03-20 For some of the channels the top few row of pixels are not being displayed properly. I went to video calibration and adjusted the screen and now the offending row of pixels are not shown however the issue is that by doing this I have pushed the skin's clock too far and I only see 3 quarters of it and it looks horrible now. Is it possible to adjust overscan for live tv for those few channels without adjusting the skin which shows properly without the video calibration adjustment. I am using default omxplayer I have tried dvdplayer but it manages to crash XBMC on certain channel change. RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Eoghlear - 2014-03-20 (2014-02-10, 21:15)michbeck100 Wrote:(2014-02-09, 01:42)michbeck100 Wrote: I'm using Hyperion successfully since a few weeks, now. It's great, taking about 4-5% CPU. I packed the whole thing into an Openelec addon and I'm planning to make it available soon. Just have a look at the Hyperion thread (http://forum.stmlabs.com/showthread.php?tid=11053). Did anyone test this? RE: OpenELEC Testbuilds for RaspberryPi Part 2 - popcornmix - 2014-03-20 (2014-03-19, 22:11)606u Wrote: Problems from this older post still stands with both -- PAPlayer and DVDPlayer. I've recorded a short clip to demonstrate the issue (the volume level is a bit low, tho): 24-bit, 44 kHz 5.1 sounds pretty bad: music is heard from front left channel all the time, center channel occasionally, the rest are mostly mute. Audio breaks every now and then, when garbled audio starts, moving cursor (in songs list) up and down fixes it for a short time (while cursor is sliding up or down), then it breaks again. The audio break up (a repeated rumbling noise) should be fixed in latest Milhouse build. If you still believe channels are mapped wrongly, then can you upload a sample file and describe your audio settings. RE: OpenELEC Testbuilds for RaspberryPi Part 2 - ijsbeer79 - 2014-03-20 (2014-03-20, 15:10)Eoghlear Wrote:(2014-02-10, 21:15)michbeck100 Wrote:(2014-02-09, 01:42)michbeck100 Wrote: I'm using Hyperion successfully since a few weeks, now. It's great, taking about 4-5% CPU. I packed the whole thing into an Openelec addon and I'm planning to make it available soon. Just have a look at the Hyperion thread (http://forum.stmlabs.com/showthread.php?tid=11053). Why would you? Hyperion could be installled to OE already. See theire wiki: https://github.com/tvdzwan/hyperion/wiki/Installation-on-RPi-with-OpenELEC RE: OpenELEC Testbuilds for RaspberryPi Part 2 - mikeb93 - 2014-03-20 Is there or will there be a solution to just stop playback and go back to the Home screen of xbmc when the TV shuts off? (cec-commands?) Or can this be achieved somehow? I'd really love a solution like this since I'm using my TV's sleep timer a lot... |