philippe_44 wrote:
Hi - Maybe a silly question: With use of piCorePlayer in RasPi A+, it is
possible to have a very small solution that potentially can be easily
fit inside active speakers directly. One of the problem of that is
stereo management. I was wondering is anybody has ever thought
Lestrad wrote:
I'm trying to get my music share mounted as NFS too. I've enabled the
NFS service on the NAS and set the default permissions to rw. Then I
went to the Storage tab in the SOA frontend and entered /mnt/netnas (a
directory I'd created on the Wandboard) under Mountpoint and
Krisbee wrote:
The error message is telling you what is wrong. In the Network share
box you should have entered:
Code:
192.168.0.15:/media
Why not use one of the inbuilt mount points - /mnt/disk1, etc?
Thanks. I entered
Hi - Maybe a silly question: With use of piCorePlayer in RasPi A+, it is
possible to have a very small solution that potentially can be easily
fit inside active speakers directly. One of the problem of that is
stereo management. I was wondering is anybody has ever thought about
modifying
Krisbee wrote:
OK, possible version clash of nfs versions on wandboard ( vers4) and
ReadyNAs (vers 3 ?). You could try to add a vers=3 option to the
mount command, but SOA might not handle this correcty, e.g:
Code:
mount -t nfs -v -o vers=3
philippe_44 wrote:
Hi - Maybe a silly question: With use of piCorePlayer in RasPi A+, it is
possible to have a very small solution that potentially can be easily
fit inside active speakers directly. One of the problem of that is
stereo management. I was wondering is anybody has ever thought
steve-g
Try adding the line
192.168.0.198:/c/media /mnt/disk1 nfs
vers=3,nolock,users,auto,x-systemd.automount,x-systemd.device-timeout=10,timeo=14,noatime
0 0
to your /etc/fstab and reboot
Simon.
simoh's Profile:
utgg wrote:
I think you need to connect a gps to each raspberry pi and use the
SqueezeGpsSync plugin, which synchronises the two players to nanosecond
accuracy, also compensating for minor speaker positioning errors.
:-) Fools day ?
LMS 7.7.2 - 5 radio, 3 Boom, 4 Duet, 1 Touch, 1 SB2.
Krisbee wrote:
Make that journalclt -n 50 and post again. Looking for log entry
similar to this soa-rpi sudo[343]: root : TTY=unknown ; PWD=/ ;
USER=root ; COMMAND=/usr/sbin/mount -t nfs -o defaults,_netdev
192.168.0.20:/media/musdata/Te to show what command was executed.
Here's what I get:
steve-g wrote:
Thanks Krisbee
This seems to be the relevant bit of journalctl:
Code:
Apr 01 10:25:35 soa-wandboard systemd[1]: Starting RPC Port Mapper.
Apr 01 10:25:35 soa-wandboard systemd[1]: Reached target RPC Port Mapper.
Apr 01 10:25:35
Lestrad wrote:
Here's what I get:
-
[root@soa-wandboard /]# mount -t nfs -v -o vers=3 192.168.0.15:/media
mnt/netnas
mount.nfs: timeout set for Wed Apr 1 11:49:20 2015
Job for rpc-statd.service failed. See systemctl status
rpc-statd.service and journalctl -xe for
Linvincible wrote:
Hi Jens,
Are you using an I2S DAC?
GPIO 18 is pin 12, used for the bit clock I2S output...
If you use the I2S output you'll need to change that GPIO on the LIRC
config by another one.
I'm also interested by the LIRC config and not knowledgeable enough to
do it
Pascal Hibon wrote:
There is a standard feature in LMS that allow you to define what
channels your player will use. This way you can have one player setup to
play the left channel and another player for the right channel. It is in
PlayerName Audio Output Channel Mode.
Then synchronize the
Krisbee wrote:
OK, possible version clash of nfs versions on wandboard ( vers4) and
ReadyNAs (vers 3 ?). You could try to add a vers=3 option to the
mount command, but SOA might not handle this correcty, e.g:
Code:
mount -t nfs -v -o vers=3
steve-g wrote:
Thanks Simon - that works!
Update on that - the Wandboard locked up after a few seconds play of
some music (hi-def if that makes any difference)
Simon has manually the /etc/fstab file. I would prefer to solve the
problem using the SOA web storage page if possible without the
utgg wrote:
I think you need to connect a gps to each raspberry pi and use the
SqueezeGpsSync plugin, which synchronises the two players to nanosecond
accuracy, also compensating for minor speaker positioning errors.
SqueezeGpsSync only works for 4.1 speaker setup's not for plain stereo
Lestrad wrote:
--
Apr 01 10:08:37 soa-wandboard systemd[14802]: Starting Timers.
Apr 01 10:08:37 soa-wandboard systemd[14802]: Reached target Timers.
Apr 01 10:08:37 soa-wandboard systemd[14802]: Starting Sockets.
Apr 01 10:08:37 soa-wandboard systemd[14802]: Reached target Sockets.
simoh wrote:
steve-g
Try adding the line
192.168.0.198:/c/media /mnt/disk1 nfs
vers=3,nolock,users,auto,x-systemd.automount,x-systemd.device-timeout=10,timeo=14,noatime
0 0
to your /etc/fstab and reboot
Simon.
Thanks Simon - that works!
bpa wrote:
Maybe but the idea of a better time sync on Pi's for better audio sync
may not be wrong see
http://forums.slimdevices.com/showthread.php?97046-Announce-Squeezelite-a-small-headless-squeezeplay-emulator-for-linux-(alsa-only)p=814030viewfull=1#post814030
hmmm ... maybe but for what
Lestrad wrote:
Is there a DUHHH.. smiley? I just realized I was using the wrong IP
address. Sorry. I'll get back to you in a bit...
Here's what I get when I use the right IP address:
rpcinfo -u 192.168.0.14 nfs:
program 13 version 2 ready and waiting
program 13 version 3 ready and
Krisbee wrote:
As you've confirmed your NFS server accepts version4 connections,
shouldn't your manual mount command be (the v switch is for verbose
output):
Code:
mount -v -t nfs4 192.168.0.14:/c/media
Here's the result I get:
Lestrad wrote:
Here's what I get when I use the right IP address:
rpcinfo -u 192.168.0.14 nfs:
program 13 version 2 ready and waiting
program 13 version 3 ready and waiting
program 13 version 4 ready and waiting
and
showmount -e 192.168.0.14:
Export list for
steve-g wrote:
Its fun this isn't it!
The '-o' in mount -t nfs -o 192.168.0.14:/c/media media/netdrive is the
problem - -o causes the '192.168.0.14:/c/media' to be treated as an
option string.
Without the '-o' I get: mount.nfs: an incorrect mount option was
specified
I'm beginning
Lestrad wrote:
Thanks. I entered 192.168.0.15:/media and got this error message:
*mount.nfs: an incorrect mount option was specified *
I tried with /mnt/disk1 and got the same error...
Post the last few lines of journalctl -f output here, this should show
you the mount command executed
Krisbee wrote:
Post the last few lines of journalctl -f output here, this should show
you the mount command executed by webinterface.
--
Apr 01 10:08:37 soa-wandboard systemd[14802]: Starting Timers.
Apr 01 10:08:37 soa-wandboard systemd[14802]: Reached target Timers.
Apr 01 10:08:37
Lestrad wrote:
Here's what I get when I use the right IP address:
rpcinfo -u 192.168.0.14 nfs:
program 13 version 2 ready and waiting
program 13 version 3 ready and waiting
program 13 version 4 ready and waiting
and
showmount -e 192.168.0.14:
Export list for
Could you now try -o nolock
Simon.
simoh's Profile: http://forums.slimdevices.com/member.php?userid=56305
View this thread: http://forums.slimdevices.com/showthread.php?t=101624
Krisbee wrote:
Steve,
Ok, as I suspected SOA can have a problem when the option for a NFS
version 3 connections is specified. On the Wandboard you can check what
version of NFS connections your NFS server will accept with this
command:
Code:
rpcinfo -u
philippe_44 wrote:
:-) Fools day ? (I'm not an audiophile BTW)
Maybe but the idea of a better time sync on Pi's for better audio sync
may not be wrong see
Krisbee wrote:
Well there's no evidence of what happened there, but I notice
rpc-statd.service failed. You need to check your NFS configuration from
the Wandboard as root:
Is there a DUHHH.. smiley? I just realized I was using the wrong IP
address. Sorry. I'll get
simoh wrote:
Could you now try -o nolock
Simon.
Thanks. Here's the result:
[root@soa-wandboard /]# mount -v -t nfs4 -o nolock 192.168.0.14:/c/media
media/netdrive mount.nfs4: timeout set for
Wed Apr 1 15:08:17 2015
mount.nfs4: trying text-based options
OK. I'm just trying to remember how I solved this a couple of months
ago. Whatever the solution was didn't allow for auto-mounting after a
reboot, which is why I resorted to the fstab entry.
Simon.
simoh's Profile:
simoh wrote:
OK. I'm just trying to remember how I solved this a couple of months
ago. Whatever the solution was didn't allow for auto-mounting after a
reboot, which is why I resorted to the fstab entry.
Simon.
I don't mind using fstab. That's how I'm now mounting the share via CIFS
-
Lestrad wrote:
Thanks. Here's the result:
[root@soa-wandboard /]# mount -v -t nfs4 -o nolock 192.168.0.14:/c/media
media/netdrive mount.nfs4: timeout set for
Wed Apr 1 15:08:17 2015
mount.nfs4: trying text-based options
On the RPI at least, the NFS mount survives a reboot without problems:
'[image: http://s23.postimg.org/slyvnysmf/soanfs1.jpg]'
(http://postimg.org/image/slyvnysmf/)
'[image: http://s29.postimg.org/l5shvx3xf/soanfs2.jpg]'
(http://postimg.org/image/l5shvx3xf/)
Code:
Krisbee wrote:
Without seeing both the NFS exports file and NFS config files on your
NAS, I'd be guessing. ( These are /etc/exports and
/etc/default/nfs-kernel-server on a default debian install for example,
what are they on your NAS).
I'll go into the NAS and get
Krisbee wrote:
Lestrad wrote:
While you're doing that, I did a bit of googling over at the arch linux
forums. This recent thread may be relevant:
https://bbs.archlinux.org/viewtopic.php?id=193834
The suggestion is to try this in the mount command:
Code:
Lestrad wrote:
Is that rpc-statd indispensable? Sorry to be so ignorant. I know a lot
about opera and '60s rock, but obviously not a lot about Linux files
systems and security services...
No apology needed, the whole point of the SOA webui is to isolate the
user from the need to know the
Lestrad wrote:
Krisbee wrote:
Without seeing both the NFS exports file and NFS config files on your
NAS, I'd be guessing. ( These are /etc/exports and
/etc/default/nfs-kernel-server on a default debian install for example,
what are they on your NAS).
39 matches
Mail list logo
