+- 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 - fritsch - 2014-02-11
mediainfo
RE: OpenELEC Testbuilds for RaspberryPi Part 2 - vprasinos - 2014-02-11
Medianfo? How? I need a list of DTS and PTS values for every frame...
RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Trixster - 2014-02-11
max_clock_drift=100
max_clock_drift_rate=100
on my 512mb pi makes xbmc lock up if youtube videos are paused for longer than about 10seconds. Without these in config.txt there are no such issues.
RE: OpenELEC Testbuilds for RaspberryPi Part 2 - popcornmix - 2014-02-11
(2014-02-11, 19:49)Trixster Wrote: max_clock_drift=100
max_clock_drift_rate=100
on my 512mb pi makes xbmc lock up if youtube videos are paused for longer than about 10seconds. Without these in config.txt there are no such issues.
Are you 100% sure? Can you try a few times with the options present and absent. I can't think of a reason that could happen.
RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Trixster - 2014-02-11
Pretty sure mate, I had 5 youtube clips crash on me back to back with those options in config.txt. I then #'ed the two lines out and now no clips when paused seem to make xbmc hang. Ill do some more testing after the Olympic half pipe finishes!
RE: OpenELEC Testbuilds for RaspberryPi Part 2 - popcornmix - 2014-02-11
(2014-02-11, 19:04)vprasinos Wrote: Medianfo? How? I need a list of DTS and PTS values for every frame...
ffprobe will display pts and dts of every frame.
RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Trixster - 2014-02-11
Right, funny old thing, I now can't repeat the crashing! Sorry Dom, put it down as a false alarm!
RE: OpenELEC Testbuilds for RaspberryPi Part 2 - allan87 - 2014-02-11
(2014-02-11, 20:21)Trixster Wrote: Pretty sure mate, I had 5 youtube clips crash on me back to back with those options in config.txt. I then #'ed the two lines out and now no clips when paused seem to make xbmc hang. Ill do some more testing after the Olympic half pipe finishes!Aside from editing out the lines, you also rebooted. the rebooting may have alleviated the problem.
RE: OpenELEC Testbuilds for RaspberryPi Part 2 - craigbeat - 2014-02-11
(2014-02-11, 21:39)allan87 Wrote:(2014-02-11, 20:21)Trixster Wrote: Pretty sure mate, I had 5 youtube clips crash on me back to back with those options in config.txt. I then #'ed the two lines out and now no clips when paused seem to make xbmc hang. Ill do some more testing after the Olympic half pipe finishes!Aside from editing out the lines, you also rebooted. the rebooting may have alleviated the problem.
If you ssh in and do a df -h, how much space have you got left on storage? I have found that rebooting sometimes gives me a bit more space back. If you are caching to disk, perhaps you are running out of space? I had this happen to me a number of times before I realised what was going on.
RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Trixster - 2014-02-12
I had rebooted after every lock up, and rebooted after each change to config.txt to try and replicate the lock ups. Storage is a 16gb usb drive which is what I'm running the system from. The sd card is an 8gb class 10 card. The pi is a 512mb model. I don't think I'm running out of space. I do not believe I am caching to the usb stick or the sd card. I have no other particular settings or tweaks in either config.txt or advancedsettings which might have given rise to the problem. The only change was the two extra lines of text which i added to config.txt yesterday evening. This afternoon was the first time I'd tried streaming youtube clips since making those two amendments. That 5 separate 720p streams crashed xbmc after having left been on pause for a few minutes each time is what led me to believe the new settings were to blame. Taking those two lines out fixed the issue, and that's what made me make my original post.
It's frustrating that I can't seem to replicate it now, hence my second post!
I am not running a steam now, but df -h gives this:
Filesystem Size Used Available Use% Mounted on
devtmpfs 121.4M 0 121.4M 0% /dev
/dev/mmcblk0p1 124.7M 103.4M 21.4M 83% /flash
/dev/sda 14.0G 1.0G 12.2G 8% /storage
/dev/loop0 93.3M 93.3M 0 100% /
tmpfs 122.9M 0 122.9M 0% /dev/shm
tmpfs 122.9M 356.0K 122.5M 0% /run
tmpfs 122.9M 0 122.9M 0% /sys/fs/cgroup
tmpfs 122.9M 24.0K 122.9M 0% /var
tmpfs 122.9M 4.0K 122.9M 0% /tmp
RE: OpenELEC Testbuilds for RaspberryPi Part 2 - craigbeat - 2014-02-12
(2014-02-12, 00:19)Trixster Wrote: I had rebooted after every lock up, and rebooted after each change to config.txt to try and replicate the lock ups. Storage is a 16gb usb drive which is what I'm running the system from. The sd card is an 8gb class 10 card. The pi is a 512mb model. I don't think I'm running out of space. I do not believe I am caching to the usb stick or the sd card. I have no other particular settings or tweaks in either config.txt or advancedsettings which might have given rise to the problem. The only change was the two extra lines of text which i added to config.txt yesterday evening. This afternoon was the first time I'd tried streaming youtube clips since making those two amendments. That 5 separate 720p streams crashed xbmc after having left been on pause for a few minutes each time is what led me to believe the new settings were to blame. Taking those two lines out fixed the issue, and that's what made me make my original post.
It's frustrating that I can't seem to replicate it now, hence my second post!
I am not running a steam now, but df -h gives this:
Filesystem Size Used Available Use% Mounted on
devtmpfs 121.4M 0 121.4M 0% /dev
/dev/mmcblk0p1 124.7M 103.4M 21.4M 83% /flash
/dev/sda 14.0G 1.0G 12.2G 8% /storage
/dev/loop0 93.3M 93.3M 0 100% /
tmpfs 122.9M 0 122.9M 0% /dev/shm
tmpfs 122.9M 356.0K 122.5M 0% /run
tmpfs 122.9M 0 122.9M 0% /sys/fs/cgroup
tmpfs 122.9M 24.0K 122.9M 0% /var
tmpfs 122.9M 4.0K 122.9M 0% /tmp
What's interesting is that, last week, I had an external SSD drive attached via USB to the Pi, and didn't have a single freeze. I've now gone back to a USB stick, and the freezing has started again. I'm going to switch back to SSD at the weekend and see if it goes away again.
I haven't run out of space this time, so must be something else. Logs don't seem to show any oddities either.
One thing I have noticed is that I can SSH into the Pi and do a killall xbmc.bin to fix the freeze if I do it within about 15 seconds of the video freezing. If I wait any longer, I can't SSH.
RE: OpenELEC Testbuilds for RaspberryPi Part 2 - h.udo - 2014-02-12
Sounds like a process eating all the available memory. ^^
RE: OpenELEC Testbuilds for RaspberryPi Part 2 - doveman2 - 2014-02-12
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'm not sure if my Emprex remote uses those keycodes though and lircmap.xml shows:
<volumeplus>KEY_VOLUMEUP</volumeplus>
<volumeminus>KEY_VOLUMEDOWN</volumeminus>
http://trac.xbmc.org/ticket/14116#comment:19
Code:
I had a similar problem with a Microsoft MCE remote clone on Ubuntu 12.04 and XBMC 12.3. For anyone who's interested, a simple workaround is to redefine the remote's volume up and down buttons using xmodmap, and then change XBMC's keymaps accordingly. For example, enter the following in ~/.Xmodmap:
keycode 122 = F13
keycode 123 = F14
and the following in ~/.xbmc/userdata/keymaps/keyboard.xml:
<keymap>
<global>
<keyboard>
<f13>VolumeDown</f13>
<f14>VolumeUp</f14>
</keyboard>
</global>
</keymap>RE: OpenELEC Testbuilds for RaspberryPi Part 2 - dhead - 2014-02-12
(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?
Raspberry Pi builds doesn't include X.org so this is no go (and this solution only works for keyboards and not for keypress send by lirc).
From a quick googling I guess your remote recognized as keyboard.
Sadly the current state of keyboard support in XBMC is a bit of a mess, with the Raspberry Pi XBMC gets scancodes from the kernel, on OpenELEC x86_64 and i686 from X.Org and on regular Linux distribution from SDL, this is true for Frodo and Gotham.
I've already encountered with the issue you described and more but I didn't thought it worth reporting as the whole keyboard situation seems to me very funny and with Wayland soon on my desktop (Gnome 3.12 next month) I probably will have more issues.
RE: OpenELEC Testbuilds for RaspberryPi Part 2 - doveman2 - 2014-02-12
(2014-02-12, 21:16)dhead Wrote: Raspberry Pi builds doesn't include X.org so this is no go (and this solution only works for keyboards and not for keypress send by lirc).
From a quick googling I guess your remote recognized as keyboard.
Sadly the current state of keyboard support in XBMC is a bit of a mess, with the Raspberry Pi XBMC gets scancodes from the kernel, on OpenELEC x86_64 and i686 from X.Org and on regular Linux distribution from SDL, this is true for Frodo and Gotham.
I've already encountered with the issue you described and more but I didn't thought it worth reporting as the whole keyboard situation seems to me very funny and with Wayland soon on my desktop (Gnome 3.12 next month) I probably will have more issues.
OK, thanks, that's a shame, would be nice to fix this issue.
I'm not sure that my remote is recognised as a keyboard, at least I've never had to do anything with scancodes and I just use lircmap.xml and remote.xml.