v17 LibreELEC Testbuilds for RaspberryPi (Kodi 17.0) - 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: v17 LibreELEC Testbuilds for RaspberryPi (Kodi 17.0) (/showthread.php?tid=269814) 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
|
RE: LibreELEC Testbuilds for RaspberryPi (Kodi 17.0) - asavah - 2016-06-26 @Milhouse Quote:gcc: update to 5.4.0 Is this true for the PI too? AFAIK there were Kodi related issues with gcc 5.3.x edit: on ARM. Everything works fine? RE: LibreELEC Testbuilds for RaspberryPi (Kodi 17.0) - Milhouse - 2016-06-26 (2016-06-26, 12:04)asavah Wrote: Is this true for the PI too? Both Pi1/Zero and Pi2/3, yes. (2016-06-26, 12:04)asavah Wrote: AFAIK there were Kodi related issues with gcc 5.3.x edit: on ARM. Seems to, but this is a test build thread, so you tell me. RE: LibreELEC Testbuilds for RaspberryPi (Kodi 17.0) - asavah - 2016-06-26 @Milhouse If memory serves Kodi was crashing on arm when trying to access any database. The folks on alarm (ARCH Linux ARM) forums told that it's a gcc bug, alarm used gcc 5.1.x to build kodi, while the rest of the packages were built with 5.3.x. RE: LibreELEC Testbuilds for RaspberryPi (Kodi 17.0) - Milhouse - 2016-06-26 I've not seen any problems accessing MySQL or SQLite with #0625 built using gcc 5.4.0. Also, you know LE has been using gcc 5.3.0 since December 2015? But then we build the whole of LE with the same gcc. RE: LibreELEC Testbuilds for RaspberryPi (Kodi 17.0) - asavah - 2016-06-26 (2016-06-26, 12:36)Milhouse Wrote: Also, you know LE has been using gcc 5.3.0 since December 2015? But then we build the whole of LE with the same gcc. Thanks for the info, guess I missed the bump, I thought that OE/LE were still using 4.9.x for ARM, that's why I asked. 5.3.x (or whatever ubuntu 16.04 has now) has been flawless on x86. RE: LibreELEC Testbuilds for RaspberryPi (Kodi 17.0) - metaron - 2016-06-26 I'm having problems with intermittent startup using #618 (I use lirc) on both a b+ and a zero. On the b+ I'm mounting storage via NFS, it's local on the zero. The b+ has a wired connection, the zero uses wireless. When the 'failure occurs, #618 manages to boot, display the animation (a 'blue' kodi animation on the b+ and a 'libreelec' animation on the zero?) then sits there with a fully black screen (i.e. before the kodi splash screen appears). When in the 'locked' state, you can ssh into the box, but ssh locks up (even ctrl-c won't exit the session) before printing the LibreELEC banner (although "Warning: untrusted X11 forwarding setup failed: xauth key data not generated" is generated when appropriate so it seems the ssh daemon is running). It feels like sshd isn't able to sporn a shell for some reason. Normally I run with 'Wait for network before starting kodi' turned on with a 10 second timeout (I use a shared sql database), but you can sit forever waiting for kodi to start. I've just turned it off via the GUI and the problem has re-occured so it doesn't seem to be related to this feature. It seems that if I ssh into the box while the splashscreen animation is running (a question of timing) the box will always boot up properly. If I wait until the animation has finished playing ssh will only connect properly if the fault doesn't occur. In locked-up cases, using the nfs mounted storage partition on the b+ I can see .kodi/temp/kodi.log but it hasn't been updated since the last run - so it doesn't look like a kodi related thing - more LibreELEC / systemd. Any ideas what I should try next to enable some useful remotely accessible logging? Edit: I've managed to get something useful out of a 'locked up' box by bypassing the shell (ssh root@testpi journalctl -b > journal.txt) not sure what it's telling me: http://pastebin.com/PjGqbdzJ Edit2: On the grounds that "systemctl restart kodi" runs the splash animation and the lockup seems to occur between the animation and the 'fixed' kodi splashscreen, I've disabled the animation: (touch /storage/.config/splash.disable). No lockups yet... Will post back if it re-occurs. RE: LibreELEC Testbuilds for RaspberryPi (Kodi 17.0) - MikeKL - 2016-06-26 #0625 and Kodi Estuary GUI Lock-up when using iplayerwww add-on I was moving around various iplayerwww catch-up options avalable in GUI before selecting Watch Live option where Kodi appeared to lock-up however after reasoably long wait (5mins?) GUI recovered kodi Log Don't believe issue is specifically related to latest nightly or use of iplayerwww add-on as have noticed GUI Estuary lock-up couple of times before for a few minutes (very infrequent) and didnt think to ssh and grab log file. PS I had just updated kodi to #0625 from #0624 less than 15mins before noticing this issue in case it has any releavance? RE: LibreELEC Testbuilds for RaspberryPi (Kodi 17.0) - popcornmix - 2016-06-26 (2016-06-26, 14:15)MikeKL Wrote: #0625 and Kodi Estuary GUI Lock-up when using iplayerwww add-on Would need a debug log. You can see a 15m gap in log, but no real clues about what was going on. There are some errors about missing controls - are you using Estuary? Does the stall occur repeatably? Which was the first build with the problem? RE: LibreELEC Testbuilds for RaspberryPi (Kodi 17.0) - loggio - 2016-06-26 Kodi freezes if you go to the EPG Timeline, watch LiveTV fullscreen and push 'back' to exit Fullscreen to go to the epg window RE: LibreELEC Testbuilds for RaspberryPi (Kodi 17.0) - asavah - 2016-06-26 (2016-06-26, 12:36)Milhouse Wrote: I've not seen any problems accessing MySQL or SQLite with #0625 built using gcc 5.4.0. So I investigated this a little more and I share my findings to save you a possible future headache and to possibly bring this to the attention of some skilled Kodi dev who may actually fix the issue. The crash is still present with gcc-5.4.0, you have not stumbled into it because of this https://github.com/LibreELEC/LibreELEC.tv/blob/master/packages/mediacenter/kodi/package.mk#L240 --disable-optimizations If kodi is build with -O2 or higher for arm it crashes on the start. The issue is here http://trac.kodi.tv/ticket/16609 The patch provided in the ticket https://github.com/zpon/xbmc-imx-git/blob/master/GetDatabaseResults.patch effectively allows kodi to run on arm if built with --enable-optimizations. The crash does not happen on x86_64. I can't tell if it's gcc bug (most likely) or kodi bug. I'll update the ticket with my findings, hope someone with good knowledge of gcc can either fix this in Kodi or file a proper bug report to gcc devs. RE: LibreELEC Testbuilds for RaspberryPi (Kodi 17.0) - Milhouse - 2016-06-26 Thanks. If a fix is ever implemented (either Kodi or gcc) then we could consider using --enable-optimizations. RE: LibreELEC Testbuilds for RaspberryPi (Kodi 17.0) - MikeKL - 2016-06-26 (2016-06-26, 14:23)popcornmix Wrote:Yes using Estuary, not easy to repeat stall at all, I switched on debug-log after providing previous log and tried to recreate the stall but unsuccessful.(2016-06-26, 14:15)MikeKL Wrote: #0625 and Kodi Estuary GUI Lock-up when using iplayerwww add-onWould need a debug log. You can see a 15m gap in log, but no real clues about what was going on. Then left kodi running with debug on and switched-off TV, when came back after 1hr or more unable to wake up kodi with either remote or a bluetooth keyboard. (similar to stall?) Here is debug-log before I rebooted pi, for what its worth. Really not sure when first noticed stall, but definitely seen it in earlier build, than latest builds. RE: LibreELEC Testbuilds for RaspberryPi (Kodi 17.0) - Milhouse - 2016-06-26 New LibreELEC.tv Krypton build #0626: RPi / RPi2 (Supercedes previous build) Code: # uname -a Based on tip of LibreELEC.tv master (457702ad, changelog) and tip of XBMC master (b101751e, changelog) with the following modifications:
RE: LibreELEC Testbuilds for RaspberryPi (Kodi 17.0) - igenena - 2016-06-27 HI Milhouse, I am on Raspberry Pi3 , using libreelec K17 since #618 till #626, the addon PVR Stalker Client 2.5.0 Search function not working, the search function in the PVR does not allow for writing in any string, but rather is showing me external Directories of my RPI (a directory for an ext4 partition on my SD or if i add my USB HDDs, they show up as well). Its pretty odd and tiring, i cant search up a channel or a program, within 2500 channels i have! When i try from MAC OS, Kodi build 17 as well, the add on is behaving well, and indeed the search function works perfectly! I opened a thread in Stalker client middleware forum, but i was told to open in PVR support as the search function might not be an add on function, but rather a Kodi's only. and that might be true, as on MAC the builds are from Kodi, while on RPi3 its the nightly we use here (Thanks to your excellent work). PS: search anywhere else in Kodi works fine, only within the stalker client it doesnt. RE: LibreELEC Testbuilds for RaspberryPi (Kodi 17.0) - smp1 - 2016-06-27 Build #0626 broke the DVD playback again. This time the navigation in DVD menus does not work on many titles I tested. The sample I posted here is a good example. |