+- Forum (http://forum.xbian.org)
+-- Forum: Software (/forum-6.html)
+--- Forum: Testing & Experimental (/forum-21.html)
+--- Thread: beta2 (/thread-1312.html)
RE: beta2 - IriDium - 15th Oct, 2013 03:22 AM
(14th Oct, 2013 07:39 PM)mk01 Wrote: @all
GOTHAM nightlies
@mk01
I really think there should be a separate thread for this, as this one is really only for Beta 1.2 although badly named as Beta 2 which is something NEW and in the pipeline.
RE: beta2 - mk01 - 15th Oct, 2013 04:13 AM
sure for issues, I don't expect to discuss Gotham issues here. But nobody outside Beta2 group will not be able to get them with simple apt-get install. So that's was the merging point.
RE: beta2 - xraxor - 15th Oct, 2013 04:53 AM
@mk01 I will try and test gotham tonight after TWD
. have quite large library with ~800 movies, some tv shows and plenty of music. hopefully will be good
RE: beta2 - Dizzy - 15th Oct, 2013 05:53 AM
regarding beta 1.2, installed today on a clean 1.1.
videos playing great, sw DTS is great, but I have a network problem.
It seems that xbian has trouble setting up network.
I'm on static IP, dns is google's 8.8.8.8.
What happens is xbian is saying "configuring network" for some 15-20 seconds on boot, then boots fine, and reaches network just fine, ping is fine.
problem is it doesn't mount my NFS shares on boot.
Here's my fstab:
Code:
#
#
#
/dev/mmcblk0p1 /boot xbian rw 0 1
/dev/root /home xbian subvol=home/@,noatime 0 0
/dev/root /lib/modules xbian subvol=modules/@,noatime 0 0
none /run/shm tmpfs noauto 0 0
none /run/user tmpfs noauto 0 0
none /sys/kernel/debug debugfs noauto 0 0
none /sys/kernel/security securityfs noauto 0 0
10.0.0.1://home/_Movies /home/xbian/nfs/Movies nfs rw,hard,intr,noatime,_netdev,comment=systemd.automount 0 0
10.0.0.1://home/_Series /home/xbian/nfs/Series nfs rw,hard,intr,noatime,_netdev,comment=systemd.automount 0 0
10.0.0.1://home/_Music /home/xbian/nfs/Music nfs rw,hard,intr,noatime,_netdev,comment=systemd.automount 0 0dmesg:
Code:
[ 293.955748] NFS: nfs4_discover_server_trunking unhandled error -512. Exiting with error EIO
[ 298.967010] NFS: nfs4_discover_server_trunking unhandled error -512. Exiting with error EIO
[ 303.976360] RPC: AUTH_GSS upcall timed out.
[ 303.976360] Please check user daemon is running.
[ 303.976662] NFS: nfs4_discover_server_trunking unhandled error -512. Exiting with error EIO
[ 308.256185] init: xbian-net post-stop process (422) terminated with status 124
[ 308.716118] zram: module is from the staging directory, the quality is unknown, you have been warned.
[ 308.737766] zram: Created 4 device(s) ...
[ 308.988125] NFS: nfs4_discover_server_trunking unhandled error -512. Exiting with error EIO
[ 309.022714] Adding 37884k swap on /dev/zram0. Priority:20 extents:1 across:37884k SS
[ 309.335020] Adding 191996k swap on /dev/mmcblk0p3. Priority:0 extents:1 across:191996k SS
[ 323.271865] init: wait-for-state (xbmcxbmc-loaded) main process (1633) killed by TERM signal
[ 333.317893] init: xbmc-loaded post-stop process (1878) terminated with status 1The first line is repeated multiple time...
Code:
Starting XBMC (12.2 Git:20130916-091cb29), Platform: Linux (Debian GNU/Linux 7.1 (n/a), 3.10.12+ armv6l). Built on Oct 2 2013
Raspberry PI firmware version: Oct 1 2013 00:37:09
Copyright (c) 2012 Broadcom
version a421d4b2cee544ec22bd4eee75080248f18fc20b (tainted) (release)
22:23:05 T:3041739296 NOTICE: ARM mem: 156MB GPU mem: 100MBno errors in xbmc.log and the same setup worked alright in 1.1
Videos I have tested run from UPnP from a server XBMC. 30GB DTS6.1 Lord of the Rings, so it's safe to say UPnP is working quite fine.
any ideas?
RE: beta2 - mk01 - 15th Oct, 2013 05:54 AM
@xraxor no it is not.
I installed Frodo back after 2h. The non-working stuff was fixed (like ff/rw with different speeds, video controls like zoom, 4:3 etc) and others. But there are many small glitches and no added value for my usage (comparing to the Frodo 12.2 with backports we use). So I lost patience with it.
But in general it will do what you expect. So it will play a movie for instance
A month ago it was a lot worse. As finest solution up to date looks the Frodo nightly from Beta2 repo + Amber Skin unfortunately not the one adapted for XBian but the actual 1.0.8 from pecinko git or via XBian Addon repo in XBMC (zip installer at http://ivka57.dyndns-ip.com/xbian-xbmc-repository/repository.xbian.xbmc.repository/repository.xbian.xbmc.repository.zip) … the only problem is that I'm not successful in updating Fred's patches to this new version - Fred did it for 0.5.x - so xbian-config is broken there. not totally, but is missing from settings menu and if started as program, spin control is not visible but is there and one more texture. Maybe Brantje would be able to help ? Don't know.(15th Oct, 2013 05:53 AM)Dizzy Wrote:Code:
#
#
#
/dev/mmcblk0p1 /boot xbian rw 0 1
/dev/root /home xbian subvol=home/@,noatime 0 0
/dev/root /lib/modules xbian subvol=modules/@,noatime 0 0
none /run/shm tmpfs noauto 0 0
none /run/user tmpfs noauto 0 0
none /sys/kernel/debug debugfs noauto 0 0
none /sys/kernel/security securityfs noauto 0 0
10.0.0.1://home/_Movies /home/xbian/nfs/Movies nfs rw,hard,intr,noatime,_netdev,comment=systemd.automount 0 0
any ideas?
actually yes. I have it on candidate list to wiki which must be up with release of Beta2. looks like your NFS server is nfs4 (or the expots under this paths are defined as NFS4), but you have "nfs" in fstab (which assumes NFS2/3 - and no nfsvers= in mount options to make this clear for mount helper program).
so XBian assumes NFS2/3, starts rpcbind and statd instead of gssd and required idmapd. there are two ways how to correct this scenario
1) change fstpe to nfs4
2) edit /etc/default/nfs-common and set NEEDS_GSSD=yes and NEEDS_IDMAPD=yes
both will do the job. the same issue was there http://forum.xbian.org/thread-1430-post-16136.html#pid16136 .
I opened now "man nfs" just to be sure about Beta2 logic and found that i'm a bit behind:
" To mount an export using NFS version 2, use the nfs file system type and specify the nfsvers=2 mount option. To mount using NFS version 3, use the nfs
file system type and specify the nfsvers=3 mount option. To mount using NFS version 4, use either the nfs file system type, with the nfsvers=4 mount
option, or the nfs4 file system type."
and few lines back:
"nfs4 FILE SYSTEM TYPE
The nfs4 file system type is an old syntax for specifying NFSv4 usage. It can still be used with all NFSv4-specific and common options, excepted the
nfsvers mount option"
that means, nfs4 is no more required - but still accepted and for exports with NFS2/3 support a well as NFS4 combination fstype=nfs AND mount option "vers=4". So I have to adapt Beta2 then.
Looks like I didn't help you much
) so just open nfs-common and force start of IDMAPD and GSSD. My homework would be keeping nfs4 for compatibility but accepting nfsvers=4 param in fstab even if fstype is nfs (not nfs4).
Please report back then.
RE: beta2 - Dizzy - 15th Oct, 2013 06:35 AM
@mk01, thx!
wasn't the fstab options as you guessed but the nfs-common options worked.
now boots in 7-8 seconds.
BTW, it's a bit strange as my NFS server supplies versions 2-4 according to rpcinfo, I would have guessed it would work out of the box according to the client...
setting GSSD and IDMAPD as yes by default harms NFSv3 compatibility?
Big kudos for 1.2, it's a huge improvement over 1.1 which quite literally made my stomach ache
RE: beta2 - mk01 - 15th Oct, 2013 07:24 AM
(15th Oct, 2013 06:35 AM)Dizzy Wrote: setting GSSD and IDMAPD as yes by default harms NFSv3 compatibility?
Big kudos for 1.2, it's a huge improvement over 1.1 which quite literally made my stomach ache
thanks for reporting back.
I'm just fixing for combo nfs and nfsvers=4 in mount options. will you be ok to test on request by removing "yes" from nfs-common, leaving nfs as fstype in fstab but adding nfsvers=4 to mount options to fstab?
GSSD and IDMAPD will not affect NFS2/3 in any way. on one side it is still NFS, but working own way. you don't need even rpcbind for it, no mountd daemon to provide locking etc (so NFS roots are benefiting from this). they are designed to coexist without issues and also work independently if needed. just /etc/exports file definition can be tricky a bit as there is no direct flag in to specify which is which so if you don't specify in client neither one can run into troubles like yours was.
so it is possible to provide the same directory for NFS2/3 as export with different paths as for NFS4. this are two lines from exports file which will allow this (the folder under /expornfs are just bound from original locations, not physically mounted there):
Code:
/exportnfs 192.168.1.0/24(rw,insecure,no_subtree_check,crossmnt,fsid=0)
/exportnfs/xbmc 192.168.1.0/24(rw,async,no_subtree_check,all_squash,insecure,anonuid=501,anongid=4,sec=sys,no_wdelay)
/exportnfs/media 192.168.1.0/24(rw,async,no_subtree_check,all_squash,insecure,anonuid=501,anongid=4,sec=sys,no_wdelay)this will allow NFS4 browsing and filesystem crossing and server browsing with accessing just the server like media:/ or my_ip:/ . this is NFS4 root where you will see all the export provided by NFS server. this wasn't possible with NFS2/3. you had to mount specifically /media or /xbmc. so you had to know the exports before.
for NFS2/3 previous rules apply so export is to be called media:/exportnfs/media media:/exportnfs/xbmc. so no browsing there.
with the fsid=0 you specifies so called NFS4 root. this is the dir where NFS4 will start if don't specify what you mounts and will allow browsing, referencing, even cross mounting.
and by using media:/xbmc or media:/exportnfs/xbmc as source definition for mount command the nfs client/server negotiates the right protocol - NFS4 for the names which are at root relative to fsid=0 (so like :/media) and NFS2/3 for the full names like /exportnfs/xbmc.
unfortunately this theory around is not clearly described in empty /etc/exports file nor on most wikis/howtos I have seen. but can provide significant saving in complexity of autofs definitions, disk less setups and others. as when you want to add additional export, you just creates new dir under fsid=0, binds the location to it and you are done. you don't to change clients.
so your setup would change like:
1) only one mount to take care of in /etc/fstab in RPI (10.0.0.1://home_export)
2) only one record in /etc/exports ((in case of pure NFS4)):
"/home_export 192.168.1.0/24(rw,no_subtree_check,crossmnt,fsid=0)"
3) then to add / remove Movies / Series / Music would mean
- creating dir /home_export/Movies
- bonding original /home/_Movies to it (mount -o bind /home/_Movies /home_export/_Movies
4) that's IT ! no change on chlient, no change on server in /etc/exports, no need to run "exportfs -a". I know, for three fs this is no difference. But for large systems previous NFS2/3 definitions / workflows have been nightmare to administer.
RE: beta2 - Dizzy - 15th Oct, 2013 08:51 AM
@mk01, of course, I'll check that tomorrow.
btw, found out that inputlirc doesn't start.
steps to reproduce are to install through : "apt-get install inputlirc",
running inputlirc with -g gives a seg fault.
"-g" is used to grab the input device exclusively. maybe a permissions issue?
used to work.
RE: beta2 - mk01 - 15th Oct, 2013 08:55 AM
(15th Oct, 2013 05:53 AM)Dizzy Wrote: regarding beta 1.2, installed today on a clean 1.1.
btw: now as I'm doing the nfsvers acceptance I realized that I hit the same issues as you reported with proper combinations of fstype=nfs and mount options not specified.
this was for years clearly assumed as NFS2/3 and mount.nfs was used. since today, mount.nfs4 is preferred and this caused my test setup (by changing nfs4 to nfs - what I normally do to test statd & port map) to not mount at all for 10 minutes. With inability to start XBMC as part of XBMC's userdata I'm sharing among clients.
Today Debian released Wheezy 7.2 what made available ~ 30 system packages to update - among others nfs-common & stuff. So second issue in the packages in the same day. As "nfsvers=" was and is not required in fstab but clearly there are combinations where new version of nfs helper tools fail to mount.
Normally Beta2 won't install such packages automatically even if set to auto-install because those were not security updates. But they were installed for YOU as you was updating today and one of the commands was "apt-get upgrade"
) so you took them all. All bad has good points and there is one that I will not be surprised if we get more such affected systems!@all
when already speaking about the debian packages available from today, first issue I did hit was that while you will install updates to samba, samba-common and samba-common-bin apt update process will look like frozen. RPi will do nothing, responsive, but update will be like sleeping.
This is cause because of improper launch of whiptail to ask you as user some conf related questions. But this MUST NOT happen as the apt is set to non_interactive in XBian - what means user will never see the dialogs.
So if you hit this as well, do "ps ax | grep whiptail" and kill after. Or just simply "sudo pkill whiptail". Upgrade process should then continue. If dpkg would fail because whiptail killed, just rerun updates. No worries - maybe you will asked for "dpkg —reconfigure -a".
Anyhow this looks like sabotage at Debian
mk
RE: beta2 - Dizzy - 15th Oct, 2013 09:01 AM
haha good to know what caused it...
RE: beta2 - Dave400 - 15th Oct, 2013 09:17 AM
(12th Oct, 2013 02:29 PM)mk01 Wrote:(9th Oct, 2013 06:20 AM)Dave400 Wrote: Bad news.. I installed the lirc update (along with 5 other packages) and now my remote is behaving how it was before, I've rolled back using a snapshot and will install the other updates again but leave out lirc for the time being...
@Dave400
is it possible that xbian-update put lirc_rpi into /etc/modules and by removing it you restore previous functionality?
while looking into /etc/lirc/hardware.conf, first RC which is looked up is lirc_rpi. all others are "else if" so won't never override the lirc RC found as first.
can you report back please?
OK, redone all updates via apt-get, all installed ok (samba-common had to have the dependency fixed via apt-get -f install but all restarted ok afterwards)
remote working fine now, not sure if anything changed on the package but the previous issue I had did not reoccur.
Might have a play with the gotham nightly tomorrow..
RE: beta2 - b0rna - 15th Oct, 2013 04:00 PM
(14th Oct, 2013 07:39 PM)mk01 Wrote: @b0rna
just out of curiosity, how big is your Movies/TVShows library ? do you store as local DB files or shared MySQL setup ?
2300 items, but It seemed to already exhibit this sort of frame drop/stutter when ~200 were parsed from TMDB.
RE: beta2 - mk01 - 15th Oct, 2013 05:36 PM
@b0rna,
if it holds to be fine and steady until ~200 it is more than I would expect as I would expect the system to be stuck at high io && iowaits at around 10x less (as the SoC design handles all this via the slow CPU).
this test is of high value to me, so thanks for it. just a most important final question, did it finish successfully ? as there were reported issues with Beta1X like OOM XBMC crashing or even kernel panics / total freez on Library operations with this size (even smaller).
probably turning off compression on filesystem would make this better, setting vm.dirty_ratio and vm.dirty_background_ratio to lower values as are now by default should have positive effect as well for this one particular action. but this can be tuned later as we get more feedback. unfortunately compression on/off is btrfs pool wide mount setting, it can't be turned off for /home mount and kept for / if they are on the same btrfs filesystem as sub volumes (in contrast ZFS allows that for fine control).
(15th Oct, 2013 08:51 AM)Dizzy Wrote: @mk01, of course, I'll check that tomorrow.
btw, found out that inputlirc doesn't start.
steps to reproduce are to install through : "apt-get install inputlirc",
running inputlirc with -g gives a seg fault.
"-g" is used to grab the input device exclusively. maybe a permissions issue?
used to work.
@Dizzy
can look into it later, but you can maybe investigate more yourself (and quicker than myself) by installing strace package and then running inputlirc binary via it. it will output lots of operations currently happening on the system and related to the inputlirc so probably before the seg fault you will se a operation which resulted in it.
RE: beta2 - mk01 - 16th Oct, 2013 03:00 AM
@brantje,
just fixed your clock screensaver. ver 0.5.3 available in xbian xbmc add ons. works now also in macosx (Frodo / Gotham).
or
http://ivka57.dyndns-ip.com/xbian-xbmc-repository/repository.xbian.xbmc.repository/repository.xbian.xbmc.repository.zip
http://ivka57.dyndns-ip.com/xbian-xbmc-repository/xbian.screensaver.clock/xbian.screensaver.clock-0.5.3.zip
RE: beta2 - danell - 16th Oct, 2013 03:23 AM
Hm... Transmission, Sickbeard and Couchpotato doesn't excist for me anymore under packages. The same for anyone else?