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-04 (2016-09-03, 23:12)zaphod24 Wrote: Had a little more time to test today. Even with 0902, a modest overclock is needed to stop the "invalid format" issue. Without it, the problem still occurs. Works just fine with the modest overclock so I am calling that a win. I'd be interested which part of the overclock is required. I suspect it is the sdram part, so you could try removing core_freq and v3d_freq from config.txt. LibreELEC Testbuilds for RaspberryPi (Kodi 17.0) - bagofcrap24 - 2016-09-04 Just noticed a small issue which must have started over the last few weeks. I'll try and narrow the exact build. My rpi3 goes through an AVR (pioneer vsx 922) The AVR is set to not pass through HDMI when in standby. When I switch off the AVR at the end of the night, the HDMI signal is correctly not passed through. However if the pi is rebooted whilst the AVR is off (happens automatically as i have a cron job to do this at 5am daily) then as the pi reboots, it brings the HDMI back up and starts passing it through to the TV whilst the AVR remains in standby. I don't remember seeing this behaviour before the last few weeks so uncertain if it's a pi issue or AVR issue so I'll try going back through builds to see if it stops. Just reporting now to see if anyone else can confirm. Sent from my ONEPLUS A3003 RE: LibreELEC Testbuilds for RaspberryPi (Kodi 17.0) - zaphod24 - 2016-09-04 (2016-09-04, 13:11)popcornmix Wrote:(2016-09-03, 23:12)zaphod24 Wrote: Had a little more time to test today. Even with 0902, a modest overclock is needed to stop the "invalid format" issue. Without it, the problem still occurs. Works just fine with the modest overclock so I am calling that a win. Using 0903 it looks like the only required overclock is the ram at 500. RE: LibreELEC Testbuilds for RaspberryPi (Kodi 17.0) - pyrodex - 2016-09-04 I am seeing a large amount of ERRORs in the logs for CEC when I have it disabled on my RPI3. http://sprunge.us/OFXb RE: LibreELEC Testbuilds for RaspberryPi (Kodi 17.0) - Milhouse - 2016-09-04 (2016-09-04, 18:49)pyrodex Wrote: I am seeing a large amount of ERRORs in the logs for CEC when I have it disabled on my RPI3. Read above, could be the name change for the CEC settings file. Disable it again (so the disabled setting is saved to the new settings file), or wait until tonight's update when it should be disabled again after you update. RE: LibreELEC Testbuilds for RaspberryPi (Kodi 17.0) - popcornmix - 2016-09-04 (2016-09-04, 17:02)zaphod24 Wrote: Using 0903 it looks like the only required overclock is the ram at 500. Thanks. Does removing the sdram overclock and adding: Code: v3d_limiter=0x1080f1 RE: LibreELEC Testbuilds for RaspberryPi (Kodi 17.0) - smp1 - 2016-09-05 Build #0904 is broken - major stuttering with any video. RE: LibreELEC Testbuilds for RaspberryPi (Kodi 17.0) - Milhouse - 2016-09-05 (2016-09-05, 06:31)smp1 Wrote: Build #0904 is broken - major stuttering with any video. Not really seeing that here (although I haven't had much time to test) - can you post a debug log? RE: LibreELEC Testbuilds for RaspberryPi (Kodi 17.0) - Milhouse - 2016-09-05 New LibreELEC.tv Krypton build #0904: RPi / RPi2 (Supercedes previous build) Code: # uname -a Based on tip of LibreELEC.tv master (3be9cfe3, changelog) and tip of XBMC master (5bcf9ba7, changelog) with the following modifications:
RE: LibreELEC Testbuilds for RaspberryPi (Kodi 17.0) - smp1 - 2016-09-05 (2016-09-05, 06:38)Milhouse Wrote:http://sprunge.us/KcRL(2016-09-05, 06:31)smp1 Wrote: Build #0904 is broken - major stuttering with any video. RE: LibreELEC Testbuilds for RaspberryPi (Kodi 17.0) - Milhouse - 2016-09-05 OK yes, lots of stutter when using MMAL, but OK with OMX. Edit: With only MMAL enabled and playing an h264/720p/23.976fps video, in the PlayerDebug overlay I see "drop" increasing by 1 every 1 second, while playback frame rate is about 2 or 3 fps. With SD/25fps material I don't see "drop" increasing, but playback is still very choppy. RE: LibreELEC Testbuilds for RaspberryPi (Kodi 17.0) - Milhouse - 2016-09-05 PR10400 is likely the cause of the stutter. RE: LibreELEC Testbuilds for RaspberryPi (Kodi 17.0) - Milhouse - 2016-09-05 Here's build #0904x with fix for PR10400: RPi / RPi2 RE: LibreELEC Testbuilds for RaspberryPi (Kodi 17.0) - outcave - 2016-09-05 (2016-09-02, 16:05)Milhouse Wrote:(2016-09-02, 15:31)outcave Wrote: and then I remain screwed .... Hi again. I don't think the certificate authority industry should be mindful of this issue, the problem is LibreSSL, OpenSSL works fine! Hide.me answered to me that the certificate date problem is on LibreSSL and not with OpenSSL or with PolarSSL. They "fully support only the official OpenVPN community distribution and that one is supposed to be linked with OpenSSL or PolarSSL ( mBed TLS ), not LibreSSL. The say more: "In OpenSSL, versions above 1.0.0, this bug is fixed and 32bit machines/OSes may validate any date constraint. OpenSSL uses it's own date routines and does not depend on the OS". Then, they will not reissue a new certificate beacuse of LibreSSL... Well, I think Hide.me right, it's not their problem and they are right the other that issue certificate with date more then 2038. I do not want to debate, but why LibreELEC choose to use LibreSSL instead on the "classic" OpenSSL? May be the word "LIBRE" is more fashionable then "OPEN"? Anyway, to summurize, LibreSSL on 32bit OS (such as Raspberry Pi, Raspberry Pi 2, and so on...) will not support Certificates issued with date more then 2038, it seem that they are not interested to solve the issue, so the problem will remain in LibreELEC. I hope and I expect the LibreELEC community/devolopers will seriously evaluete this problem/limitation and will move again to OpenSSL. Thanks! RE: LibreELEC Testbuilds for RaspberryPi (Kodi 17.0) - Milhouse - 2016-09-05 Any project using current LibreSSL with Linux 32-bit is going to have this issue, which includes new OpenELEC builds. It's an issue for LibreSSL/Linux to sort out between themselves. Not using LibreSSL on Linux is of course an option, but not a decision we'll be taking overnight - there are sound reasons not to use OpenSSL anymore, and flip-flopping back and forth between LibreSSL and OpenSSL every time there's an issue is not really a workable solution. Since Linux isn't going to change it's 32-bit ABI any time soon to support 64-bit time_t, the only solution is for LibreSSL to implement their own time routines (as OpenSSL already does) but I suspect a degree of anti-Linux/pro-OpenBSD developer ego is manifesting itself here. |