+- 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 - 606u - 2014-04-04
I haven't reported this one as I never saw it working until recently, when I ripped few of my old DVD to mkv files. Anyway, here is the problem: in movies list, information regarding definition (SD/720p/1080/4k), CODECs and aspect ratio is pure lottery for m4v container (h.264 + AAC made with Handbrake and tagged with Subler), however it seems to work well for other cases: mkv container (tested with MPEG-2 with AC3 audio). Its the same on desktop version of XBMC. Is it just me or its for everybody?
RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Milhouse - 2014-04-04
Presumably everybody if it also affects desktop XBMC. I use NFOs that contain the stream information rather than depend on XBMC (mis)identifying, so haven't noticed any problem myself.
Perhaps if you can create a 100% reproducible test case with sample file it should be possible for it to be investigated further and hopefully fixed. Posting in a dedicated thread would also ensure more "eyes on".
RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Leopold - 2014-04-04
(2014-04-03, 19:31)MilhouseVH Wrote: Hmmm. That leaves the updated rpcbind as the only remaining potential culprit. Unfortunately my broadband is down at the moment so I won't be able to create a build to test that theory for now. Weird how my NFS is working fine.
My NFS is also working fine with all builds. Could the NFS issues that some are reporting be down to export options? Perhaps a change in libnfs now requires particular options on the server side?
For example I think I had the problem of my Synology NFS shares not showing up in XBMC without the default insecure_locks option changed to insecure http://wiki.xbmc.org/?title=NFS#Synology.
RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Mafarricos - 2014-04-04
(2014-04-04, 07:08)MilhouseVH Wrote: @bagofcrap24: Hmm, will need to investigate that further, maybe the build isn't a good one but not sure why that would be the case right now. You could try a very recent official nightly as that should have libnfs reverted (check the sha to be sure).
@Chortos-2: Many thanks for continuing the libass investigation! I'd be happy to help build and test any patches but beyond that my technical knowledge of subtitles and GLES is limited.
@Mafarricos: Try disabling FIQ FSM - add "dwc_otg.fiq_fsm_enable=0" to the end of your line in cmdline.txt.
Will try this and report at night.
Is FIQ FSM enabled by default in your releases, for what I see that disables, correct?
Usually this setting brings this kind of problem?
RE: OpenELEC Testbuilds for RaspberryPi Part 2 - popcornmix - 2014-04-04
(2014-04-04, 11:15)Mafarricos Wrote: Will try this and report at night.
Is FIQ FSM enabled by default in your releases, for what I see that disables, correct?
Usually this setting brings this kind of problem?
The fiq fsm has given me (and probably most) no trouble. However some combination of network setup and usb devices seems to cause a problem for some (too many..)
As a result, the default options have just been changed in upstream OpenELEC:
https://github.com/OpenELEC/OpenELEC.tv/commit/b97d61d614d3d9df78b8634487dbabd1638630a5
So in future builds, it will have to be enabled manually. People who are having problems should find it now works okay with unchanged cmdline.txt.
Obviously I'm hoping for a fix for this soon, as having it enabled does solve a number of USB issues.
RE: OpenELEC Testbuilds for RaspberryPi Part 2 - popcornmix - 2014-04-04
(2014-04-04, 08:46)606u Wrote: I haven't reported this one as I never saw it working until recently, when I ripped few of my old DVD to mkv files. Anyway, here is the problem: in movies list, information regarding definition (SD/720p/1080/4k), CODECs and aspect ratio is pure lottery for m4v container (h.264 + AAC made with Handbrake and tagged with Subler), however it seems to work well for other cases: mkv container (tested with MPEG-2 with AC3 audio). Its the same on desktop version of XBMC. Is it just me or its for everybody?
It it's the same on desktop xbmc, then you should post in a general xbmc forum, and perhaps create a trac ticket.
The devs who can fix this are probably not reading this forum.
RE: OpenELEC Testbuilds for RaspberryPi Part 2 - popcornmix - 2014-04-04
(2014-04-04, 02:36)Chortos-2 Wrote: If texture size is indeed the problem, convert_quad in OverlayRendererUtil.cpp needs to be taught to split ASS_Images that are wider than the maximum texture size.
I run with 1920x1080 fanart, which are rendered using textures. The limit is 2048x2048, so I don't think it is a texture size issue. It looks like a libass bug.
Milhouse has identified the commit when it appeared: https://github.com/OpenELEC/OpenELEC.tv/issues/3059
RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Mafarricos - 2014-04-04
(2014-04-04, 12:35)popcornmix Wrote:(2014-04-04, 11:15)Mafarricos Wrote: Will try this and report at night.
Is FIQ FSM enabled by default in your releases, for what I see that disables, correct?
Usually this setting brings this kind of problem?
The fiq fsm has given me (and probably most) no trouble. However some combination of network setup and usb devices seems to cause a problem for some (too many..)
As a result, the default options have just been changed in upstream OpenELEC:
https://github.com/OpenELEC/OpenELEC.tv/commit/b97d61d614d3d9df78b8634487dbabd1638630a5
So in future builds, it will have to be enabled manually. People who are having problems should find it now works okay with unchanged cmdline.txt.
Obviously I'm hoping for a fix for this soon, as having it enabled does solve a number of USB issues.
OK.
I have a wifi dongle connected and a wireless keyboard.
Will check if with that I don't have freezes while watching videos and if I have some problems with USB.
But for what I see probably will solve my problem.
RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Forage - 2014-04-04
(2014-04-04, 12:35)popcornmix Wrote:In case it help narrowing down the issue: In my case it was just network, I don't have a single additional/external USB device connected to the RPi. Good to hear it's disabled for the time being.(2014-04-04, 11:15)Mafarricos Wrote: Will try this and report at night.
Is FIQ FSM enabled by default in your releases, for what I see that disables, correct?
Usually this setting brings this kind of problem?
The fiq fsm has given me (and probably most) no trouble. However some combination of network setup and usb devices seems to cause a problem for some (too many..)
RE: OpenELEC Testbuilds for RaspberryPi Part 2 - stefan129 - 2014-04-04
(2014-04-04, 13:12)Forage Wrote:(2014-04-04, 12:35)popcornmix Wrote:In case it help narrowing down the issue: In my case it was just network, I don't have a single additional/external USB device connected to the RPi. Good to hear it's disabled for the time being.(2014-04-04, 11:15)Mafarricos Wrote: Will try this and report at night.
Is FIQ FSM enabled by default in your releases, for what I see that disables, correct?
Usually this setting brings this kind of problem?
The fiq fsm has given me (and probably most) no trouble. However some combination of network setup and usb devices seems to cause a problem for some (too many..)
Same for me, no additional USB device. If fiq fsm turned on the network does not work. Turning it off with "dwc_otg.fiq_fsm_enable=0" brings back the network and everything is working perfect again.
Re: RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Mafarricos - 2014-04-04
(2014-04-04, 13:02)Mafarricos Wrote:(2014-04-04, 12:35)popcornmix Wrote:(2014-04-04, 11:15)Mafarricos Wrote: Will try this and report at night.
Is FIQ FSM enabled by default in your releases, for what I see that disables, correct?
Usually this setting brings this kind of problem?
The fiq fsm has given me (and probably most) no trouble. However some combination of network setup and usb devices seems to cause a problem for some (too many..)
As a result, the default options have just been changed in upstream OpenELEC:
https://github.com/OpenELEC/OpenELEC.tv/commit/b97d61d614d3d9df78b8634487dbabd1638630a5
So in future builds, it will have to be enabled manually. People who are having problems should find it now works okay with unchanged cmdline.txt.
Obviously I'm hoping for a fix for this soon, as having it enabled does solve a number of USB issues.
OK.
I have a wifi dongle connected and a wireless keyboard.
Will check if with that I don't have freezes while watching videos and if I have some problems with USB.
But for what I see probably will solve my problem.
After 22 minutes the video got stuck anyway.
Is there other option to try? It seems that in my case deactivating isn't enough.
I will check again, with other videos, but it seems that will still have the problem even with the option deactivated.
What's strange is that I never had problem with OpenElec Milhouse releases.
Last version that I used was from 2014-03-17 and I never had problems with freezing videos.
RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Chortos-2 - 2014-04-04
(2014-04-04, 12:53)popcornmix Wrote: It looks like a libass bug. Milhouse has identified the commit when it appeared: https://github.com/OpenELEC/OpenELEC.tv/issues/3059Yeah, but the only externally visible change that commit introduces is it makes images bigger and fewer by combining them. Before that commit, each letter would be a separate image, and they would be packed into a texture by XBMC, splitting them in multiple rows if needed to fit in the maximum texture width. After that commit, the whole line is a single image—with a width of around 1900 judging by the resolution of Milhouse’s original screenshot that he posted on #libass—that XBMC puts in the texture whole, so if it exceeds the allowed width and is clipped, the output will look just like in the “bad” screenshots.
There is no corruption either on the Raspberry Pi with a simple libass-based software renderer or on other platforms in XBMC, so we’re fairly sure it’s not a libass bug. At this point the only thing unique to the setup that exhibits the corruption (XBMC on Rasperry Pi) is that it uses OpenGL ES on the Raspberry Pi’s particular GPU hardware instead of OpenGL on a desktop- or laptop-class GPU. So I thought: either the hardware could have some particular restrictions, or some of the XBMC source code that differs between GL and GLES might have a bug.
(2014-04-04, 12:53)popcornmix Wrote: I run with 1920x1080 fanart, which are rendered using textures. The limit is 2048x2048, so I don't think it is a texture size issue.Thanks. Well, I’m really out of ideas now! Unless libass is outputting an image that is larger than 2048 for some reason, I guess. I’ll check that in a moment. Edit: it’s 1777×79 pixels, so nope.
RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Chortos-2 - 2014-04-04
Ahaha, I’ve got it! I’m submitting a pull request to XBMC in a minute.
There are three images now: one for the main glyph, one for the border, one for the shadow. 1773, 1777, 1777 pixels wide respectively. XBMC tries to pack them into one texture: it calculates that it needs 1773+1777+1777 = 5327 pixels, which is more than the limit of 2048. So it halves the texture width until it’s below the limit, getting 1331! I was just three pixels off, heh. Let’s make it reset to exactly the limit instead.
I noticed this issue yesterday already but didn’t realize it actually caused the corruption!
RE: OpenELEC Testbuilds for RaspberryPi Part 2 - stuCONNERS - 2014-04-04
can some put up what I would type into crontab for a 6am daily reboot. I cant get cron working on these new builds.
RE: OpenELEC Testbuilds for RaspberryPi Part 2 - tija - 2014-04-04
(2014-04-02, 22:05)MrNice Wrote: @tija
Could you download the files
Nums_7dot1_24_48000.wav
Why I propose this test is because I have a 5.0 config.
With OMXPlayer LFE is mapped to FL and FR (large band) and channels 7 and 8 mapped to FL-RL and FR-RR, this is OK,
BUT with PAPlayer LFE is not mapped (no sound) and channel 7 mapped to RL channel 8 mapped to RR only.
I think this is a mistake.
What are your results, what do you think?
So I did some small test with my configuration HDMI output, passthrough enabled, speaker configuration 7.1
Playing this file Nums_7dot1_24_48000.wav I had no sound for Numbers 4 and 5 and Numbers 7 and 8 have been very hollow (don't know if this is the right word but i could hear something but no clear number)
And I'm just curious about the Log ... Is it right that the sound is mapped 8->8 and then back 8->2 ?
Code:
22:18:38 98096.765625 T:2796192848 INFO: ffmpeg[A6AA8450]: Input #0, wav, from '/storage/downloads/Nums_7dot1_24_48000.wav':
22:18:38 98096.765625 T:2796192848 INFO: ffmpeg[A6AA8450]: Duration: 00:00:09.05, bitrate: 9216 kb/s
22:18:38 98096.765625 T:2796192848 INFO: ffmpeg[A6AA8450]: Stream #0:0: Audio: pcm_s24le ([1][0][0][0] / 0x0001), 48000 Hz, 7.1, s32, 9216 kb/s
22:18:38 98096.765625 T:2796192848 DEBUG: CDVDDemuxFFmpeg::AddStream(0, ...) -> 0
22:18:38 98096.765625 T:2796192848 DEBUG: FactoryCodec - Audio: passthrough - Opening
22:18:38 98096.765625 T:2796192848 DEBUG: FactoryCodec - Audio: passthrough - Failed
22:18:38 98096.765625 T:2796192848 DEBUG: FactoryCodec - Audio: pcm - Opening
22:18:38 98096.765625 T:2796192848 DEBUG: FactoryCodec - Audio: pcm - Opened
22:18:38 98097.507812 T:2796192848 INFO: AudioDecoder: File is queued
22:18:38 98097.515625 T:3058373712 INFO: CActiveAE::ApplySettings - Forcing samplerate to 48000
22:18:38 98097.515625 T:3058373712 INFO: CActiveAEResamplePi::CActiveAEResample
22:18:38 98097.515625 T:3058373712 INFO: CActiveAEResamplePi::Init remap:(nil) chan:8->8 rate:48000->48000 format:1->3 bits:16->32
22:18:38 98097.515625 T:3058373712 INFO: CActiveAEResamplePi::Init 1.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
22:18:38 98097.515625 T:3058373712 INFO: CActiveAEResamplePi::Init 0.00 1.00 0.00 0.00 0.00 0.00 0.00 0.00
22:18:38 98097.515625 T:3058373712 INFO: CActiveAEResamplePi::Init 0.00 0.00 1.00 0.00 0.00 0.00 0.00 0.00
22:18:38 98097.515625 T:3058373712 INFO: CActiveAEResamplePi::Init 0.00 0.00 0.00 1.00 0.00 0.00 0.00 0.00
22:18:38 98097.515625 T:3058373712 INFO: CActiveAEResamplePi::Init 0.00 0.00 0.00 0.00 1.00 0.00 0.00 0.00
22:18:38 98097.515625 T:3058373712 INFO: CActiveAEResamplePi::Init 0.00 0.00 0.00 0.00 0.00 1.00 0.00 0.00
22:18:38 98097.523438 T:3058373712 INFO: CActiveAEResamplePi::Init 0.00 0.00 0.00 0.00 0.00 0.00 1.00 0.00
22:18:38 98097.523438 T:3058373712 INFO: CActiveAEResamplePi::Init 0.00 0.00 0.00 0.00 0.00 0.00 0.00 1.00
22:18:38 98097.531250 T:3058373712 DEBUG: COMXCoreComponent::Initialize OMX.broadcom.audio_mixer input port 232 output port 231 m_handle 0xa1328888
22:18:38 98097.546875 T:3058373712 DEBUG: COMXCoreComponent::AllocInputBuffers component(OMX.broadcom.audio_mixer) - port(232), nBufferCountMin(1), nBufferCountActual(1), nBufferSize(524288), nBuff
erAlignmen(32)
22:18:38 98097.546875 T:3058373712 DEBUG: COMXCoreComponent::AllocOutputBuffers component(OMX.broadcom.audio_mixer) - port(231), nBufferCountMin(1), nBufferCountActual(1), nBufferSize(524288) nBuff
erAlignmen(32)
22:18:38 98097.585938 T:3058373712 INFO: CActiveAEResamplePi::CActiveAEResample
22:18:38 98097.585938 T:3058373712 INFO: CActiveAEResamplePi::Init remap:(nil) chan:8->2 rate:48000->48000 format:3->3 bits:32->32
22:18:38 98097.593750 T:3058373712 INFO: CActiveAEResamplePi::Init 0.32 0.00 0.23 0.00 0.23 0.00 0.23 0.00
22:18:38 98097.593750 T:3058373712 INFO: CActiveAEResamplePi::Init 0.00 0.32 0.23 0.00 0.00 0.23 0.00 0.23
22:18:38 98097.593750 T:3058373712 INFO: CActiveAEResamplePi::Init 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
[/