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) - Milhouse - 2016-05-28 (2016-05-27, 23:04)Little_Kitty Wrote: i have the timeservers setup via the libreELEC settings These shouldn't be necessary unless your own network is the problem and your DHCP server is configured with an inaccurate timeserver. (2016-05-27, 23:04)Little_Kitty Wrote: When i turn on the PI it shows the wrong time. Wrong *time*, or wrong *date*? Having the wrong *time* would suggest you have an incorrect timezone. A date of January 1970 means you have no timeserver at all, or no internet connection. (edit: systemd will now set an approximate date - see post #681) A wrong *date* means the timeserver being used is not accurate, or not available. (2016-05-27, 23:04)Little_Kitty Wrote: It shows the time that the image was updated? like i put the latest from 26 may it shows 26 may. Just a guess - perhaps the kernel uses the date the kernel is built in the absence of any other time source? I see the following with tonight's #0527 build on an RPi3: Code: rpi22:~/.cache # journalctl The exact same time - May 27 21:07:10 - is also the initial date/time when booting the #0572 build on an RPi1: Code: rpi512:~/.cache # journalctl Not entirely sure how or where it gets the date/time from, but for it to be the exact same on two different devices booted at two different times is likely to be more than just a coincidence. Booting #0526 build on 27 May @ 23:53 on RPi3: Code: rpi22:~/.cache # journalctl Maybe this is a new behaviour in recent kernels... (2016-05-27, 23:04)Little_Kitty Wrote: is it correct NTPdate isnt installed? connmand handles ntp. What is the output from: Code: cat /storage/.cache/timezone RE: LibreELEC Testbuilds for RaspberryPi (Kodi 17.0) - Milhouse - 2016-05-28 New LibreELEC.tv Krypton build #0527: RPi / RPi2 (Supercedes previous build) Code: # uname -a Based on tip of LibreELEC.tv master (454d0a54, changelog) and tip of XBMC master (e18bd8d8, changelog) with the following modifications:
RE: LibreELEC Testbuilds for RaspberryPi (Kodi 17.0) - santope - 2016-05-28 (2016-05-27, 04:28)SeVreN2013 Wrote:(2016-05-27, 02:59)santope Wrote: I have got LibreELEC running, and downloaded the .tar, but I cannot find the "update" folder to copy it in. (2016-05-27, 12:13)ElectricPim Wrote:(2016-05-27, 02:59)santope Wrote: I am new to the whole RPI concept, so this is very basic question: Many thanks for your patience and your comprehensive replies to my newbie question. In the end I did it through the Raspberrian GUI file manager type of thing, but I had to change the permissions, from the command line. A good Linux exercise for me ! But I will also try your suggestions, just to learn. Another little question (this should be easy): Can I (should I) run LibreELEC from NOOBS ? RE: LibreELEC Testbuilds for RaspberryPi (Kodi 17.0) - Milhouse - 2016-05-28 (2016-05-28, 00:29)santope Wrote: Can I (should I) run LibreELEC from NOOBS ? It's possible to do so, but unless you plan on booting multiple operating systems there is no point in using NOOBS as you'll lose a lot of storage space and have a more complicated setup. If you need additional support it would be best to start a new thread so that this testing thread remains on topic. RE: LibreELEC Testbuilds for RaspberryPi (Kodi 17.0) - santope - 2016-05-28 (2016-05-28, 00:46)Milhouse Wrote:(2016-05-28, 00:29)santope Wrote: Can I (should I) run LibreELEC from NOOBS ? Sorry, I suppose my questions pertain to LibreELEC in general, not this test version. But I cannot test if I cannot load your test builds. And I don't find any option here to show hidden files and folders. However, back to topic: - I tried to play a MVC ISO file (the reason I came to this thread). It plays nicely, but only in 2D. Maybe to do with the fact that I am using a PC monitor (1080p 60Hz) and not a TV? I still expected to see an overlapping double picture or something - Other than that, and random freezes, the only thing I noticed is the left sliding menu that keeps sliding in and out of view before you can select anything. Thanks for the good work, RE: LibreELEC Testbuilds for RaspberryPi (Kodi 17.0) - Milhouse - 2016-05-28 (2016-05-28, 00:13)Milhouse Wrote: Maybe this is a new behaviour in recent kernels... This had me scratching my head, but this is why the default date appears to match the build date. Since systemd 229: Code: * On boot-up, when PID 1 detects that the system clock is behind the Since build #0522, systemd is being rebuilt during each incremental build while PR:382 (bump to systemd 230) remains unmerged upstream. Consequently the release date of systemd closely approximates to the date/time of the build in which it appears, because systemd is being rebuilt on a daily basis. Prior to build #0522, systemd was last built during a private (unreleased) clean build on May 20, when the systemd package was built at 12:40. If you were to boot the released build #0521 which did not need to rebuild systemd, you will see the default date is "May 20 12:40:32". When PR:382 merges upstream, systemd will be built once more and then subsequent incremental builds will no longer rebuild systemd, at which point the default date will no longer match (or approximate to) the build date. RE: LibreELEC Testbuilds for RaspberryPi (Kodi 17.0) - Milhouse - 2016-05-28 @Little_Kitty: Given the above, if you have set the correct timezone but still have incorrect time (your date is "correct" purely by chance, something that will stop being the case in future once systemd is not built on a daily basis, and probably will be incorrect if you reboot after midnight) then I can only imagine that you do not have a functioning internet connection and will need to look at the rest of your network to determine where the fault lies. RE: LibreELEC Testbuilds for RaspberryPi (Kodi 17.0) - TheShoe - 2016-05-28 (2016-05-27, 13:53)Shanyel Wrote:(2016-05-27, 06:45)TheShoe Wrote:(2016-05-27, 06:22)Milhouse Wrote: Is it just the time that is incorrect, and not also the date? Have you set the timezone correctly in Kodi? ok - so here's what solved it for me once the obvious was pointed out: 1: set country and timezone in Kodi 2: re-add pool.ntp.org in libreelec ntp settings 3: reboot and voila! interesting although Milhouse mentioned the ntp server should not need to be set, i still had to do it to get the correct time RE: LibreELEC Testbuilds for RaspberryPi (Kodi 17.0) - Milhouse - 2016-05-28 (2016-05-28, 04:53)TheShoe Wrote: interesting although Milhouse mentioned the ntp server should not need to be set, i still had to do it to get the correct time What I actually said: (2016-05-28, 00:13)Milhouse Wrote: These shouldn't be necessary unless your own network is the problem and your DHCP server is configured with an inaccurate timeserver. The default (fallback) servers are 0.pool.ntp.org, 1.pool.ntp.org, 2.pool.ntp.org, 3.pool.ntp.org, and will be used if there is no other timeserver configured in your network. If your network is specifying it's own timeserver via DHCP then you won't be using these default timeservers. However if your network timeserver is inaccurate then you need to configure static timeservers (as you have done) in order to override your DHCP server. Obviously the best option is to fix your DHCP server so that it uses an accurate timeserver, or no timeserver at all leaving your devices to use sane defaults. RE: LibreELEC Testbuilds for RaspberryPi (Kodi 17.0) - TheShoe - 2016-05-28 i did check the router and it's configured with pool.ntp.org and the TZ is set properly. should it be 0.pool.ntp.org ? RE: LibreELEC Testbuilds for RaspberryPi (Kodi 17.0) - Milhouse - 2016-05-28 pool.ntp.org is a cluster that dynamically resolves to multiple addresses for timeservers appropriate for your region - in effect, a load balancer, of sorts. See http://www.pool.ntp.org/en/use.html Even if your router is configured to use pool.ntp.org, what timeserver is your LibreELEC client configured to use - is LE being configured (by DHCP) to use pool.ntp.org, or is it using your router (ie. 192.168.0.x) as the timeserver? If the latter, is the ntpd daemon working correctly in your router? Is the time on your router accurate? In LE, try (where 192.168.0.x is your router address): Code: ntpd -wqd -p pool.ntp.org and see if you get valid replies, or timeouts (ctrl-c to end each run). Each time you run ntpd for pool.ntp.org you should query a different timeserver (0.pool.ntp.org etc. will also be random). RE: LibreELEC Testbuilds for RaspberryPi (Kodi 17.0) - User 99401 - 2016-05-28 (2016-05-28, 06:33)Milhouse Wrote: pool.ntp.org is a cluster that dynamically resolves to multiple addresses for timeservers appropriate for your region - in effect, a load balancer, of sorts. See http://www.pool.ntp.org/en/use.html Tried that. I do get replies from all pool.ntp.org clusters, though the date is incorrect... My router time is OK, checked also with windows 10 pc/laptop and time is synced correctly RE: LibreELEC Testbuilds for RaspberryPi (Kodi 17.0) - makruiten - 2016-05-28 I posted this a while back, but there were some other discussions going on, so I don't think it was really noticed (sorry if I missed any replies). The problem I have for quite some time now, on two different RPis, is that I need to disable and re-enable UPnP and AirPlay every time I have rebooted my device. If I don't, UPnP is not detected in my network and AirPlay won't accept incoming connections. Since it's two devices having the same issue, it's either something in my network or something with the software. Is anybody else experiencing this? RE: LibreELEC Testbuilds for RaspberryPi (Kodi 17.0) - ElectricPim - 2016-05-28 (2016-05-28, 00:29)santope Wrote: Many thanks for your patience and your comprehensive replies to my newbie question. That's the spirit! santope Wrote:But I will also try your suggestions, just to learn. Yes, I run from NOOBS, you can update openelec to libreelec. I created a small bash script that will update LibreElec to the lastest Millhouse build. Run it on your PC/Laptop in your LAN, it uses SSH and lynx is needed (apt-get install lynx) Code: #!/bin/bash You can also run it with a build number to revert to an older build. Code: le_update.sh 0522 // will revert to the #0522 build RE: LibreELEC Testbuilds for RaspberryPi (Kodi 17.0) - popcornmix - 2016-05-28 (2016-05-28, 13:14)makruiten Wrote: I posted this a while back, but there were some other discussions going on, so I don't think it was really noticed (sorry if I missed any replies). The problem I have for quite some time now, on two different RPis, is that I need to disable and re-enable UPnP and AirPlay every time I have rebooted my device. If I don't, UPnP is not detected in my network and AirPlay won't accept incoming connections. Since it's two devices having the same issue, it's either something in my network or something with the software. Is anybody else experiencing this? It would be useful to confirm if this is a regressions or if it has never worked. e.g. does the LE Jarvis stable build have the same issue? If it does, then does the OE Isengard stable build have this issue? |