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 - Milhouse - 2013-08-25

(2013-08-24, 13:50)popcornmix Wrote: You need that patch instead of the previous "bcm2708 vchiq driver" patch. Only vchiq_proc.c and vchiq_arm.c changed, and the patch is the initial import of those files, so you can probably just grab the updated version of those two files.

Rightyo... I hacked in the vchiq_proc.c and vchiq_arm.c changes as best I could, Linux compiled anyway which is usually a good sign! Smile

I've played the test movie with two concurrent vcgencmd loops 6-7 times and no traceback messages, so that's looking good - many thanks.

However, I did see the following ERROR just once in /var/log/message during one playback - not sure what it means, and maybe a later patch already addresses it:

Code:
Aug 25 12:35:46 rpi512 user.info kernel: [   48.919983] bcm2835-cpufreq: switching to governor ondemand
Aug 25 12:35:59 rpi512 cron.err crond[728]: time disparity of 22957175 minutes detected
Aug 25 12:41:52 rpi512 user.warn kernel: [  414.552304] ERROR::handle_hc_chhltd_intr_dma:2592: handle_hc_chhltd_intr_dma: Channel 6, DMA Mode -- ChHltd set, but reason for halting is unknown, hcint 0x00000002, intsts 0x04600021
Aug 25 12:41:52 rpi512 user.warn kernel: [  414.552304]



RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Squall13 - 2013-08-25

(2013-08-25, 12:13)evanspae Wrote:
(2013-08-25, 02:42)Squall13 Wrote:
(2013-08-24, 19:04)misa Wrote: Try to remove <guires>1080 or 720</guires> from advancedsettings.xml

Hi there.

I tried that and it still reverts back to it's default settings (deformed) when I restart the thing.

Does guisettings.xml have anything to do with this? I came to an advice on the previous thread that I should delete it. I deleted it, and it looked fine. Made some adjustments on the overscan then when I restarted it it was messed up again.

How about config.txt? I remember one time that I should be changing gpu_mem in there somewhere depending on if its a 256 or 512 Pi.

There is obviously still a bug here (I think it looks as if its an XBMC Gotham one with menu restructures) and we will have to wait for developers to sort. Config.txt will not sort this as guisettings are being overwritten on each reboot.. its becoming a real showstopper preventing latest Gotham from daily usage. We will have to be patient. Most of the earlier issues of buffering and DTS, Dolby HD etc are looking good.

Thanks to all for progress todate keep up the good work. The eternal problem here is the better the solution being offered... the more we want from it! Tongue

I understand sir if it is a bug or some sort and I appreciate all these people have done for the project. but it looks like I'm the only one with the problem so it must have been something I've done lol. The last people that had the same problem that I have googled was back in 2012 so I think it's safe to assume that no one here currently is having said issue.


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - popcornmix - 2013-08-25

(2013-08-25, 14:03)MilhouseVH Wrote: However, I did see the following ERROR just once in /var/log/message during one playback - not sure what it means, and maybe a later patch already addresses it:

Looks like this issue:
https://github.com/raspberrypi/linux/issues/241

Seems it should have been fixed. Can you check if all the dwc_otg commits are present in your linux tree?
If you do and you are still getting that error then opening a linux issue may be best.


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Milhouse - 2013-08-25

(2013-08-25, 14:08)popcornmix Wrote: Looks like this issue:
https://github.com/raspberrypi/linux/issues/241

Seems it should have been fixed. Can you check if all the dwc_otg commits are present in your linux tree?
If you do and you are still getting that error then opening a linux issue may be best.

I seem to have the following dwc related patches in OE master:
Quote:Subject: [PATCH 002/112] Add dwc_otg driver
Subject: [PATCH 030/112] Add FIQ patch to dwc_otg driver. Enable with dwc_otg.fiq_fix_enable=1. Should give about 10% more ARM performance. Thanks
to Gordon and Costas
Subject: [PATCH 054/112] Default to dwc_otp.lpm_enable=0
Subject: [PATCH 057/112] dwc_otg: fix bug in dwc_otg_hcd.c resulting in silent kernel memory corruption, escalating to OOPS under high USB load.
Subject: [PATCH 063/112] dwc_otg: Fix unsafe access of QTD during URB enqueue
Subject: [PATCH 064/112] dwc_otg: Fix incorrect URB allocation error handling
Subject: [PATCH 067/112] dwc_otg: fix potential use-after-free case in interrupt handler
Subject: [PATCH 068/112] dwc_otg: add handling of SPLIT transaction data toggle errors
Subject: [PATCH 071/112] dwc_otg: implement tasklet for returning URBs to usbcore hcd layer
Subject: [PATCH 074/112] dwc_otg: fix NAK holdoff and allow on split transaction only
Subject: [PATCH 087/112] dwc_otg: Call usb_hcd_unlink_urb_from_ep with lock held in completion handler
Subject: [PATCH 089/112] dwc_otg: fix device attributes and avoid kernel warnings on boot
Subject: [PATCH 095/112] dwc_otg: mask correct interrupts after transaction error recovery
Subject: [PATCH 096/112] dwc_otg: fiq: prevent FIQ thrash and incorrect state passing to IRQ
Subject: [PATCH 098/112] dwc_otg: whitespace cleanup in dwc_otg_urb_enqueue
Subject: [PATCH 099/112] dwc_otg: prevent OOPSes during device disconnects
Subject: [PATCH 100/112] dwc_otg: prevent BUG() in TT allocation if hub address is > 16
Subject: [PATCH 103/112] dwc_otg: make channel halts with unknown state less damaging
Subject: [PATCH 104/112] dwc_otg: fiq_split: use TTs with more granularity
Subject: [PATCH 107/112] dwc_otg: fix potential sleep while atomic during urb enqueue
Subject: [PATCH 108/112] dwc_otg: make fiq_split_enable imply fiq_fix_enable
Subject: [PATCH 109/112] dwc_otg: prevent crashes on host port disconnects
Subject: [PATCH 110/112] dwc_otg: prevent leaking URBs during enqueue

It looks like I have the patch mentioned in issue 241 (highlighted in above list) - I assume the patch hasn't changed, this is what I have:
Code:
1.8.1.6


From ffb30ec872c1434dda30f3364710e6bb47e98fb1 Mon Sep 17 00:00:00 2001
From: P33M <[email protected]>
Date: Sun, 3 Mar 2013 14:45:53 +0000
Subject: [PATCH 068/112] dwc_otg: add handling of SPLIT transaction data
toggle errors

Previously a data toggle error on packets from a USB1.1 device behind
a TT would result in the Pi locking up as the driver never handled
the associated interrupt. Patch adds basic retry mechanism and
interrupt acknowledgement to cater for either a chance toggle error or
for devices that have a broken initial toggle state (FT8U232/FT232BM).
---
drivers/usb/host/dwc_otg/dwc_otg_hcd_intr.c | 19 ++++++++++++++-----
1 file changed, 14 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/host/dwc_otg/dwc_otg_hcd_intr.c b/drivers/usb/host/dwc_otg/dwc_otg_hcd_intr.c
index 0c81a64..16e8c6c 100644
--- a/drivers/usb/host/dwc_otg/dwc_otg_hcd_intr.c
+++ b/drivers/usb/host/dwc_otg/dwc_otg_hcd_intr.c
@@ -1921,13 +1921,20 @@ static int32_t handle_hc_datatglerr_intr(dwc_otg_hcd_t * hcd,
                     dwc_otg_qtd_t * qtd)
{
    DWC_DEBUGPL(DBG_HCDI, "--Host Channel %d Interrupt: "
-            "Data Toggle Error--\n", hc->hc_num);
+        "Data Toggle Error on %s transfer--\n",
+        hc->hc_num, (hc->ep_is_in ? "IN" : "OUT"));

-    if (hc->ep_is_in) {
+    /* Data toggles on split transactions cause the hc to halt.
+     * restart transfer */
+    if(hc->qh->do_split)
+    {
+        qtd->error_count++;
+        dwc_otg_hcd_save_data_toggle(hc, hc_regs, qtd);
+        update_urb_state_xfer_intr(hc, hc_regs,
+            qtd->urb, qtd, DWC_OTG_HC_XFER_XACT_ERR);
+        halt_channel(hcd, hc, qtd, DWC_OTG_HC_XFER_XACT_ERR);
+    } else if (hc->ep_is_in) {
        qtd->error_count = 0;
-    } else {
-        DWC_ERROR("Data Toggle Error on OUT transfer,"
-              "channel %d\n", hc->hc_num);
    }

    disable_hc_int(hc_regs, datatglerr);
@@ -2080,6 +2087,8 @@ static void handle_hc_chhltd_intr_dma(dwc_otg_hcd_t * hcd,
        handle_hc_babble_intr(hcd, hc, hc_regs, qtd);
    } else if (hcint.b.frmovrun) {
        handle_hc_frmovrun_intr(hcd, hc, hc_regs, qtd);
+    } else if (hcint.b.datatglerr) {
+        handle_hc_datatglerr_intr(hcd, hc, hc_regs, qtd);
    } else if (!out_nak_enh) {
        if (hcint.b.nyet) {

I've only seen the ERROR just the once, but if I continue to see it I'll open a new issue.

My Pi is connected to a keyboard - though not in use - and IR dongle, which may account for the USB 1.1 activity. Other than the message appearing, all seems fine with the Pi and XBMC.


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - RichG - 2013-08-25

(2013-08-25, 13:54)evanspae Wrote:
(2013-08-25, 13:30)popcornmix Wrote: advancedsettings should trump guisettings. My clock is correct with those settings in advancedsettings.
However I don't understand setting the timezone from the gui does not work.
It would be useul to determine where the problem lies. I'd like to know if:
raspmbc nightly (gotham) build has the same timezone bug
xbmc nightly gothman build on windows has the same timezone bug
xbmc nightly gotham build on openelec on PI has the same timezone bug

If it affects all platforms, then a trac ticket should be submitted. If it only affects openelec or Pi, then we need to investigate why that is.

Latest Windows Gotham nightly 24-08 does not have timezone clock issue and does not require locale advancedsettings. Both on screen clock and log and file timestamps are ok so no bug.

I am unable to test raspbmc nightly gotham build, hopefully someone can check this, but appears to be a PI issue.


Just been trying todays build (25/08) and on first boot with timezone in advancedsettings.xml it came up on hour out. Removed the lines again from advancedsettings and rebooted and time was correct - go figure!


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - dhead - 2013-08-25

(2013-08-24, 17:37)dhead Wrote: Hi rbej and popcornmix

Is xbmc-995.01-xvba_support-e70c101.patch included in latest Gotham builds ?
It may fix an issue with few media keys.

https://github.com/FernetMenta/xbmc/commit/c643928909249f536c65d96683576b2df907fcf6
https://github.com/FernetMenta/xbmc/commit/df180bc99ab2c68661426d6a186dacba044aacc3

https://github.com/OpenELEC/OpenELEC.tv/issues/2520

(2013-08-25, 13:56)rbej Wrote: Updated Gotham Branch

- updated Xbmc Gotham

- added some Xbmc patches from internet

http://netlir.dk/rbej/builds/

http://lysin.me/rbej

Thanks Rbej.

This build fixed all my issues with media keys (FF, RR, Play and Record).


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - botribun - 2013-08-25

Since 3 or 4 builds xbmc doesn't feel snappier any more and it just shows around ~25/30 fps in the system tab? Is it just me?


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - popcornmix - 2013-08-25

(2013-08-25, 16:53)botribun Wrote: Since 3 or 4 builds xbmc doesn't feel snappier any more and there just shows around ~25/30 fps in the system tab? Is it just me?
I believe that is deliberate.
There were some bugs in the dirty rectangle code meaning some display (particularly the system info) were constantly being flagged as requiring an update and so would try to update as fast as possible, resulting in high fps and 100% cpu.
With the fixes you should find the screens only update when required (i.e. at speed the controls update) and the cpu will be lower.

If you want the fps to show higher numbers (at expence of cpu), then disabling dirty rectangled will probably have this effect:
<gui>
<algorithmdirtyregions>0</algorithmdirtyregions>
</gui>
to advancedsettings.xml.
http://wiki.xbmc.org/?title=advancedsettings.xml#.3Calgorithmdirtyregions.3E


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - doveman2 - 2013-08-25

(2013-08-25, 12:28)popcornmix Wrote:
(2013-08-25, 00:38)doveman2 Wrote: Ah, I see it affects XBMC completely and shows the wrong time on Home and in the EPG (i.e. it shows the current programme as the one that was on an hour ago) and not just the log Sad

Just edit advancedsettings.xml and add the correct timezone information. E.g. I use:
Code:
<locale>
        <country>UK (24h)</country>
        <language>English</language>
        <timezone>Europe/London</timezone>
        <timezonecountry>Britain (UK)</timezonecountry>
    </locale>

That will fix the time. Not sure why setting this in the gui is broken in gotham builds.

Thanks, I'll try that. I checked guisettings.xml and that already has

Code:
<locale>
        <audiolanguage>original</audiolanguage>
        <charset>DEFAULT</charset>
        <country>UK (24h)</country>
        <language>English</language>
        <subtitlelanguage>original</subtitlelanguage>
        <timezone></timezone>
        <timezonecountry></timezonecountry>
    </locale>

so as you can see, the timezone settings are blank which explains why it's not working.

Hmm, adding the settings to advancedsettings.xml didn't help and it still shows an hour behind onscreen. I put the timezone settings in guisettings.xml as well and that's fixed it.

Looking through I also saw

Code:
<audiooutput>
        <ac3passthrough>true</ac3passthrough>
        <audiodevice>default</audiodevice>
        <channels>1</channels>
        <dtshdpassthrough>true</dtshdpassthrough>
        <dtspassthrough>true</dtspassthrough>
        <guisoundmode>1</guisoundmode>
        <mode>0</mode>
        <multichannellpcm>true</multichannellpcm>
        <normalizelevels>true</normalizelevels>
        <passthroughaac>false</passthroughaac>
        <passthroughdevice>default</passthroughdevice>
        <processquality>30</processquality>
        <stereoupmix>false</stereoupmix>
        <streamsilence>true</streamsilence>
        <truehdpassthrough>true</truehdpassthrough>
    </audiooutput>

could the normalizelevels setting be causing Music to be so much louder than TV or does that setting apply to all audio? I note that there doesn't seem to be any downmix setting in there, is that located somewhere else?

There's also

Code:
<audio>
        <mute>false</mute>
        <fvolumelevel>1.000000</fvolumelevel>
    </audio>

and I wonder what fvolumelevel controls.

I also saw

Code:
<input>
        <enablejoystick>true</enablejoystick>

which I changed to false as I'm not using a joystick and it seems sensible to disable anything I'm not using.


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - doveman2 - 2013-08-25

(2013-08-25, 16:58)popcornmix Wrote: I believe that is deliberate.
There were some bugs in the dirty rectangle code meaning some display (particularly the system info) were constantly being flagged as requiring an update and so would try to update as fast as possible, resulting in high fps and 100% cpu.
With the fixes you should find the screens only update when required (i.e. at speed the controls update) and the cpu will be lower.

Yes, for me it's lower in Settings or System Info now, around 30fps and 30% CPU. However it still has the bug when moving from the left-hand category pane in Settings to the right-hand pane where the CPU goes to 89%+. For example, Settings - Videos with Library selected it's 25-30%, moving to the other pane so that "Show plot for unwatched items" is selected and it jumps to 89%. Interestingly, this doesn't happen on the Skin Settings pages, i.e Settings - Appearance - Settings where it stays below 50% whatever's selected (at least with xTV-SAF) and on Categories with fewer items in the other pane, such as Startup and Media Sources, it stays below about 35%.


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Milhouse - 2013-08-25

I can reproduce the above from doveman2, although I've included all the GUI performance patches from stupid-boy. For me, moving from the left column (Settings -> Video -> Library, ~9% CPU) to the right ("Show plot for unwatched items") causes the CPU load to jump to 55% (1GHz Pi). So it looks like there's a few additional GUI optimisations needed...


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - popcornmix - 2013-08-25

@doveman2 and @MilhouseVH

There is a thread for dirty rectangle bugs:
http://forum.xbmc.org/showthread.php?tid=171784

Ideally turn on visualizedirtyregions and set algorithmdirtyregions to 1 or 2 and take a screenshot.
It should show what area of the screen is getting unnecessary updates.


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Martijn - 2013-08-25

(2013-08-25, 17:31)MilhouseVH Wrote: I can reproduce the above from doveman2, although I've included all the GUI performance patches from stupid-boy. For me, moving from the left column (Settings -> Video -> Library, ~9% CPU) to the right ("Show plot for unwatched items") causes the CPU load to jump to 55% (1GHz Pi). So it looks like there's a few additional GUI optimisations needed...

http://forum.xbmc.org/showthread.php?tid=171784&pid=1491666#pid1491666
It's not like you spend all day in settings right so this is just a very minor detail


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Squall13 - 2013-08-25

I think I saw the bug that was causing my problems. The resolution part of guisettings.xml doesn't change whatsoever. Directly or via XBMC settings. Deleting and recreating it doesn't work either. The values remain the same.

Oh well, I switched back to the latest rbej Frodo but it seems like I have some problems there as well ( can't open : /sbin/init/ line 49 var/config/settings.conf on startup). But it's better than having my resolution change every reboot.

Cheers and more power.


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - doveman2 - 2013-08-25

(2013-08-25, 17:33)popcornmix Wrote: @doveman2 and @MilhouseVH

There is a thread for dirty rectangle bugs:
http://forum.xbmc.org/showthread.php?tid=171784

Ideally turn on visualizedirtyregions and set algorithmdirtyregions to 1 or 2 and take a screenshot.
It should show what area of the screen is getting unnecessary updates.

I did try that before and couldn't see any dirty rectangles on the settings screens, the only one I found was on Recently Added with scrolling text.

I'll try again though just in case the newer build has changed things there but I doubt it.

(2013-08-25, 17:33)Martijn Wrote: http://forum.xbmc.org/showthread.php?tid=171784&pid=1491666#pid1491666
It's not like you spend all day in settings right so this is just a very minor detail

I think you underestimate it IMHO, as it means I have to warn people not to leave XBMC on these screens or it will peg the CPU at 90%, wasting energy and creating unnecessary heat, thus shortening the life of the RPi for no reason. Users shouldn't have to be worrying about which screen they might have left it on and remembering to go back to Home every time they leave it idling.

(2013-08-25, 17:31)MilhouseVH Wrote: I can reproduce the above from doveman2, although I've included all the GUI performance patches from stupid-boy. For me, moving from the left column (Settings -> Video -> Library, ~9% CPU) to the right ("Show plot for unwatched items") causes the CPU load to jump to 55% (1GHz Pi). So it looks like there's a few additional GUI optimisations needed...

Strange that your CPU is so much lower than mine as I'm currently overclocking to 1000/450 with overvoltage=4.