[kraleksandr]

Looks like xbmc uses too much cpu (around 60% by htop in standby).
For example: copying big file to the samba-shared ext4 hdd over wifi not faster than 2.13 MB/s, but if I do "service xbmc stop" (or any another way to exit xbmc) it rises up to 6 MB/s

[Smultie]

(10th Jul, 2013 06:10 AM)kraleksandr Wrote:  Looks like xbmc uses too much cpu (around 60% by htop in standby).
For example: copying big file to the samba-shared ext4 hdd over wifi not faster than 2.13 MB/s, but if I do "service xbmc stop" (or any another way to exit xbmc) it rises up to 6 MB/s

Are you sure you haven't "parked" you XBMC on a CPU-intensive screen? Especially scrolling text can be taxing for your CPU.

[kraleksandr]

(10th Jul, 2013 06:21 AM)Smultie Wrote:  

(10th Jul, 2013 06:10 AM)kraleksandr Wrote:  Looks like xbmc uses too much cpu (around 60% by htop in standby).
For example: copying big file to the samba-shared ext4 hdd over wifi not faster than 2.13 MB/s, but if I do "service xbmc stop" (or any another way to exit xbmc) it rises up to 6 MB/s

Are you sure you haven't "parked" you XBMC on a CPU-intensive screen? Especially scrolling text can be taxing for your CPU.

It happens even with main menu, just power on PI, ssh to, htop aand xbmc uses more than 50% cpu.
skin - bello, OC - xbian.

---

Cant find how to configure T9-like input mode for my IR remote.
If I put this

Code:

        <zero>key_0</zero>
        <one>key_1</one>
        <two>key_2</two>
        <three>key_3</three>
        <four>key_4</four>
        <five>key_5</five>
        <six>key_6</six>
        <seven>key_7</seven>
        <eight>key_8</eight>
        <nine>key_9</nine>

to the .xbmc/userdata/Lircmap.xml then when I press, as ex. "2" key, in input line appears (by press count):

1. 2
2. 2a
3. 2ab
4. 2abc
5. 2abc2
   

Without these lines in input line appears "2" for each keypress.

Why in a5 with same conf files it works correctly? How to make it works like normal T9?

[robotuin]

Hi there,

first of all: congratulations for the performance of xbian. I'm still impressed by the bootup time alone.. but besides that everything works so much more smoothly compared to raspbmc that you start thinking, you are using a faster machine

I just wanted to give a quick feedback to the issue with icons not showing on the homescreen (tested the fix proposed further up this thread):
Installed libtiff4 with sudo apt-get install libtiff4 and now they are showing. Also the shortcut icons to video addons underneath the menu bar are showing now. For people who don't know: you set them in the confluence skin settings.

Since I guess that this surely will be fixed in the next version, I really have only one small suggestion: wouldn't it be a nice additional option in the xbian-config addon to choose whether a video keeps playing or pauses when entering the menu? I know that there are people wanting this behavior, but I guess there are also a lot like me who don't

For people who want to change this, for now just delete the (second) line with the command
<onunload condition="!Player.Paused">PlayerControl(Play)</onunload> in the file
/usr/local/share/xbmc/addons/skin.confluence/720p/VideoFullScreen.xml

Thanks again for this great xbmc experience!

[f1vefour]

(10th Jul, 2013 06:38 AM)kraleksandr Wrote:  

(10th Jul, 2013 06:21 AM)Smultie Wrote:  

(10th Jul, 2013 06:10 AM)kraleksandr Wrote:  Looks like xbmc uses too much cpu (around 60% by htop in standby).
For example: copying big file to the samba-shared ext4 hdd over wifi not faster than 2.13 MB/s, but if I do "service xbmc stop" (or any another way to exit xbmc) it rises up to 6 MB/s

Are you sure you haven't "parked" you XBMC on a CPU-intensive screen? Especially scrolling text can be taxing for your CPU.

It happens even with main menu, just power on PI, ssh to, htop aand xbmc uses more than 50% cpu.
skin - bello, OC - xbian.

It must be the skin your using, switch to the confluence (default) skin and check CPU usage.

[kraleksandr]

(12th Jul, 2013 10:49 AM)f1vefour Wrote:  

(10th Jul, 2013 06:38 AM)kraleksandr Wrote:  

(10th Jul, 2013 06:21 AM)Smultie Wrote:  

(10th Jul, 2013 06:10 AM)kraleksandr Wrote:  Looks like xbmc uses too much cpu (around 60% by htop in standby).
For example: copying big file to the samba-shared ext4 hdd over wifi not faster than 2.13 MB/s, but if I do "service xbmc stop" (or any another way to exit xbmc) it rises up to 6 MB/s

Are you sure you haven't "parked" you XBMC on a CPU-intensive screen? Especially scrolling text can be taxing for your CPU.

It happens even with main menu, just power on PI, ssh to, htop aand xbmc uses more than 50% cpu.
skin - bello, OC - xbian.

It must be the skin your using, switch to the confluence (default) skin and check CPU usage.

30% with default Confluence

[rikardo1979]

so all is normal as should than

[timmink]

Hello,

Airplay still dead on fresh install. Connected to the LAN via cable.
Both devices iphone and iPad on iOS 6.

Trying with a separate RaspBMC SD-card Airplay works. So the network seems to be OK.

Regards
Tim

[Smultie]

Can confirm Airplay doesn't work.
Can't even see the Xbian device with iTunes or Beamer.app

Can't find any airplay-related errors in xbmc.log either.....
Any direction??

[Fred]

It works for me (from android device) so I can't help you.

You could try this:

Quote:SSH into your RPi

Terminal

sudo nano ~/.xbmc/userdata/advancedsettings.xml

add this line (where 7000 is the port, could be different, check the port your app is sending to)
Code:
<airplayport>7000</airplayport>

Make sure you add this line somewhere between <advancedsettings> and </advancedsettings> but not in some subsetting. I added it the line before </advancedsettings>.

Reboot or restart XBMC.

Please try this and report back if this works or not.

[Smultie]

(13th Jul, 2013 07:22 AM)Fred Wrote:  It works for me (from android device) so I can't help you.

You could try this:

Quote:SSH into your RPi

Terminal

sudo nano ~/.xbmc/userdata/advancedsettings.xml

add this line (where 7000 is the port, could be different, check the port your app is sending to)
Code:
<airplayport>7000</airplayport>

Make sure you add this line somewhere between <advancedsettings> and </advancedsettings> but not in some subsetting. I added it the line before </advancedsettings>.

Reboot or restart XBMC.

Please try this and report back if this works or not.

My Android phone works as well (with Yatse), but I have an iPad and a MacBook Pro as well, which I would like to work via Airplay.

Any other ppl (devs) who can lead me in the right way?

[mk01]

(13th Jul, 2013 07:12 AM)Smultie Wrote:  Can't find any airplay-related errors in xbmc.log either.....
Any direction??

this is related to dbus-daemon process stopping after some time, I had this issue and probably all users used to work with airplay will report that.

i have to extract from my devel version just this fix and probably update in a hot fix of some kind.

if you log into ssh, issue "sudo start dbus", then it will work probably until next reboot. there dbus will be started, … and then stopped by some other event.

because this topic will repeat and reappear in many threads, I will not update all of them, just focus on the https://github.com/xbianonpi/xbian/issues/423

---

(3rd Jul, 2013 11:59 AM)niftydude Wrote:  Hi mk,
i've tried out that zram-swap script from git and rebooted. Nice. Seems to be working OK:

xbian@xbian ~ $ free
total used free shared buffers cached
Mem: 125112 100740 24372 0 8 22200

xbian@xbian ~ $ sudo swapon -sa
[sudo] password for xbian:
Filename Type Size Used Priority
/dev/mmcblk0p3 partition 262140 0 -1
/dev/zram0 partition 131068 16784 20


I feel like this is still a little bit slower than alpha 5, but better than beta 1 was. I'll let it run and see how it goes.

thanks for the partswap test. and please update zram-swap to 1.0-3.1 from git, as you can see second terrible "issue" for 256mb models.

sram part size 131068, total memory 125112. it's only question of load until you get swap write error, then oops, then some processed killed and probably panic.

there was 128mb os sram by default, with the revised logic this still applies, but before creating zram the size is compared to total memory available to linux (128) and only 1/3 of that is allowed.

so for 256 models +-45, for 512 depends on the split. but the general rule is = min(128,mem/3)

---

(8th Jul, 2013 07:56 PM)puckMan Wrote:  

(8th Jul, 2013 03:14 PM)niftydude Wrote:  Oh yeah - forgot to mention - yep - tried this, it worked fine for me.

can you please tell me how to try that out?

just add "partswap" to cmdline.txt

[alfredo]

Hi all,

I finally received my sdcard-usb adapter, and could make changes to the btrfs filesystem from my laptop. Here's my mileage: as you asked, my /etc/fstab is the following

Code:

proc            /proc           proc    defaults          0       0
LABEL=xbian-root-btrfs    /    btrfs    subvol=root/@,thread_pool=1,rw,compress=lzo,noatime,autodefrag    0    0
LABEL=xbian-root-btrfs    /home    btrfs    subvol=home/@,thread_pool=1,rw,compress=lzo,noatime,autodefrag    0    0
LABEL=xbian-usb-btrfs    /usr    btrfs    subvol=usr,thread_pool=1,rw,compress=lzo,noatime,autodefrag    0    0
LABEL=xbian-usb-btrfs    /var    btrfs    subvol=var,thread_pool=1,rw,compress=lzo,noatime,autodefrag    0    0
UUID=8B12-9112    /boot    vfat    defaults,noauto,user,gid=0,uid=0    0    0

Furthermore, I disabled stdout and stderr redirection in mountall.conf, and the following is the last message I get, before the aforecited 127 error code.

Code:

btrfs: mismatching generation and generation_v2 found in root item. This root was probably mounted with an older kernel. Resetting all new fields.

I tried searching for people getting the same error message, but didn't find anything that seemed related.

Please let me know if you spot something evidently wrong in my fstab.
In the meanwhile, I'll try again the same configuration with beta 1.1, and let you know how it goes. (Possibly moving on the new thread.)

Thanks again!

[mk01]

(17th Jul, 2013 06:25 AM)alfredo Wrote:  Please let me know if you spot something evidently wrong in my fstab.
In the meanwhile, I'll try again the same configuration with beta 1.1, and let you know how it goes. (Possibly moving on the new thread.)

Thanks again!

there will be no difference, because nothing in the core changed.

---

(17th Jul, 2013 06:25 AM)alfredo Wrote:  Furthermore, I disabled stdout and stderr redirection in mountall.conf, and the following is the last message I get, before the aforecited 127 error code.

127 generally means "target can't be started - not available". on exec, or other call. looks like mountall wan't to start something - i suppose from /usr/sbin.

as upstart is all going around plymouth, dbus, policykits etc, I bet you have winner - something after /sbin/init - mountall

did you try the "debug" parameter in cmdline.txt, it will disbable the redirects for you, it will use --verbose logging for all the processes, redirect all to screen etc.

as a check for this theory with /usr I would open initramfs.gz again, and anywhere between
move_root and echo "Switching root" would put

"mount -t btrfs -o subvol=usr,thread_pool=1,rw,compress=lzo,noatime,autodefrag /dev/XXX (don't use label|uuid there) ${CONFIG_newroot}/usr"

I'm quite sure it will boot. You can try force mountall attention to /usr at all cost with "bootwait" parameter. But we even don't know, if mountall is started. and, to trigger device creation and LABEL|UUID resolving, udev needs to be started. and this is tarted on virtual-filesystems only, which happens cca 3s after startup so not so easy the parallel starting up.

I think the /usr mount from initramfs is safe harbor for now.

try the "debug" param, really.

beta2 is taking control over boot by starting /etc/init/xbian.conf AS ABSOLUTELY FIRST event / started exclusively with nothing else. then, we can easily control process from there.

I hope I put some ideas to your plays.

[xraxor]

Hi guys, anyone know how I can get my HDD to sleep after sometime of no usage? it would sleep after 5min in alpha5, now it stays running.