OpenELEC Testbuilds for RaspberryPi - 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: OpenELEC Testbuilds for RaspberryPi (/showthread.php?tid=140518) 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
|
RE: OpenELEC Testbuilds for RaspberryPi - Milhouse - 2013-03-09 (2013-03-09, 21:54)doveman2 Wrote: Anyway, I overwrote the files on the SD with those from rbej's latest build now and tested with the Update files (so basically updating to the same version again) and that worked, so unless anyone else has a problem it's probably not worth looking at the kernel. OK, agreed... (2013-03-09, 21:54)doveman2 Wrote: More importantly, it no longer works for me. Maybe why the PVR stuff has been reverted, new build just uploaded (see post before yours). It seemed to be working fine for me, but then I'm not using any of the PVR stuff. RE: OpenELEC Testbuilds for RaspberryPi - doveman2 - 2013-03-09 (2013-03-09, 21:57)MilhouseVH Wrote: Maybe why the PVR stuff has been reverted, new build just uploaded (see post before yours). It seemed to be working fine for me, but then I'm not using any of the PVR stuff. I did kill {tvheadend PID} and then kill {xbmc.bin PID} and then xbmc restarted and managed to finish the "Loading EPG data" but then froze right after that. I've posted the two logs here http://pastebin.com/ez692M1w (before killing) and here http://pastebin.com/vYenz3JJ (after killing and XBMC restarting). I'll try the newest build though, as you say maybe the PVR stuff is the problem RE: OpenELEC Testbuilds for RaspberryPi - rbej - 2013-03-09 PVR master branch not work properly with Xbmc Frodo Branch. I back to PVR Frodo Branch. If you see log network message on startup, please dont worry. This is correct. https://github.com/OpenELEC/OpenELEC.tv/pull/2031 RE: OpenELEC Testbuilds for RaspberryPi - doveman2 - 2013-03-09 Cool, seems to be OK again with the latest update RE: OpenELEC Testbuilds for RaspberryPi - Milhouse - 2013-03-10 (2013-03-09, 20:55)MilhouseVH Wrote:(2013-02-27, 09:01)rbej Wrote: - remove "Suspend" and "Hibernate" from XBMC shutdown menu (taken from XBIAN) It turns out that the Raspberry Pi is using the default power interface, CNullPowerSyscall, and is getting all power options by default: Code: virtual bool CanPowerdown() { return true; } Rather than patch individual skins, it would be better/easier to patch the default power interface when building for the Pi, thus correctly disabling Suspend/Hibernate for all skins... the following patch achieves this: Code: diff --git a/xbmc/powermanagement/PowerManager.h b/xbmc/powermanagement/PowerManager.h RE: OpenELEC Testbuilds for RaspberryPi - sraue - 2013-03-10 (2013-03-09, 20:55)MilhouseVH Wrote:(2013-02-27, 09:01)rbej Wrote: - remove "Suspend" and "Hibernate" from XBMC shutdown menu (taken from XBIAN) the problem here is xbmc calls "upower" to get if suspend/hibernate is supported. because upower depends on consolekit, which depends (still) on x11 librarys we dont include upower (also because supend/hibernate is not supported). this also means xbmc shows this options which are set as default because xbmc dont get the requested info RE: OpenELEC Testbuilds for RaspberryPi - sraue - 2013-03-10 (2013-03-10, 00:57)MilhouseVH Wrote: It turns out that the Raspberry Pi is using the default power interface, CNullPowerSyscall, and is getting all power options by default: will try this here on various systems with and without working upower, if it works i will report back so you can make a PR with this changes (or i help you with this) - nice find. RE: OpenELEC Testbuilds for RaspberryPi - Milhouse - 2013-03-10 (2013-03-10, 01:18)sraue Wrote: will try this here on various systems with and without working upower, if it works i will report back so you can make a PR with this changes (or i help you with this) - nice find. It works as a patch for a Pi, that's all I've tested with. (2013-03-10, 01:16)sraue Wrote: the problem here is xbmc calls "upower" to get if suspend/hibernate is supported. because upower depends on consolekit, which depends (still) on x11 librarys we dont include upower (also because supend/hibernate is not supported). this also means xbmc shows this options which are set as default because xbmc dont get the requested info The problem is there is no valid power management option for the Pi, so it always uses the default null provider. Here is the code to determine a suitable option: Code: #if defined(TARGET_DARWIN) None of the Linux tests are performed, not even HAS_HAL, so I'm guessing HAS_DBUS is not defined. On a Pi, m_instance is always NULL, so is assigned an instance of CNullPowerSyscall. So the question becomes - maybe one for Popcornmix - does the Pi have any kind of power management interface, and if so should the above test be modified rather than patching the properties of the default? Edit: On further investigation, _LINUX and HAS_DBUS are both defined, but HAS_HAL isn't, so none of the four conditions tested within __LINUX && HAS_DBUS evaluate to true on a R-Pi, thus explaining why m_instance is always null before being assigned the default instance. RE: OpenELEC Testbuilds for RaspberryPi - Milhouse - 2013-03-10 (2013-03-10, 00:57)MilhouseVH Wrote: Rather than patch individual skins, it would be better/easier to patch the default power interface when building for the Pi, thus correctly disabling Suspend/Hibernate for all skins... the following patch achieves this: Patching the power management instance with correct options for the Raspberry Pi also means that the Power Saving settings screen no longer offers Suspend and Hibernate, which is a nice bonus. RE: OpenELEC Testbuilds for RaspberryPi - Milhouse - 2013-03-10 (2013-03-10, 01:18)sraue Wrote: will try this here on various systems with and without working upower, if it works i will report back so you can make a PR with this changes (or i help you with this) - nice find. PR #2403. RE: OpenELEC Testbuilds for RaspberryPi - popcornmix - 2013-03-10 (2013-03-10, 05:24)MilhouseVH Wrote: PR #2403.404. RE: OpenELEC Testbuilds for RaspberryPi - rbej - 2013-03-10 Very good patch. Works well. RE: OpenELEC Testbuilds for RaspberryPi - Milhouse - 2013-03-11 (2013-03-10, 21:43)popcornmix Wrote:(2013-03-10, 05:24)MilhouseVH Wrote: PR #2403.404. I did just get a 404 on my phone when clicking the link, but it's loading fine on my desktop... maybe an intermittent github problem? RE: OpenELEC Testbuilds for RaspberryPi - Milhouse - 2013-03-11 (2013-03-11, 03:03)Krist0ina Wrote: Google told me to use either sudo shutdown -h or sudo halt but If I use either command I just get an error saying sudo not found In OpenELEC you don't need sudo as you're already root (the super-user). However neither shutdown or halt exist in OpenELEC, so presumably you're using instructions for another distribution. "poweroff -f" is the command to shutdown OpenELEC, and "reboot" to reboot. RE: OpenELEC Testbuilds for RaspberryPi - Milhouse - 2013-03-11 (2013-03-10, 05:24)MilhouseVH Wrote:(2013-03-10, 01:18)sraue Wrote: will try this here on various systems with and without working upower, if it works i will report back so you can make a PR with this changes (or i help you with this) - nice find. I've also just updated this PR (though I think I may have messed it up slightly by trying to squash my commits!) to include ifdef's for the Raspberry Pi, so that original suspend/hibernate behaviour is restored for non-Pi systems. The patch is here, and maybe this patch could be accepted into xbmc master at some point (unless there is a better solution). |