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) - popcornmix - 2016-09-01 (2016-09-01, 05:27)thegooddoctor Wrote: -Skipping backwards now shows buffering window (my wire network is uncongested and optimized - there has never been an issue previously). That is a deliberate skin change. Estuary didn't previous indicate buffering at all. There is always buffering after a seek, but with fast network/disk it just takes a fraction of a second. I must admit I'd prefer the buffering overlay on skin held off for about a second before appearing as it is ugly just popping up for half a second. RE: LibreELEC Testbuilds for RaspberryPi (Kodi 17.0) - outcave - 2016-09-01 OpenVPN on LibreELEC (Krypton) v7.90.004 ALPHA on a Raspberry Pi 2 Hi. I'm trying to connect to Hide.me VPN service with OpenVPN on LibreELEC (Krypton) v7.90.004 ALPHA on a Raspberry Pi 2. I have this error: Code: LibreELEC:~/.kodi/addons/service.vpn.manager/HideMe # openvpn Milan\ \(UDP\).ovpn May be some Root CA missed in LibreSSL? Just for your info, with OpenELEC 6.0.3 and with LibreELEC (Jarvis 16.1) v7.0.2 I was able to connect with the exactly same .ovpn file. I hope in your help. Thanks. RE: LibreELEC Testbuilds for RaspberryPi (Kodi 17.0) - Milhouse - 2016-09-01 This isn't the 7.90.004 support thread. Test with a build from this thread, or post your problem on the LibreELEC forum. Although to be honest it appears more likely that it's the server certificate that is invalid, as per the error message. 7.90.004 uses a different version of LibreSSL to OpenELEC 6.0.3, this could be one of many security issues "fixed". RE: LibreELEC Testbuilds for RaspberryPi (Kodi 17.0) - hansdd - 2016-09-01 Hi. Since the build #0827 the addon "radio" broke down. In the log file (kodi.log) the follow message was show: 07:18:19 31748.623047 T:1362097056 NOTICE: [xbmcswift2] Request for "/" matches rule for function "show_root_menu" 07:18:22 31752.257812 T:1503204256 NOTICE: [xbmcswift2] Request for "/stations/my/" matches rule for function "show_my_stations" 07:18:22 31752.257812 T:1503204256 NOTICE: [plugin.audio.radio_de] __add_stations started with 11 items 07:18:26 31756.201172 T:1362097056 NOTICE: [xbmcswift2] Request for "/station/2255" matches rule for function "get_stream_url" 07:18:26 31756.203125 T:1362097056 NOTICE: [plugin.audio.radio_de] get_station_by_station_id started with station_id=2255 07:18:26 31756.203125 T:1362097056 NOTICE: [plugin.audio.radio_de] __api_call started with path=broadcast/getbroadcastembedded, param={'broadcast': '2255'} 07:18:26 31756.203125 T:1362097056 NOTICE: [plugin.audio.radio_de] __urlopen opening url=http://radio.de/info/broadcast/getbroadcastembedded?broadcast=2255 07:18:26 31756.351562 T:1362097056 NOTICE: [plugin.audio.radio_de] get_stream_url result: http://c22033-l.i.core.cdn.streamfarm.net/22001mdr1sachsen/live/3087mdr_sachsen/live_de_128.mp3 07:18:28 31757.599609 T:1961611264 ERROR: exception in CApplication:rocess() when the playback will start, there some stripe on the display, and the system reboot after few seconds. RE: LibreELEC Testbuilds for RaspberryPi (Kodi 17.0) - bmonster - 2016-09-01 My live TV and Radio has always been perfect, using rbp3 and media portal client. RE: LibreELEC Testbuilds for RaspberryPi (Kodi 17.0) - thegooddoctor - 2016-09-02 (2016-09-01, 12:53)popcornmix Wrote:I agree - for as brief as the buffering window appears it is annoying(2016-09-01, 05:27)thegooddoctor Wrote: -Skipping backwards now shows buffering window (my wire network is uncongested and optimized - there has never been an issue previously). It needs to be held off for a certain period, or have the option to deactivate the window RE: LibreELEC Testbuilds for RaspberryPi (Kodi 17.0) - zaphod24 - 2016-09-02 Over the last few weeks I've noticed that when an overlay pops up when hitting the info button or when a commercial is about to skip and while watching recorded mpeg2 1080i60 content, sometimes my Vizio TV will turn blue for a bit and then say "invalid format". If I switch to another input and back or turn the tv on and off it will show a picture again and continue to playback fine. I have tried all kinds of settings, adjust display rate on and off, sync playback to display on and off. Nothing seemed to help. Finally tonight I tried various options for deinterlacing. My testing indicates that off and mmal Bob are ok but as soon as I switch to mmal advanced I can reproduce the problem by hitting the info button a few times to pop the info display up and take it away. Not sure what that indicates other than mmal advanced and an overlay seem to produce an odd resolution or refresh rate for some period of time which confuses my tv. For now I can switch to mmal Bob and prevent the issue. RE: LibreELEC Testbuilds for RaspberryPi (Kodi 17.0) - Milhouse - 2016-09-02 (2016-09-01, 20:52)hansdd Wrote: Hi.Do you have the crashlog? Most likely candidate for the breakage is PR10236. RE: LibreELEC Testbuilds for RaspberryPi (Kodi 17.0) - Milhouse - 2016-09-02 New LibreELEC.tv Krypton build #0901: RPi / RPi2 (Supercedes previous build) Code: # uname -a Based on tip of LibreELEC.tv master (d416dad6, changelog) and tip of XBMC master (f39d849f, changelog) with the following modifications:
RE: LibreELEC Testbuilds for RaspberryPi (Kodi 17.0) - Milhouse - 2016-09-02 @BigNoid & @smp1 - are USB game controllers still causing crashes/weird stacktraces in the latest build (not that I've intentionally fixed anything, but there have been some peripheral.joystick updates in the last few builds). Thanks. RE: LibreELEC Testbuilds for RaspberryPi (Kodi 17.0) - BigNoid - 2016-09-02 (2016-09-02, 07:18)Milhouse Wrote: @BigNoid & @smp1 - are USB game controllers still causing crashes/weird stacktraces in the latest build (not that I've intentionally fixed anything, but there have been some peripheral.joystick updates in the last few builds). Thanks. Still crashes: Code: Thread 1 (Thread 0x664ff3a0 (LWP 6342)): RE: LibreELEC Testbuilds for RaspberryPi (Kodi 17.0) - outcave - 2016-09-02 (2016-09-01, 18:42)Milhouse Wrote: This isn't the 7.90.004 support thread. Test with a build from this thread, or post your problem on the LibreELEC forum. Although to be honest it appears more likely that it's the server certificate that is invalid, as per the error message. 7.90.004 uses a different version of LibreSSL to OpenELEC 6.0.3, this could be one of many security issues "fixed". Hi Mr. Milhouse. I'm quit sure that if I use the lastest build I will have the same problem.... The problem is that the Hide.me certificate will expires in year 2046 and the LibreSSL 2.3.x will not work well on the Raspberry Pi due to "Year 2038 bug". See here: https://github.com/libressl-portable/portable/issues/207 This is the reason that with oldest version such as OpenELEC 6.0.3 or with LibreELEC (Jarvis 16.1) v7.0.2 I did not have this problem (beacuse the OpenSSL / LibreSSL is older version). So, I expect, that all certificates that will expires after 03:14:07 UTC on 19 January 2038 will have the same problem on all LibreELEC with Kodi 17.0. Hope in a fix. Thanks. RE: LibreELEC Testbuilds for RaspberryPi (Kodi 17.0) - popcornmix - 2016-09-02 (2016-09-02, 06:06)zaphod24 Wrote: Not sure what that indicates other than mmal advanced and an overlay seem to produce an odd resolution or refresh rate for some period of time which confuses my tv. For now I can switch to mmal Bob and prevent the issue. Overclocking will likely resolve this. sdram_freq, core_freq and v3d_freq could all help (roughly in that order of likelihood). RE: LibreELEC Testbuilds for RaspberryPi (Kodi 17.0) - zaphod24 - 2016-09-02 (2016-09-02, 13:29)popcornmix Wrote:(2016-09-02, 06:06)zaphod24 Wrote: Not sure what that indicates other than mmal advanced and an overlay seem to produce an odd resolution or refresh rate for some period of time which confuses my tv. For now I can switch to mmal Bob and prevent the issue. Thanks for the suggestions. Any suggestions for values to start with and if overvolting is needed? RE: LibreELEC Testbuilds for RaspberryPi (Kodi 17.0) - Milhouse - 2016-09-02 (2016-09-02, 12:10)outcave Wrote:(2016-09-01, 18:42)Milhouse Wrote: This isn't the 7.90.004 support thread. Test with a build from this thread, or post your problem on the LibreELEC forum. Although to be honest it appears more likely that it's the server certificate that is invalid, as per the error message. 7.90.004 uses a different version of LibreSSL to OpenELEC 6.0.3, this could be one of many security issues "fixed". Thanks. Yes, this is a 32-bit OS issue (more specifically, a 32-bit ABI issue). Your certificate would be fine in a 64-bit OS, indeed there is no problem with the sample certificates shown on github when testing the latest LibreELEC Generic (x86_64) builds. However there are no immediate plans for a 64-bit version of LibreELEC for RPi (which would only support RPi3 hardware), so fixing this in libressl to support post-2038 dates on 32-bit platforms is the only practical solution. I would expect this to be resolved in libressl at some point as it's going to affect a lot of platforms, but until then it might be easier for certificate authorities to avoid using outlandish post-2038 expiry dates. |