beta2

[webjib]

(29th Sep, 2013 10:56 PM)mk01 Wrote:  When you say "it was ok before" means what? It was ok with Alpha5, Beta1X, or even with Beta2?

With Beta1.1

(29th Sep, 2013 10:56 PM)mk01 Wrote:  What happens when you run this in terminal?

Code:

echo -e "e\nE\nx\nÉconomiseur d'écran\n" | sort

Same as you.

[Smultie]

(29th Sep, 2013 11:42 PM)mk01 Wrote:  @Smultie

xbian-update is only package touching advancedconfig.xml and yes we can take it out. definitely for testing period, maybe Curly or Koen will tell us why it was introduced (I'm sure it had a reason before).

anyhow how it messes up the interface for you? it is resolution for internal rendering only which is then kept or upscaled to FullHD (depending on actual resolution set on boot). I use it as well as otherwise the texts are clearly blurred otherwise but the other way around for people using 720p the internal 1080p means 2.25times more points to render on GUI which are immediately lost on output.

is it changing layout of the screen for you? maybe I don't see anything because of using AMBER which internally runs at 1080?

I'm running Amber too. Basically, what it does ( I think), is rendering a 720p image in a 1080p screen. Ergo only 30-40% of the TV-screen is filled with XBMC. When I set the GUI resolution back at 1080p from SSH (with the add on doesn't work for some reason) and reboot, the image is back to normal.

[mk01]

(29th Sep, 2013 11:49 PM)Smultie Wrote:  I'm running Amber too. Basically, what it does ( I think), is rendering a 720p image in a 1080p screen. Ergo only 30-40% of the TV-screen is filled with XBMC. When I set the GUI resolution back at 1080p from SSH (with the add on doesn't work for some reason) and reboot, the image is back to normal.

I didn't see this issue since ... very long time this is a feature. It has something to do with messed up guisettings.xml, I know deleting it and restarting xbmc always helped (XBMC recreated the resolution settings and WINDOW/DESKTOP mode). and it was triggered always when XBMC changed the internal GUI res from higher to lower - in case previous GUI render res was in line with screen res.

doesn't matter anyhow, I commented the change 1080p -> 720p out.

[webjib]

I've created a new SD card with beta 2, and now, my usb drive is automatically mounted over samba, so maybe my previous configuration was broken somewhere.

However, either with guest or xbian user, I don't have any rights on the drive. Mount options are maybe read-only or something else ?

[mk01]

(29th Sep, 2013 11:47 PM)webjib Wrote:  

(29th Sep, 2013 10:56 PM)mk01 Wrote:  When you say "it was ok before" means what? It was ok with Alpha5, Beta1X, or even with Beta2?

With Beta1.1

would you mind to test the Beta1.1 XBMC binaries on Beta2? xbian-update dependency won't allow you to downgrade it, but the manual overwrite is not so difficult.
log into ssh and

Code:

sudo -i
stop xbmc
cd /tmp
wget http://xbian.brantje.com/pool/main/x/xbian-package-xbmc/xbian-package-xbmc_2.3-0.4_armhf.deb
mkdir xbmc
dpkg -x xbian-package-xbmc_2.3-0.4_armhf.deb xbmc
btrfs-auto-snapshot snapshot --name testxbmc root home
cd xbmc
rm -fr /usr/local/share/xbmc
rm -fr /usr/local/lib/xbmc
mv ./usr/local/share/xbmc/ /usr/local/share/xbmc
mv ./usr/local/lib/xbmc/ /usr/local/lib/xbmc
start xbmc

after tests,

Code:

sudo -i
btrfs-auto-snapshot rollback home/@testxbmc
btrfs-auto-snapshot rollback root/@testxbmc
reboot
btrfs-auto-snapshot destroy home/@testxbmc_rollback
btrfs-auto-snapshot destroy root/@testxbmc_rollback

I tried 2.3-0.4 package and it is the same. Try 2.2 or 2.1 from http://xbian.brantje.com/pool/main/x/xbian-package-xbmc/ .

mk

---

(30th Sep, 2013 12:10 AM)webjib Wrote:  I've created a new SD card with beta 2, and now, my usb drive is automatically mounted over samba, so maybe my previous configuration was broken somewhere.

However, either with guest or xbian user, I don't have any rights on the drive. Mount options are maybe read-only or something else ?

It is somehow my attitude to restrict what is possible ... good I decided not to have locks on toilet doors at my place. I would be locking them from outside as well.

I will add SHARERW=yes/no to usbmount.conf later today and issue update.

Your install wasn't broken, it was like I asked you to confirm, but in-between I got idea of elegant solution without the need of changing boot process and is already issued.

If you umount the mountpoint the share should disappear as well, but I didn't test this yet.

As we speak 1.0.4-6 is ready. Install and change SHARERW=no to yes.
Then

Code:

DEVNAME=/dev/xxx usbmount remove
usbmount /dev/xxx

(what is writable is guest_ok as well (guest writeable) with effective user xbian)

[CurlyMo]

Quote:xbian-update is only package touching advancedconfig.xml and yes we can take it out. definitely for testing period, maybe Curly or Koen will tell us why it was introduced (I'm sure it had a reason before).

Because back then the feature was introduced and we have to add it to the guisettings.xml. Of course this is not needed anymore in subsequent releases.

[Airwolfuk]

(29th Sep, 2013 05:49 PM)Airwolfuk Wrote:  connection pages. I can only setup wifi using ssh Xbian Config and even then that has issues as previously reported. Once my wifi is setup it runs pretty good. With external power I get HD streaming over http most of the time.

what is your xbian-package-config-xbmc and -shell version ? can you start xbian-config XBMC and post few (10-15 lines) of python errors? does "/home/xbian/.xbmc/userdata/addon_data/plugin.xbianconfig" directory exists with those files?
"advancedmode confirmationonchange lastupdatecheck notifyonerror notifyonsuccess"

btw: I aligned the ssh result codes so if you update (at least) xbian-package-config-shell it should not be reverted anymore.
[/quote]

My versions were from last week (Monday). I am running the upgrade now and will report back tomorrow.

[webjib]

(30th Sep, 2013 12:21 AM)mk01 Wrote:  As we speak 1.0.4-6 is ready. Install and change SHARERW=no to yes.
Then

Code:

DEVNAME=/dev/xxx usbmount remove
usbmount /dev/xxx

working perfectly now

[IriDium]

Small point but "May be" significant.

I'm running two "installs" of Beta 1.2
a) Class 10 4GB micro SD card with adapter.
b) Class 4 2GB micro SD card with adapter but booting off a USB 8G Flash drive.

a) seems to run a lot slower and spends a lot more time in a write state, than b) (Monitored with nmon)

Neither setup needed any updates (Last time it worked ) and they are both configured roughly the same (same skin and add-ons) both on the same RPi and peripherals.

The only Xbian difference I can really see is the swap file is smaller (Guess because of the amount of available storage).

It's not a definitive test as I cannot guarantee they are both identical but I would have thought there shouldn't be much difference. I was hoping a) would have been faster, but it appears that maybe a USB installation is quicker.

Any ideas why? Is the I/O on the SD card slower than the USB ?

[wind-rider]

(29th Sep, 2013 09:23 PM)mk01 Wrote:  

(28th Sep, 2013 11:04 PM)wind-rider Wrote:  I know that the possibility to boot from usb being developed, but could this also be used to boot from NFS?

I tried it with Beta 1.1 but couldn't get the settings right for fstab and cmdline.txt.

Are there any people who succeeded in doing this?

NFS boot is not such a big success story as it mostly looks reading internet, already CurlyMo's Alpha5 was able to boot NFS with few small mods. Since early Beta development it was a feature and I was using it until switch to btrfs which provided for me similar targets even more.

I will check the actual status with all the changes for past months get back to you.

But as insights general requirement is:
1) kernel with auto ip configuration
2) correct kernel command line options (ip= for kernel auto ip, root=/dev/nfs, nfsroot=10.0.0.10:/path/to/root,nfs_mount_options, bug-free networking scripts - some versions of Debian used to ifdown & ifup already UP network with rootfs mounted on it ... bad bad)
3) with NFS3, nolock is a must as mount option (you don't have rpcbind & statd available during mount) - with NFS4 it's much more straight forward
4) nfs export from server with no_root_squash
5) the NFS should contain simple copy of your system, rsync or even cp -arvd will do just fine

Like I said, will recheck later today and post mini-howto.

Thank you very much for replying more in-depth! I tried following these guides:
http://youresuchageek.blogspot.nl/2013/01/raspberrypi-root-over-nfs-share.html
http://cellux.github.io/articles/moving-to-nfs-root/
http://www.raspberrypi.org/phpBB3/viewtopic.php?f=63&t=5974

However I didn't succeed, and gave up because I thought that my NAS's NFS daemon might not be 100% reliable (my NAS has built-in NFS where I have no control over all parameters). I'll try again coming week. However, it would also be nice to know if somebody else succeeded because I couldn't find any success stories about this with XBian. That's also why I asked - to know whether it was worth trying

Also - the layout of the fstab was a bit different than I was used to (it used LABEL=, @root etc), and the guides I read didn't cover changing that. That's also why I asked.

So it would be great if you could write something about the XBian-specific parts of achieving this, and the requirements

[darrylb]

Ok... So, I was able to (from a clean image) actually get Beta 2 installed. Now, I just run into the problem that the RaLink RT5370 (http://www.ebay.com/itm/171027110556?ssPageName=STRK:MEWNX:IT&_trksid=p3984.m1497.l2649)

So far no success. (Dmesg):

[ 14.765781] ieee80211 phy0: rt2x00_set_rt: Info - RT chipset 5390, rev 0502 detected
[ 15.009374] init: failsafe main process (479) killed by TERM signal
[ 15.092764] ieee80211 phy0: rt2800_init_eeprom: Error - Invalid RF chipset 0x3070 detected
[ 15.092794] ieee80211 phy0: rt2x00lib_probe_dev: Error - Failed to allocate device
[ 15.093032] usbcore: registered new interface driver rt2800usb
[ 16.242432] device label xbian-root-btrfs devid 1 transid 334 /dev/mmcblk0p2
[ 18.377578] input: lircd as /devices/virtual/input/input0

[mk01]

(30th Sep, 2013 04:12 AM)IriDium Wrote:  The only Xbian difference I can really see is the swap file is smaller (Guess because of the amount of available storage).

It's not a definitive test as I cannot guarantee they are both identical but I would have thought there shouldn't be much difference. I was hoping a) would have been faster, but it appears that maybe a USB installation is quicker.

Any ideas why? Is the I/O on the SD card slower than the USB ?

partswap parameter (creating a partition at end of the card) is not considering actual device size and is fixed to 256MB. if on b) is total swap bigger, then probably because both SD and USB contain swap partitions?

until actually the swap would be full, there is can be no difference in core speed (0% utilization of 1gb swap is no different to 0% util on 256mb swap).

just theoretically (without touching the setups myself) the a) must boot faster as beta2 will skip initramfs phase if root device is located on mmcblk0. this makes 6 seconds (this skip will be active after one reboot into the same media - so you put a) starts, reboot and initramfs will not be loaded until root= parameter is outside mmcblk0. whether initramfs.gz is used for next reboot is decided during reboot / shutdown and setting is local to the SD card being active (just for info)).

then important role in your test is how and when you created the filesystems (whether flash Beta1 + update, or one was copy via xbian-config etc). also, Beta1 img filesystem was created with older structure (older kernels) and with different parameters - it uses leaf size of 4K and duplicate metadata profile (each metadata is written twice). Beta2 img will be crated (and copies via xbian-config are) with 16K leaf and single profile. The perceived latency and speed of metadata operations are miles faster.

I'm running SD class10 16gb A-DATA card (I reformated it already, so "new" standard). Now created xbian-copy copy to micro class4, size of 8GB. to be honest I was expecting difference due to 10/4class, but the class10 loads xbmc in 31s, the micro class4 in 29s (standard XBian clocking, timing taken from /run/upstart-ev.log as time when xbmc-loaded service is started - what is triggered by XBMC itself as last event after all internal services are started, all python threads started, addons with autostart started and skin is fully loaded including UI objects active). second reboot measured (so no-initramfs) and install is clean Beta1.0 image + update to Beta2. nothing else. eth0 used and set to DHCP mode no non-Beta2 switches or tuning, nor disabled services. With clocking to 930/420/500/2 and static IP, it is up in 23s.

I assume the class10 seems to be slower because of cca 100 snapshots, while the class4 was just clean like a virgin.

how you measure or got the feeling about one being slower / faster ?

btw: just to give you some idea how actual setup affects for instance boot, AMBER with large bitmaps, +6s, 1channel plugin installed +2-3s. Wifi plugged in with working configuration +3s (with parallel eth0), other SD card/USB stick plugged in +3s, USB hub with NO DEVICES attached +1-5s (depends on number of ports to scan) etc.

So when I want to compare or check speed between changes, I always do a NEW snapshot from @safe (Beta1.0), reboot to the new snapshot install updates, reboot, reboot. Then I get comparable numbers.

But it is quite interesting topic indeed specially on the poor weak RPI cause even how you are breathing will change factors and timing in -5+5s

---

(30th Sep, 2013 10:48 AM)darrylb Wrote:  Ok... So, I was able to (from a clean image) actually get Beta 2 installed. Now, I just run into the problem that the RaLink RT5370 (http://www.ebay.com/itm/171027110556?ssPageName=STRK:MEWNX:IT&_trksid=p3984.m1497.l2649)

is it this one problem?

https://github.com/xbianonpi/xbian/issues/421

how you got it working on previous releases? if you share info, no problem to implement.

---

(30th Sep, 2013 08:48 AM)wind-rider Wrote:  Also - the layout of the fstab was a bit different than I was used to (it used LABEL=, @root etc), and the guides I read didn't cover changing that. That's also why I asked.

I promised - I will deliver - anyhow don't bother for rootfs "/", once mounted it can be missing from /etc/fstab, /home, /lib/modules will have to go out as well (cause no subvolumes on NFS) and I have to check all upstart dependencies for possible mounted or mounting events (they were used before, but plan was to remove them to make Beta2 as less dependent on actual boot device as possible (even on filesystem type).

just out from interest: https://github.com/xbianonpi/xbian-package-initramfs/pull/5

6 months old. Nobody was using beside me and I stopped when EXT4->BTRFS change to be on the same system as users. Since then lot happened and NFS was never tested again. I go on it now, so +-1h.

---

(30th Sep, 2013 02:36 AM)Airwolfuk Wrote:  My versions were from last week (Monday). I am running the upgrade now and will report back tomorrow.

ok, thanks

[darrylb]

@mk01 : I have not had success in previous version. This is a new wifi that I am trying to use, as I believe it will be more reliable, is faster, and will provide better signal for my home. The last one I had success on was Xbian 1.0a5, and I had to run the "Wireless config script".

As for "is this the same", I cant quite tell. I see different output, but it does look similar. That being said, I would not hesitate to give you access into my PI, for testing purposes as that other thread indicates not having one to test with. I can reoute the SSH port to it for you, and we can talk in PM if you are interested. Otherwise, just let me know if there is anything I can do.

[mk01]

(30th Sep, 2013 11:30 AM)darrylb Wrote:  As for "is this the same", I cant quite tell. I see different output, but it does look similar. That being said, I would not hesitate to give you access into my PI, for testing purposes as that other thread indicates not having one to test with. I can reoute the SSH port to it for you, and we can talk in PM if you are interested. Otherwise, just let me know if there is anything I can do.

ok, will try to grab some docs via google tomorrow, otherwise we will do the remote access. if I don't get back to you don't hesitate to remind me.

---

Can you just quit post "lsmod" after the dongle inserted and errors appear in dmesg ?

---

what about this ? https://github.com/raspberrypi/linux/commit/876ddb40b773c8e29583cb9ec6946b6b5f3d1179

will check whether it fits 3.10.y headers, but suppose yes.

[darrylb]

@mk01 :

Terminal

root@xbian:/proc# lsmod
Module Size Used by
configs 23648 0
zram 6288 1
frandom 3296 0
uinput 5128 1
rt2800usb 13725 0
rt2800lib 55824 1 rt2800usb
rt2x00usb 6308 1 rt2800usb
rt2x00lib 27568 3 rt2x00usb,rt2800lib,rt2800usb
mac80211 240400 3 rt2x00lib,rt2x00usb,rt2800lib
cfg80211 148732 2 mac80211,rt2x00lib
crc_ccitt 944 1 rt2800lib
led_class 1860 1 rt2x00lib
lirc_rpi 4756 3
lirc_dev 6580 1 lirc_rpi
rpcsec_gss_krb5 17120 0
root@xbian:/proc#

Terminal

xbian@xbian ~ $ lsusb
Bus 001 Device 002: ID 0424:9512 Standard Microsystems Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp.
Bus 001 Device 004: ID 148f:3070 Ralink Technology, Corp. RT2870/RT3070 Wireless Adapter
xbian@xbian ~ $

I have been leaving the USB plugged in. When I plug it in while it is already started, the device restarts. Please note, I have 1amp powering the pi, and am using the first model version.

That particular link seems very accurate to my issue. I am an IT guy, but sadly my strengths are limited to hardware/Windows System Admin/DBA type work, and linux is fairly foreign to me so I really wouldnt know what to do based on those links. Available to do anything you need Just let me know.