Kodi Community Forum
OpenELEC Testbuilds for RaspberryPi Part 2 - 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 Part 2 (/showthread.php?tid=184866)



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:
(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..)
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.


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:
(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..)
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.

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/3059
Yeah, 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
[/
code]


This forum uses Lukasz Tkacz MyBB addons.