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 - 2014-02-19 (2014-02-19, 22:49)allan87 Wrote: 256M was the stock setting in the config.txt file of my first install, and I was not aware that it was not optimal. What are the disadvantages of 256? I have checked available CPU memory from time to time and always found plenty of free RAM. Would a setting somewhere in between 128 and 256 make sense (especially if one is running test builds)? To be honest on a 512M Pi, it doesn't make a lot of difference if gpu_mem is set to 128M or 256M. For most uses memory is not an issue. You might want more than 128M on GPU if playing level 5.1 1080p H.264 with 16 reference frame, or using heavy skins with the artwork resolution turned up. You might want more than 256M on ARM if you are running lots of plugins, a torrent client and are streaming video with a big cache set up. But for most users you'll be fine either way. (In fact I have gpu_mem=256 on my home setup). RE: OpenELEC Testbuilds for RaspberryPi Part 2 - MrNice - 2014-02-19 (2014-02-19, 20:26)popcornmix Wrote:(2014-02-19, 18:46)MrNice Wrote: If I set-up 2.0, I have output 2.0 with PCM 6 Channels files and 5 Channels output with DTS/AC3 files (I have 5.0 speakers) Passthrough ON Files are PCM MCH Please find the first log here You could notice; - After switching on Pi I tried to play one file but I had no sound at all. I had to change the video resolution from 720 to 1050 and sound want back. This occur very often when I start the device. I didn't post about that so far. (if you can read why this issue could be good) - First I played 1 file with 5.0 config - Second I played 2 files with 2.0 config File is AC3 The second log here - I did a reboot and I had to change the resolution to 720 to get sound - First I played 1 file with 5.0 config - Second I played 1 file with 2.0 config Don't hesitate to tell me any issue you could notice. Hope this will help RE: OpenELEC Testbuilds for RaspberryPi Part 2 - popcornmix - 2014-02-19 (2014-02-19, 23:02)MrNice Wrote: Files are PCM MCH First log is a wav file with PCM. Only DTS and AC3 support passthough, so this doesn't use passthrough. Therefore speaker configuration does have an effect. Second log is AC3 audio. Passthough is correctly being used. Therefore you will have multichannel audio whether speaker configuration is set to 2.0 or 5.0. RE: OpenELEC Testbuilds for RaspberryPi Part 2 - MrNice - 2014-02-19 So to conclude, as I play PCM MCH, DTS and AC3 files I have to always set-up 5.0 to get full audio. Do you agree? RE: OpenELEC Testbuilds for RaspberryPi Part 2 - popcornmix - 2014-02-19 (2014-02-19, 23:20)MrNice Wrote: So to conclude, as I play PCM MCH, DTS and AC3 files I have to always set-up 5.0 to get full audio. Yes. omxplayer and your equipment support mulitchannel PCM, so setting speaker configuration to 5.0 is correct. dvdplayer/papalyer don't (yet) support multichannel PCM, so you may need to disable it for those. I'm hoping to support that soon. RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Jönke - 2014-02-20 (2014-02-19, 20:54)popcornmix Wrote:(2014-02-19, 20:51)Jönke Wrote: With deinterlace disabled Was on 128 and changed to 256 and sd tv seems to work better but 1080i livetv/recording still black screen (only sound) Here is a sample that plays with omxplayer but not dvdplayer https://www.dropbox.com/s/lh15yu1zkbuzj9x/Steve%20Irwin%27s%20Wildlife%20Warriors.2014-02-19.E18.mkv RE: OpenELEC Testbuilds for RaspberryPi Part 2 - thomasthetomcat - 2014-02-20 I have the same problem using dvdplayer to watch .mkv files with high bitrates. Lower bitrates work fine, but higher materials cause laggs (in picture and sound) and frame dropping. And at the beginning I see a black screen and only hear the sound. Then the picture appears and fast-forward until it reaches the position where the sound already is. Omxplayer works without problems. RE: OpenELEC Testbuilds for RaspberryPi Part 2 - delinend - 2014-02-20 Thanks Milhouse, for updating to lcdproc-0.5.7-cvs20140217, in your last build. Now my HD44780 LCD/Display via Rpi/GPIO works out-of-the-box in Gotham, without driver change :-) RE: OpenELEC Testbuilds for RaspberryPi Part 2 - tfouto - 2014-02-20 (2014-02-19, 22:54)popcornmix Wrote:(2014-02-19, 22:49)allan87 Wrote: 256M was the stock setting in the config.txt file of my first install, and I was not aware that it was not optimal. What are the disadvantages of 256? I have checked available CPU memory from time to time and always found plenty of free RAM. Would a setting somewhere in between 128 and 256 make sense (especially if one is running test builds)? popcornmix, How safe can we increase memory gpu_mem? 300? RE: OpenELEC Testbuilds for RaspberryPi Part 2 - popcornmix - 2014-02-20 (2014-02-20, 10:55)tfouto Wrote: How safe can we increase memory gpu_mem? 300? If you want, but unless you are seeing OMX errors in the log, it won't make any difference. RE: OpenELEC Testbuilds for RaspberryPi Part 2 - doveman2 - 2014-02-20 As well as the avis I previously referred to, I find dvdplayer can't skip forward in streaming video either, so I'm having to use omxplayer for most things at the moment. RE: OpenELEC Testbuilds for RaspberryPi Part 2 - dhead - 2014-02-20 (2014-02-12, 21:16)dhead Wrote:(2014-02-12, 15:17)doveman2 Wrote: Regarding the issue where the remote volume keys don't repeat, which is apparently an OS-level bug as XBMC doesn't do the repeating itself but relies on the OS to handle this, I wonder if this workaround for Ubuntu can be used with OE? I've been doing a little more testing and I think I know how to solve this. If I understand correctly when you hold the VolumeUp button the remote send a button hold event and when released the remote sends a release event. When you hold another button like a "K" the remote will send a press key event (hold and release ?) and repeat again (with some delay) and again until you release the button. I think that maybe XBMC is relying on SDL and X11 to convert "hold" and "release" events when there is a large delay between them (the button is held) to continuously repeats. On the Raspberry where no SDL and X11 are use, XBMC gets events from the kernel which doesn't do this conversion. I'm not sure if it is a good idea to have this issue solved in XBMC, probably better to solve it in external app. The best suiteable candidate is eventlircd but we will need to code in this feature. My coding skills are lacking but this is surely my do-it list. RE: OpenELEC Testbuilds for RaspberryPi Part 2 - doveman2 - 2014-02-20 (2014-02-20, 14:29)dhead Wrote: I've been doing a little more testing and I think I know how to solve this. I wouldn't have thought there's any difference with the remote as to what it sends when holding a button, so I imagine it sends the same sort of command whether I'm holding VolumeUp or the down button on the d-pad. The latter repeats in XBMC whilst the former doesn't though, so I guess the kernel must be doing something different when it sees that VolumeUp/Down is being pressed compared to the other keys and not sending repeats to XBMC. If this is the case, perhaps a workaround would be to remap the VolumeUp/Down keys at/before the kernel level, so it sees them as normal keys/scancodes that it does send repeats for and then at the XBMC level, map these keys/scancodes to the Volume commands? RE: OpenELEC Testbuilds for RaspberryPi Part 2 - dhead - 2014-02-20 (2014-02-20, 16:32)doveman2 Wrote:(2014-02-20, 14:29)dhead Wrote: I've been doing a little more testing and I think I know how to solve this. The kernel is too "stupid" to do this distinction (I'm not a developer but this distinction should be do in userspace not in the kernel). This can't be solved by remapping the scancodes to other keycodes in the kernel with hwdb.d, I already tried it, See https://wiki.archlinux.org/index.php/Map_scancodes_to_keycodes I believe the repeats (and delays) are implemented by the mcu in the keyboard and got nothing to do with the OS. RE: OpenELEC Testbuilds for RaspberryPi Part 2 - doveman2 - 2014-02-20 (2014-02-20, 16:49)dhead Wrote: [The kernel is too "stupid" to do this distinction (I'm not a developer but this distinction should be do in userspace not in the kernel). OK. I wish there was some way to check for sure if the remote is not sending the volume buttons repeated unlike all the other buttons but I think Windows has too many layers of software in the way to easily find out exactly what it's doing. Maybe the remote doesn't send repeats for any keys though and it's the OS that decides what to do when a key is held down (i.e between the Press signal and the Release signal) and the OS signals to XBMC when the other keys are held down and thus XBMC repeats the commands but it's not doing this for the Volume keys? |