[joelbaby]

HW Acceleration Options have no effect?

30th March build from here: http://download.openbricks.org/cuboxi-emveepee/
Using the test file: Jellyfish-120-Mbps.mkv
Box: Cubox-i2Ultra

It appears that changing the options in the Acceleration Options menu have zero effect on playback:

- Hardware / Software Acceleration
- Enable / Disable Multi Threading

Whichever combination I choose, pressing 'o' always states:

Code:

D(Video: h264(High),yuv420p, 1920x1080[SAR 1:1 DAR 16:9]
P(fr:23.976,vq 0%, dc:iMX-h264, Mb/s:110 ...)

C(ad: 0.000, a/v: 0.000, edl:-, dcpu 50% acpu 0% vcpu 15% cache 0%)
W(fps: 23  CPU0: 60%, CPU1:60%)

[aplund]

I'm running the imx-git build out of arch linux arm (xbmc-imx-git 13.20140330-1) and I find that it is pretty unstable. But I think it might be a problem with my kernel.

Firstly, sending SIGKILL to xbmc leaves the system hung and the watchdog timer triggers.

But very often I get a hang during playback and the logs only say this:

Code:

00:51:44 T:1666249776   ERROR: CDVDAudio::AddPacketsRenderer - timeout adding data to renderer
00:51:44 T:1666249776   DEBUG: CDVDPlayerAudio:: Discontinuity1 - was:243428581.715536, should be:242250958.333333, error:-1177623.382203
00:51:46 T:1666249776   ERROR: CDVDAudio::AddPacketsRenderer - timeout adding data to renderer
00:51:46 T:1666249776   ERROR: AddPackets - failed to add leftover bytes to render
00:51:46 T:1666249776   DEBUG: CDVDPlayerAudio:: Discontinuity1 - was:243659889.183333, should be:242282958.333333, error:-1376930.850000
00:51:47 T:1666249776   ERROR: CDVDAudio::AddPacketsRenderer - timeout adding data to renderer
00:51:47 T:1666249776   DEBUG: CDVDPlayerAudio:: Discontinuity1 - was:243691793.510333, should be:242282958.333333, error:-1408835.177000
00:51:48 T:1666249776   ERROR: CDVDAudio::AddPacketsRenderer - timeout adding data to renderer
00:51:48 T:1666249776   ERROR: AddPackets - failed to add leftover bytes to render
00:51:48 T:1666249776   DEBUG: CDVDPlayerAudio:: Discontinuity1 - was:243691848.847333, should be:242346958.333333, error:-1344890.514000
00:51:50 T:1666249776   ERROR: CDVDAudio::AddPacketsRenderer - timeout adding data to renderer

And trying to shutdown xbmc or kill it just leaves the whole system hung and the watchdog timer triggers.

My kernel is from commit a305f2d of Jon Nettleton's branch at https://github.com/linux4kix/linux-linar...le-mx6.git

[CruX]

I'd suggest installing either linux-imx6-wandboard-dt or linux-imx6-cubox-dt depending on your plattform.
Im running the wandboard version and its doing fine.

Cheers,
CruX

[aplund]

Hmm... having a look at the tree used in the archlinuxarm packages, the one I'm using is only two commits behind it. The only changes seem to be to do with DVI to HDMI cables.

I'm wondering if some of the system hangs are related to the audio I'm getting to to playback. I'll have to test to and see. Are there any kernel debugging messages that might be helpful here?

[aplund]

Well, I found half the issue. My console blanks after 600 seconds, even if xbmc is active on it. Doesn't explain the system hanging in kernel mode when xbmc gets a SIGKILL.

[aplund]

The way to deactivate the blanking is

Code:

setterm -term linux -blank 0 <>/dev/tty1 > /dev/tty1

Doesn't seem like a robust solution though. I have no idea how to re-enable the blanking to the previous state when xbmc exits.

[aplund]

And here is another trace from the stall. Perhaps some bug in rcu? Not sure exactly what it means:

Code:

INFO: rcu_sched self-detected stall on CPU { 3}  (t=2100 jiffies g=49436 c=49435 q=4393)
CPU: 3 PID: 445 Comm: xbmc.bin Not tainted 3.10.30-12-ARCH #3
[<80015498>] (unwind_backtrace) from [<8001229c>] (show_stack+0x10/0x14)
[<8001229c>] (show_stack) from [<8008a9b4>] (rcu_check_callbacks+0x394/0x7c4)
[<8008a9b4>] (rcu_check_callbacks) from [<80037144>] (update_process_times+0x40/0x6c)
[<80037144>] (update_process_times) from [<8006db88>] (tick_sched_timer+0x4c/0x78)
[<8006db88>] (tick_sched_timer) from [<8004b188>] (__run_hrtimer.isra.32+0x54/0xe4)
[<8004b188>] (__run_hrtimer.isra.32) from [<8004ba8c>] (hrtimer_interrupt+0x11c/0x2d0)

[aplund]

Starting to feel kind of lonely here.

Anyway, does anyone know why xbmc is forced to use software decoding for DVDs? It seems this change was introduced quite a while ago (d75a46a9f9626be12cc486c8e7c7d9be9d216922), but I cannot find any good reason for it.

This means that the VPU isn't used for any DVD based playback. Is this a bug or a feature?

[bbandi]

I'm trying to get my cubox-i play videos in 24p, but it doesn't work. Every time it should change the resolution it just freezes the picture (but the sound works, so I think it just breaks the framebuffer). I see this is implemented in EGLNativeTypeIMX. and it interacts with some sysfs files, so I changed the permissions to 777 of those files, but it's still the same.
I'm using archlinuxarm and xbmc-imx-git, based on the name it was compiled on 11/04, so it might not have the fsl_disp_dev_property based detection, but I think it should work with modalias as well. What am I missing? It works on geexbox without any hacking. Was something disabled in the arch compilation? Or I just have to wait for an update?
SPDIF also doesn't work on arch (neighter "normal" nor passthrough, but works from console programs, eg mopidy), but works on geexbox.
Here's the compile script:
https://github.com/archlinuxarm/PKGBUILD...x/PKGBUILD

[bbandi]

Okay, turned out it was indeed because it wasn't able to write to sysfs. This udev rule fixed it:
SUBSYSTEM=="graphics", RUN+="/bin/chmod 666 /sys/class/graphics/fb0/mode"

[aplund]

I've managed to obtain a trace for the system hang. I've built the kernel with lock debugging turned on and this is the result:

Code:

lock: 0xdc246acc, .magic: dead4ead, .owner: DVDPlayer/597, .owner_cpu: 3
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.10.30-15-ARCH #7
[<80017108>] (unwind_backtrace) from [<80013908>] (show_stack+0x20/0x24)
[<80013908>] (show_stack) from [<804df170>] (dump_stack+0x24/0x28)
[<804df170>] (dump_stack) from [<804df898>] (spin_dump+0x8c/0x94)
[<804df898>] (spin_dump) from [<8026121c>] (do_raw_spin_lock+0x11c/0x18c)
[<8026121c>] (do_raw_spin_lock) from [<804e4f44>] (_raw_spin_lock_irqsave+0x80/0x98)
[<804e4f44>] (_raw_spin_lock_irqsave) from [<803a471c>] (gckEVENT_Interrupt+0x28/0x50)
[<803a471c>] (gckEVENT_Interrupt) from [<803ab518>] (gckHARDWARE_Interrupt+0x78/0x7c)
[<803ab518>] (gckHARDWARE_Interrupt) from [<80398260>] (gckKERNEL_Notify+0x30/0x34)
[<80398260>] (gckKERNEL_Notify) from [<80395f78>] (isrRoutine+0x28/0x50)
[<80395f78>] (isrRoutine) from [<800a9034>] (handle_irq_event_percpu+0x78/0x264)
[<800a9034>] (handle_irq_event_percpu) from [<800a926c>] (handle_irq_event+0x4c/0x6c)
[<800a926c>] (handle_irq_event) from [<800ac5d4>] (handle_fasteoi_irq+0x94/0x15c)

This is clearly a kernel bug, somewhere in the freescale patches. But I seem to be able to trigger it (inconsistently) by restarting xbmc.

Also, my display shows a terrible flicker when playing videos. The scrolling messages at the home screen show some flicker too though not as bad. I cannot think what might be causing this, but my guesses are either something going wrong with the double buffering or with hsync, or both. Does anyone else notice a some kind of flickering? Perhaps it's just my TV, but it does seem to work ok for other things.

[dhead]

Few questions about the development process:
(I'm trying to educate myself better about FOSS development process with a team)

I saw that Gotham RC1 was merged to xbmc-imx6 master branch.
1. For a feature branch that a single developer is working on I'm guessing that prefered method would be rebasing but for a repository like xbmc-imx6 which multiple developers are working on the decision is merging so the timeline won't be broken, am I right ?, what merging method is reccomended (if any) ?
2. What would be the procedure for the "final" PR to XBMC mainline ? are you going to have a clean branch from XBMC mainline and cherry-pick all the imx related commits ? (I'm guessing after the merge you can just pull rebase from XBMC mainline)

[wolfgar]

Hi

The way of working was described in my blog
When Gotham and mainline (The Hoff ;-) / helix) have splitted, we decided to continue to rebase master-pr by following mainline to be ready for a PR to upstream while providing a imx6 port for the stabilizing Gotham on master...

If you have any remaining question, please feel free to ask..

Regards
Stephan

[Jönke]

Any news of mpeg2 1080 deinterlacing issue?

[wolfgar]

No not yet sorry : it is one of the 2 remaining big issues with imx6 (the other being HD audio)