+- 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 Part 2 (/showthread.php?tid=184866)
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
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
RE: OpenELEC Testbuilds for RaspberryPi Part 2 - dhead - 2013-11-30
(2013-11-28, 02:24)MilhouseVH Wrote: New OpenELEC Gotham build on dropbox.
...
As the black screen issue with Tvheadend resolved I stopped testing development builds but decided to test this to see what all the fuzz about popcornmix's speeds improvments.
To my suprise I'm getting only black screens when opening live tv streams (sd h264).
Almost forgot, XBMC is amazingly fast without overclocking, splendid work popcornmix
.Edit: this I did forgot, if I'm not wrong (python isn't my cup of tea) this commit should help the developers test Tvheadend even without DVB device, I've got a multicast ts file available to test if one need such.
https://github.com/tvheadend/tvheadend/commit/446e063b0c56f37639d79b0f03ad684e0270820e
Edit 2: Well, I was wrong, sort of, I'm getting black screen when playing video in general regardless if this live tv or local media (I only planed to test navigation speed and live tv).
I'm giving up for today.
RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Leopold - 2013-11-30
(2013-11-30, 05:30)MilhouseVH Wrote:(2013-11-28, 23:36)goRt Wrote: Hi,
Any chance of getting your builds supported with the devbuild update addon:
http://openelec.tv/forum/128-addons/49855
Thanks in advance
(2013-11-29, 06:55)Leopold Wrote: @MilhouseVH If you could put your builds into the same Dropbox folder and share the url to the folder then I can add it to the add-on. I've found your builds to be a big improvement over the latest OpenELEC release so it would be great if you could do that.
delinend has kindly set me up on his server at the following url:
http://netlir.dk/rbej/builds/index.php?dir=MilhouseVH/
and I'll be pushing my infrequent releases to that folder rather than continue with dropbox.
If you want to update the addon to reference this folder, fine with me.
@MilhouseVH Thanks. I've now added the url as an option called "MilhouseVH Builds".
If anyone is interested you can install the add-on called "OpenELEC Dev Update" from my repository xbmc.repo.leopold.zip.
This add-on makes it possible to install builds directly from the gui.
RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Milhouse - 2013-11-30
@Leopold: In case you're not aware, you need only drop the tar file into the Update (.update) folder and reboot for OpenELEC to upgrade, although of course this only works with recent Gotham builds so you'll still need to extract SYSTEM/KERNEL/MD5 when upgrading from Frodo. If you were able to determine if tar upgrading is supported, your addon would have to do less work (just download to .update, basically).
RE: OpenELEC Testbuilds for RaspberryPi Part 2 - evanspae - 2013-11-30
(2013-11-29, 13:42)popcornmix Wrote:(2013-11-29, 13:24)evanspae Wrote: As mentioned above this is playback of pre recorded .ts file on a well established system. This and other files plays fine on other xbmc clients (mainly 12.2 Frodo builds) both on PCs and stable raspberrypi openelec 3.2.3. There are not reception or file errors and it is a new problem on latest build.
If you seek to the end, is the sync off by the same amount as if you'd played from the beginning, or does seeking fix the sync?
Can you upload a file that has this problem and send me a link? The smaller the better, although in this case the drift may only be visible in a large file.
(Google drive is a good way of hosting a large file).
Skipping to various points and back through the file does not exhibit any obvious lipsync issues, it seems related to longer term drift of some description.
Unfortunately, the file is 9.5GB. I will see if I can post a clip but I am concerned that my edit prog TSMuxer and VideoRedo may not cut without some resyncing etc.
RE: OpenELEC Testbuilds for RaspberryPi Part 2 - popcornmix - 2013-11-30
(2013-11-30, 12:37)dhead Wrote: As the black screen issue with Tvheadend resolved I stopped testing development builds but decided to test this to see what all the fuzz about popcornmix's speeds improvments.
To my suprise I'm getting only black screens when opening live tv streams (sd h264).
I've seen a couple of reports of black screens on playback with latest gotham builds.
The solution seems to be to change something in settings.
Unfortunately I've not seen any good reports of what exactly cured the black screen.
"I played with the settings and got it working" is about all the information.
So, if you can fix it by playing with the settings, I'd like to know what fixed it. (Probably something in audio, but could be video).
The other option is to move .xbmc/userdata/guisettings.xml away, and see if that can play videos (you'll have to set up your non-default settings again).
RE: OpenELEC Testbuilds for RaspberryPi Part 2 - popcornmix - 2013-11-30
(2013-11-30, 04:32)allan87 Wrote: Bug? I have not been able to install add-ons with the recent build. It says "working", the text by the add-on says "downloading 0%", but both indicators soon disappear and then its back to square 1.
This may be related:
http://forum.xbmc.org/showthread.php?tid=179193
RE: OpenELEC Testbuilds for RaspberryPi Part 2 - allan87 - 2013-11-30
(2013-11-30, 14:56)popcornmix Wrote:Not sure. I tried a couple of earlier builds (earliest I got to was nov 20 from xbmcnightlybuilds) and the problem persisted. I ran a log while testing the nov. 20 build. I will try deleting the addon db, and also see if I can install from zip. If deleting the db does not fix it, I will report further.(2013-11-30, 04:32)allan87 Wrote: Bug? I have not been able to install add-ons with the recent build. It says "working", the text by the add-on says "downloading 0%", but both indicators soon disappear and then its back to square 1.
This may be related:
http://forum.xbmc.org/showthread.php?tid=179193
____________________
Update: Deleting the add-on db, as suggested in the thread referenced by popcornmix, fixed the problem. Thanks popcornmix.
RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Reddog999 - 2013-11-30
(2013-11-30, 05:59)MilhouseVH Wrote:(2013-11-29, 16:57)Reddog999 Wrote: @MilhouseVH
I know this is a big ask but how difficult/time consuming would it be for you to recompile your last build based on Linux 3.10.xx - I will understand your reluctance if this is not practical.
My reason for asking this is that with all the latest dev builds (except for Rbej's builds), the GPIO ir receiver does not work and I believe I have found that the culprit may be the Linux version.
I have tried at least a dozen different builds and my results are:
All official Openelec builds (e.g. 3.1.6, 3.1.7, 3.2.3) work - they use Linux version 3.10.xx
All Rbej Frodo and Gotham builds work - he uses version 3.10.xx
Chris Swan builds: all builds up to 13/9/13 (build version r15595) work - uses Linux version 3.10.xx
all builds from 14/9/13 (build version r15889) do not work - uses Linux version 3.11.xx
Your builds using Linux version 3.12.xx do not work
Of course it could be a Frodo/Gotham thing but since Rbej's Gotham releases use Linux version 3.10.xx that work, I believe it is more likely to be a driver problem that is packaged with the Linux kernel.
My other post gives some more information.
If I was a more able person I would make my own build but sadly I don't have the knowledge or the tools to do this.
Not likely, no - I'm more interested in publishing and testing upcoming fixes and new features rather than create custom builds that resolve specific issues like this. You should really work with the OpenELEC developers to try and resolve the issues that remain with the current 3.12.x kernel - if/when a patch becomes available I'll include it in my build.
Understood - no problem.
Quote:Have you tried copying a 3.10.x kernel to the latest Gotham build - does it work?
Already tried that by updating to your r16442 build and then copying (and renaming of course) rbej's KERNEL file (uses 3.10.20) from his latest build - would not start:
Error in prepare_sysroot: final_check: could not find system
Starting debugging shell.... type exit to quit
sh: can't access tty: job control turned off
Just one more question regarding the linux kernel - I assume this is what you use to compile the kernel? If so, should I not be directing my questions to popcornmix since I see his name in the commits?
RE: OpenELEC Testbuilds for RaspberryPi Part 2 - doveman2 - 2013-11-30
(2013-11-26, 21:04)popcornmix Wrote:(2013-11-26, 16:47)doveman2 Wrote: Is anyone finding that the audio amplification/compression gets messed up when jumping around in videos? I have it set to 18db and when I start watching something it's fine but when I jump forward or back, it seems to get a lot louder, like it's fixed itself to 18db and isn't adjusting in relation to the audio stream as it should.
That is expected.
The 18dB will be added to the volume when playback starts. To avoid clipping, there is an attenuation level that is calculated.
If (volume+amplification > max_level) then the attenuation is increased. The attenuation slowly decays when we are not in danger of clipping.
Overall this means that quiet parts of the movie are amplified by 18dB, but loud parts are left alone.
After a seek, the attenuation is reset to 0, and allowed to settle based on the current volume level in the file (exactly as if you'd started playback from there).
So, if you had just passed a loud part of movie, where attenuation had increased to 18dB, and you are now in a quiet part, the attenuation will be slowly decaying (e.g. it might be 15dB)
and you then seek to an equally quiet part, it will seem louder as the attenuation is reset to 0.
However it should be the same volume as you would have got just by waiting for the decay to take it to zero.
Of course I'd expect the volume to go louder briefly when skipping, as the attenuation has to reset and analyse the current volume to determine what it should be set to. The problem however is that it doesn't seem to kick in for a long time (30-60s), so that it's blaring loud for that time and I have to use the TV remote to reduce the volume and then increase it again once it's settled down. Often when I'm skipping, it's through the ads, which tend to be louder than the programme anyway, so it's not that I'm landing on quiet parts and it's boosting them to the max, I'm landing on loud parts and it's not attenuating them for a long while.
When I used ffdshow's volume boost/compression feature on the PC, I recall it would jump in volume when skipping but then adjust itself back down very quickly, so it wasn't really a problem.
Perhaps a possible solution would be to always set the attenuation to max when skipping (or starting, as we might be resuming a video at a loud point) and then let it analyse the volume and decay to the correct level?
RE: OpenELEC Testbuilds for RaspberryPi Part 2 - schub - 2013-11-30
(2013-11-29, 16:57)Reddog999 Wrote: @MilhouseVH
I know this is a big ask but how difficult/time consuming would it be for you to recompile your last build based on Linux 3.10.xx - I will understand your reluctance if this is not practical.
My reason for asking this is that with all the latest dev builds (except for Rbej's builds), the GPIO ir receiver does not work and I believe I have found that the culprit may be the Linux version.
I have tried at least a dozen different builds and my results are:
All official Openelec builds (e.g. 3.1.6, 3.1.7, 3.2.3) work - they use Linux version 3.10.xx
All Rbej Frodo and Gotham builds work - he uses version 3.10.xx
Chris Swan builds: all builds up to 13/9/13 (build version r15595) work - uses Linux version 3.10.xx
all builds from 14/9/13 (build version r15889) do not work - uses Linux version 3.11.xx
Your builds using Linux version 3.12.xx do not work
Of course it could be a Frodo/Gotham thing but since Rbej's Gotham releases use Linux version 3.10.xx that work, I believe it is more likely to be a driver problem that is packaged with the Linux kernel.
My other post gives some more information.
If I was a more able person I would make my own build but sadly I don't have the knowledge or the tools to do this.
Hi,
because i had trouble getting my USB DVB-C-Stick to work with the Builds from MilhouseVH,
i have tried to build a OpenELEC master with kernel 3.10 and popcornmix newclock3.
But the resulting image was always hanging on boot.
Now i have successfully build a OpenELEC 3.2 image with popcornmixs newclock3 branch.
Currently iam testing my version, but at first my DVB-C-Stick and LiveTV does work.
Best Regards,
RE: OpenELEC Testbuilds for RaspberryPi Part 2 - popcornmix - 2013-11-30
(2013-11-26, 15:05)MilhouseVH Wrote: There seems to be a problem with "rewind" on music - it always seeks forward (rather than backwards). Fast forward works correctly though.
Yes, I can confirm. I believe 2x and 4x forwards should work but probably nothing else. I'll see what I can do.
The generic code in omxplayer (which is based on dvdplayer) doesn't look like it handles rewind properly.
So, I tried xbmc on windows and played a music files with right-click play with dvdplayer and rewind seems broken there too.
RE: OpenELEC Testbuilds for RaspberryPi Part 2 - evanspae - 2013-11-30
(2013-11-30, 13:31)evanspae Wrote:(2013-11-29, 13:42)popcornmix Wrote:(2013-11-29, 13:24)evanspae Wrote: As mentioned above this is playback of pre recorded .ts file on a well established system. This and other files plays fine on other xbmc clients (mainly 12.2 Frodo builds) both on PCs and stable raspberrypi openelec 3.2.3. There are not reception or file errors and it is a new problem on latest build.
If you seek to the end, is the sync off by the same amount as if you'd played from the beginning, or does seeking fix the sync?
Can you upload a file that has this problem and send me a link? The smaller the better, although in this case the drift may only be visible in a large file.
(Google drive is a good way of hosting a large file).
Skipping to various points and back through the file does not exhibit any obvious lipsync issues, it seems related to longer term drift of some description.
Unfortunately, the file is 9.5GB. I will see if I can post a clip but I am concerned that my edit prog TSMuxer and VideoRedo may not cut without some resyncing etc.
Here is link to a clip of file in question https://www.dropbox.com/s/e2bajutdzx66ick/Agatha%20Christie%27s%20Poirot_S13E04_ITV1%20HD_2013-11-06.ts
RE: OpenELEC Testbuilds for RaspberryPi Part 2 - popcornmix - 2013-11-30
(2013-11-30, 21:15)evanspae Wrote: Here is link to a clip of file in question https://www.dropbox.com/s/e2bajutdzx66ick/Agatha%20Christie%27s%20Poirot_S13E04_ITV1%20HD_2013-11-06.ts
So, what's the behaviour I'm looking for?
E.g. after ten minutes of watching audio is ahead by 0.5 seconds.
Can you confirm this particular file played correctly with an older xbmc? Openelec 3.2.3?
Edit:
I've tested the file. Watched the whole clip and it was perfectly in sync using Milhouse's latest Gotham build.
I've got ac3 passthrough enabled.
RE: OpenELEC Testbuilds for RaspberryPi Part 2 - doveman2 - 2013-11-30
I have no idea what just happened but I upgraded my brother to build 16442 and after that he couldn't play any video, he was just getting a black screen and no audio. I got him to change Vertical Blank Sync from Let Driver Choose to Always Enabled and after that the first video he tried played a couple of seconds, then stopped but the rest he tried worked fine and then he tried the first one again and that was OK too now. I guess Vertical Blank Sync was on Let Driver Choose before the upgrade though and it was working fine for him (he's using the composite video output, so I'm not even sure if that setting has any effect).
15 minutes later, he phoned back to say his skin (xTV-SAF) was completely messed up, all the menu items on the Home page were under the wrong heading and he had no visible cursor/highlight so couldn't see what he was selecting. I managed to switch debugging on by editing the guisettings.xml and eventually he managed to switch the skin to Confluence, which was OK but when he switched back to xTV-SAF, the cursor disappeared again so he didn't even know if he was selecting Yes or No when it asked if he wanted to keep the change! The log is here in case anyone wants to take a look and see if there's any clue as to what went wrong: http://xbmclogs.com/show.php?id=91965 I grabbed the xbmc.old.log with build 16442 as well but that was before I turned debugging on, so it might not show anything useful: http://xbmclogs.com/show.php?id=91967
I tried downgrading him to 16367 but that didn't help and he said he then was also missing the pictures above the menus (Recently Added I guess). This is the log with that build: http://xbmclogs.com/show.php?id=91966
I noticed he had xtv-SAF v1.3.4.1011 whereas I only have 1.3.3.928. I'm not sure how he got a newer version as I haven't been notified about an update and I don't even think he's got update notifications on but anyway, it was working before I updated him to build 16442. I transferred the xtv-SAF v1.3.3.928 package to his RPi and got him to install it (that was a bit confusing for him as as soon as he selected it, it just returned him to the Addons menu, with no indication it had or was installing, so he did it again with the same result and then suddenly it popped up "Do you want to switch to this skin" so it had obviously been installing, just not telling him. It's back to working order again now, which is a relief but it's a bit of a drag that what should have been a quick upgrade turned into a few hours of phone calls and head scratching.
Any ideas what went wrong here?
EDIT: OK, I don't know about the video playback problems but it seems that xtv-SAF v1.3.4.1011 isn't compatible with Gotham. It may also have failed to install properly, resulting in the missing cursor.
RE: OpenELEC Testbuilds for RaspberryPi Part 2 - evanspae - 2013-12-01
(2013-11-28, 15:14)evanspae Wrote: I have not tested builds for a few weeks but I am testing OpenELEC_Gotham-RPi.arm-devel-20131127234643-r16442.tar. I am most impressed with speed increase in opening up BBC HD .ts content very responsive, ditto on Ch4 HD 5.1 .ts files.
Skip step works very well also.. thanks for everyones efforts..
I will post back any issues.. I have had momentary black frames and one lock up but I think a reboot was necessary because of changes I had made.
Quote:evanspae Wrote:
Here is link to a clip of file in question https://www.dropbox.com/s/e2bajutdzx66ic...3-11-06.ts
So, what's the behaviour I'm looking for?
E.g. after ten minutes of watching audio is ahead by 0.5 seconds.
Can you confirm this particular file played correctly with an older xbmc? Openelec 3.2.3?
Edit:
I've tested the file. Watched the whole clip and it was perfectly in sync using Milhouse's latest Gotham build.
I've got ac3 passthrough enabled.
My comments are related to the build OpenELEC_Gotham-RPi.arm-devel-20131127234643-r16442.tar . With lipsync set up correctly on start of program, it had drifted out by 500ms towards the end of program approx 2hrs later. As previously mentioned it plays with no problems on another pi with Openelec 3.2.3 although the 3.2.3 pi is connected through a/v system with auto lipsync and external passthrough settings enabled. The latest Gotham is connect via HDMI to tv with no passthrough.