beta2

[Airwolfuk]

(10th Sep, 2013 04:55 AM)mk01 Wrote:  I would say the fact it was connecting / not-connecting and speed you got finally will have the same reason. First of all I would exclude the usual factors as for example a neighbor who installed five new wifi APs - so traffic / channel overlapping / sharing.

What practically changed from beta1.1 is kernel - wifi driver with it of course. It would be possible to have performance differences between releases, can happen, but not to the extend of not being able handshake with AP. Keep us informed.

Thanks for the guidance. Usual factors checked and nothing obvious. Also, rebooted several times and connects ok but speed is still a problem. From my iPad using speedtest app I get 6-7mbs download which is about what I was getting before.

I see there are upgrades available from your repo so will upgrade and report back

[mk01]

definitely the updates won't help, until there is commit to kernel specifically about problem you are experiencing. And I don't remember any fixes in 3.10.x around this. the drivers are pretty old (atheros).

is it atheros or rtl ?

[anonimo200]

Good evening. Congratulations once again. The update went perfect and everything seems to work (I'll keep on checking), but I've noticed it takes more time to boot (before the update I could see the Xbmc menu in 33 seconds and now it takes 40) I know, I know, 40 seconds is great but from 33 to 40 is a 21% increase. Is there anything running now that wasn't before and can be stopped (xbmc-bridge is new, right?)? Network takes longer to start too.
As always, thanks for your help.

[mk01]

anonimo200

btrfs filesystem is doing massive updates & cleanup after such big data movement (installing xx packages). also, btrfs is mounted with defrag options which is also running yet some time after the stressing. give it some time (1-2h). definitely do not count first reboot.

definitely I do not intent to lose any second. i'm comparing with beta1 with standard xbian clocking and cleanly flashed image. that was 36s and beta2 is doing the same.

you are right with the network - that is because using isc-dhcp client which is very slow. but reason for that are stupid DHCP servers not conforming to standards where other dhcp clients could not get IP address . for beta2 I wrote my own dhcp scripting based on klibc ipconfig what was making RPI getting dhcp IP in 9 seconds after start, static around 7-8 (without using kernel configuration).

but at the end that is not so significant to total boot time as it seems. there is still full debug info turned on for beta2 (check files /run/upstart-ev.log and -mnt.log, uptime_start.log), there you will see exact timings.

rpi can boot xbmc in 25seconds WITH initramfs which is eating some 5s, so don't be afraid we will go to 60. beta1 was a platform change, beta2 aims to be as wide compatible and bug free as possible and when this will be confirmed, it will take round of loosing weight again.

and to answer to you question, all essential services have been moved from sysv runlevels to upstart (basically it means what was starting behind xbmc is now starting as part of upstart process).

[anonimo200]

Thank you mk01 for your quick and full explanation. I think I can live with 40 seconds (or even 60 :-) ) Please, when Beta 2 is launched tell us how to stop the debug info processes (I'll try to avoid a clean installation).
By the way, I've installed Jezz_X's Slik skin and it's reeeeaaaalllyyyy fast: http://code.google.com/p/jezzxbmc/
It's quite dark but I made some modifications to Home.xml so you can see the background images (trial and error...) If someone is interested just tell me.
Regards

[mk01]

with public beta2 the debugging will be of course not included.

can you post your /run/upstart-ev.log ?

[anonimo200]

Of course, I’ll post it this evening, I’m at work now… And will try NFS, yesterday it was quite late.
I meant, how to stop the debug processes in my current installation (not now, when Beta 2 is released) to avoid installing Beta 2 (althought probably it's better a clean installation)

[mk01]

I know what you mean - but no manual steps will be needed as there will be again just regular deb update to xbian-update and the process (installing the package) will take care even of removing debugging stuff. there is nothing outside deb packages, so once we remove those, they will be removed even from your actual installation.

Still there is one benefit of doing clean ref lash of beta2 image once it becomes available as rootfs will be created with different parameters for speed optimalizations and just updating .debs will not do that. but it won't be mandatory.

Even the ref lash will be easy, as xbian-config offers function to backup whole /home to a file, which can be easily downloaded via SMB from windows for example (by opening xbian on network, going to xbian-backup share and downloading the .img).

once fresh image is deployed, one has just to again open xbian on network and copy the img to xbian-backup/put_here_to_restore folder.

whole /home (so xbian home dir, xbmc settings including libraries, add ons, add ons settings) will be restored automatically and xbmc restarted.

[Airwolfuk]

(10th Sep, 2013 05:44 AM)mk01 Wrote:  definitely the updates won't help, until there is commit to kernel specifically about problem you are experiencing. And I don't remember any fixes in 3.10.x around this. the drivers are pretty old (atheros).

is it atheros or rtl ?

lsusb reports

Bus 001 Device 004: ID 0846:9041 NetGear, Inc. WNA1000M 802.11bgn [Realtek RTL8188CUS]

so rtl to answer your question

I think it has something to do with power even though on beta 1.1 i used the same method (TV USB) and got better performance.

Also, the Xbian setup in XMBC is now really slow and the network setup generally fails. Xbian-config when i SSH in is OK and sets up the network along with other options really quick.

[IriDium]

(10th Sep, 2013 03:31 AM)mk01 Wrote:  

(10th Sep, 2013 01:55 AM)IriDium Wrote:  Now started getting Yellow message on startup in XBMC "Remote communication server - failed to start".

Nothing significant in xbmc.log or dmesg.

Ref the update: It did not ask for a reboot which surprised me. Could it have got confused and thought initramfs-tools was an Xbian-update?

Will keep an eye on it for the next update.

with the "remote comm failed" could it be you did restart xbmc (or xbmc reloaded) - instead of stop / start xbmc ?

i know what is causing it, but can't pin point exact combination when.

and with the update - so reboot wasn't requested. but you rebooted, then started xbmc - xbian-config-xbmc and xbian-update was there again as available to upgrade. that was the workflow (to be able to reproduce) ?

Remote comm failed was from a power off situation. Ie. 1st boot. I rebooted with stop xbmc, start xbmc and it was not there. Will monitor to see when I see it - but it always seems to be within a minute of xbmc starting.

Upgrade: Yes - no reboot reqwuested. So I rebooted with sudo reboot just to see. Went into xbmc xbian-config and it was still there. The ssh xbian-config method worked, and it no longer showed in xbmc xbian-config.

---

Latest upgrades installed.

In xbmc xbian-config - Services. Daemons are listed as a number 1 -> 17 instead of their respective names. Is this correct?

xbian-xbmc-bridge is stopped - is that correct?

So is ssh but it's possible to ssh in - have we changed the service and nt updated xbmc xbian-config?

xbmc xbian-config now takes about 5 minutes to complete - spends most of it's time on updating services. Also the progress bar doesn't work anymore.

[mk01]

(10th Sep, 2013 10:45 PM)IriDium Wrote:  In xbmc xbian-config - Services. Daemons are listed as a number 1 -> 17 instead of their respective names. Is this correct?

xbian-xbmc-bridge is stopped - is that correct?

So is ssh but it's possible to ssh in - have we changed the service and nt updated xbmc xbian-config?

xbmc xbian-config now takes about 5 minutes to complete - spends most of it's time on updating services. Also the progress bar doesn't work anymore.

will check it, changed something in config and probably broke config-xbmc.

the updating xbian-update story - I was going through the command xbmc-config is issuing to shell-config and was able to upgrade it

we are missing something there, but Belese confirmed xbmc-config holds no cache for this and shell-config's cache around updates is store in /tmp which gets emptied upon restart.

but we will find it …

---

(10th Sep, 2013 07:17 PM)Airwolfuk Wrote:  so rtl to answer your question

I think it has something to do with power even though on beta 1.1 i used the same method (TV USB) and got better performance.

please edit /etc/sysctl.d/xbian.conf and put a # at the start of all lines starting "net."

I was shortening some timeouts, if the wifi would be slower (from whatever reason) this theoretically could make it even worse - if packets would come later, with shorter lifetimes kernel could (instead of waiting) just close the connection what from user / program perspective could show much more slower transfers.

try it.

[IriDium]

@Airwolfuk - are you using the WIFI dongle in the RPi or on a POWERED HUB?

I just tested mine and it was drawing around 400ma at peak rate - way more than the RPi can give, so it could be lowering performance! Just a thought.

[IriDium]

Tried to start xbian-xbmc-bridge via ssh xbian-config but it failed to start.

Prior to the latest update. ssh xbian-config -> Xbian system copy tool: doesn't give an option to cancel - one has to <escape>

[anonimo200]

@mk01
can you post your /run/upstart-ev.log ?

Before posting the log... Sometimes I mount NFS by ssh to copy files to/from my PC. When running the command it takes longer than in beta 1 to execute ( mount -t nfs 192.168.1.3:/shareddirectory /media/NFS )
In Xbmc it's the same, the first time I access NFS it takes longer than in previous versions. Samba is more or less the same than before.

Ok, here is the file:
6.96 1.66 job= event=xbian if= on_boot= rl= setup= 0.00 0.00 0.00 9/70 275
7.02 1.66 job=xbmc-failed-start event=started if= on_boot= rl= setup= 0.00 0.00 0.00 9/70 277
7.00 1.66 job=procps event=started if= on_boot= rl= setup= 0.00 0.00 0.00 10/70 280
7.11 1.66 job=hwclock.sh event=started if= on_boot= rl= setup= 0.00 0.00 0.00 6/66 287
7.14 1.66 job= event=not-container if= on_boot= rl= setup= 0.00 0.00 0.00 5/63 289
7.26 1.66 job=xbmc-preload event=started if= on_boot= rl= setup= 0.00 0.00 0.00 2/59 295
7.65 1.66 job=mountall event=started if= on_boot= rl= setup= 0.00 0.00 0.00 9/73 324
8.55 1.66 job=dbus event=started if= on_boot= rl= setup= 0.00 0.00 0.00 4/83 396
8.70 1.66 job=portmap event=started if= on_boot= rl= setup= 0.00 0.00 0.00 5/83 413
8.80 1.66 job= event=xbian-nowait if= on_boot= rl= setup= 0.00 0.00 0.00 5/84 419
9.29 1.66 job= event=net-device-up if=eth0 on_boot= rl= setup= 0.00 0.00 0.00 13/99 467
9.65 1.66 job=network-interface event=started if=eth0 on_boot= rl= setup= 0.00 0.00 0.00 8/96 483
10.36 1.66 job=xbian-fstab event=started if= on_boot= rl= setup= 0.64 0.13 0.04 9/107 532
10.36 1.66 job=xbmc event=starting if= on_boot= rl= setup= 0.64 0.13 0.04 9/107 532
11.93 1.66 job=udev event=started if= on_boot= rl= setup= 0.64 0.13 0.04 15/118 593
11.86 1.66 job= event=filesystem if= on_boot= rl= setup= 0.64 0.13 0.04 15/118 593
12.45 1.66 job=mountall event=stopped if= on_boot= rl= setup= 0.64 0.13 0.04 8/107 622
12.89 1.66 job= event=net-device-up if=lo on_boot= rl= setup= 0.64 0.13 0.04 14/112 646
12.95 1.66 job=xbian-fstab event=stopped if= on_boot= rl= setup= 0.64 0.13 0.04 14/108 648
13.49 1.66 job= event=static-network-up if= on_boot= rl= setup= 0.64 0.13 0.04 5/96 671
13.57 1.66 job=network-interface event=started if=lo on_boot= rl= setup= 0.64 0.13 0.04 4/93 674
13.75 1.66 job=avahi-daemon event=started if= on_boot= rl= setup= 0.64 0.13 0.04 6/93 680
13.86 1.66 job=xbian-net event=started if= on_boot= rl= setup= 0.64 0.13 0.04 7/89 686
14.19 1.66 job= event=startup if= on_boot=n rl= setup= 0.64 0.13 0.04 10/90 708
14.22 1.66 job=udevtrigger event=started if= on_boot= rl= setup= 0.64 0.13 0.04 9/91 710
14.32 1.66 job=xbian-net event=stopped if= on_boot= rl= setup= 0.64 0.13 0.04 10/90 713
14.38 1.66 job=module-init-tools event=stopped if= on_boot= rl= setup= 0.64 0.13 0.04 8/88 714
16.42 1.66 job= event=net-device-added if=lo on_boot= rl= setup= 2.35 0.50 0.16 9/111 783
16.55 1.66 job= event=net-device-added if=eth0 on_boot= rl= setup= 2.35 0.50 0.16 8/110 785
18.52 1.66 job=udevtrigger event=stopped if= on_boot= rl= setup= 2.35 0.50 0.16 5/97 812
18.64 1.66 job=networking event=started if= on_boot= rl= setup= 2.35 0.50 0.16 6/99 817
21.50 1.66 job=lirc event=started if= on_boot= rl= setup= 2.56 0.57 0.19 2/77 884
34.54 1.69 job=xbmc event=started if= on_boot= rl= setup= 2.54 0.63 0.21 8/182 1064
34.52 1.69 job=xbmc-done event=started if= on_boot= rl= setup= 2.54 0.63 0.21 9/183 1063
34.56 1.69 job=rc-sysinit event=started if= on_boot= rl= setup= 2.54 0.63 0.21 5/178 1065
35.25 1.69 job= event=runlevel if= on_boot= rl=2 setup= 2.74 0.71 0.24 11/195 1102
35.30 1.69 job=rc event=started if= on_boot= rl=2 setup= 2.74 0.71 0.24 10/193 1105
35.39 1.69 job=anacron event=started if= on_boot= rl= setup= 2.74 0.71 0.24 8/191 1107
35.40 1.69 job=cron event=started if= on_boot= rl= setup= 2.74 0.71 0.24 8/189 1109
38.10 1.69 job=rc event=stopped if= on_boot= rl=2 setup= 2.74 0.71 0.24 4/188 1220
371.69 247.09 job=xbmc-screensaver event=started if= on_boot= rl= setup= 1.10 0.65 0.33 4/186 1696

If I can help with anything else please tell me.
Regards

[anonimo200]

Strange behaviour here. My TV goes to stanby when the screensaver should start in Xbmc. Nothing to do with the options in Peripherals. I can't run cec-config in ssh.

Edit: nop, it goes to stanby after a few minutes even when the screen has gone dim.