beta2
|
15th Oct, 2013, 03:22 AM
Post: #481
|
|||
|
|||
RE: beta2 | |||
15th Oct, 2013, 04:13 AM
Post: #482
|
|||
|
|||
RE: beta2
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.
|
|||
15th Oct, 2013, 04:53 AM
Post: #483
|
|||
|
|||
RE: beta2
@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 |
|||
15th Oct, 2013, 05:53 AM
Post: #484
|
|||
|
|||
RE: beta2
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: # dmesg: Code: [ 293.955748] NFS: nfs4_discover_server_trunking unhandled error -512. Exiting with error EIO The 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 no 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? |
|||
15th Oct, 2013, 05:54 AM
Post: #485
|
|||
|
|||
RE: beta2
@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: 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. |
|||
15th Oct, 2013, 06:35 AM
Post: #486
|
|||
|
|||
RE: beta2
@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 |
|||
15th Oct, 2013, 07:24 AM
Post: #487
|
|||
|
|||
RE: beta2
(15th Oct, 2013 06:35 AM)Dizzy Wrote: setting GSSD and IDMAPD as yes by default harms NFSv3 compatibility? 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) 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. Please read rules and do a search before you post! . FAQs . How to post log file? . Looking for answers? Please start here |
|||
15th Oct, 2013, 08:51 AM
Post: #488
|
|||
|
|||
RE: beta2
@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. |
|||
15th Oct, 2013, 08:55 AM
Post: #489
|
|||
|
|||
RE: beta2
(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 Please read rules and do a search before you post! . FAQs . How to post log file? . Looking for answers? Please start here |
|||
15th Oct, 2013, 09:01 AM
Post: #490
|
|||
|
|||
RE: beta2
haha good to know what caused it...
|
|||
15th Oct, 2013, 09:17 AM
Post: #491
|
|||
|
|||
RE: beta2
(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... 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.. |
|||
15th Oct, 2013, 04:00 PM
Post: #492
|
|||
|
|||
RE: beta2
(14th Oct, 2013 07:39 PM)mk01 Wrote: @b0rna 2300 items, but It seemed to already exhibit this sort of frame drop/stutter when ~200 were parsed from TMDB. |
|||
15th Oct, 2013, 05:36 PM
Post: #493
|
|||
|
|||
RE: beta2
@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. @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. |
|||
16th Oct, 2013, 03:00 AM
Post: #494
|
|||
|
|||
RE: beta2
@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 |
|||
16th Oct, 2013, 03:23 AM
Post: #495
|
|||
|
|||
RE: beta2
Hm... Transmission, Sickbeard and Couchpotato doesn't excist for me anymore under packages. The same for anyone else?
|
|||
« Next Oldest | Next Newest »
|