INTERACT FORUM
More => Old Versions => JRiver Media Center 27 for Linux => Topic started by: Wheaten on December 31, 2020, 08:33:40 am
-
removed
-
Wheaton, I found this guide interesting.
The suggestion on the swap file was particularly helpful. I have a new RPi4 4Gb and changed the the line in /etc/dphys-swapfile to CONF_SWAPSIZE=512 from CONF_SWAPSIZE=100, and this significantly improved response time on my screen.
I didn't notice any change in performance with the change to the screen driver.
A suggestion you might want to remove the "$" from your Code: selects as these should not be there and obviously will return errors when pasted.
thanks
-
Thanks for the feedback.
I've added the bash prompt, to distinguish commands from text entering
-
I am having trouble with this. As I am very green in Linux and CLI that isn't a surprise. The problem arises with this, as I try to set up my RPi4/8GB with MC27:
After I safe the fstab and when I try to run the sudo mount -a, I get a "Parse error" for the line I inserted:
mount: etc/fstab: parse error at line 4 -- ignored
as far as I can tell, it is, apart from the changes I indicated, identical to the code in the instructions.
<full path to your library> /mnt/music cifs credentials=/home/pi/.credentials, nofail, vers=1.0, x-systemd.automount,file_mode=0777,dir_mode=0777,uid=1000,gid=1000 I put
smb://<IP-address>/volume1/music to replace <full path to your library>. I also changed uid and gid as they are different on my Synology NAS (I am assuming the IDs refer to the NAS and not the Pi but that may be wrong, too.)
EDIT: I would also prefer to mount the music folder as NTFS (I find that more stable and it works nicely on my iMac). Is that possible and do I just change the CIFS to NTFS and leave out the credential part? I have given the pi NTFS permissions for the music folder on the NAS.
Can someone, please, give me a hint as to how to fix this?
many thanks
Hans
-
For what it’s worth, I never was successful at mounting a network attached (actually router attached) storage device on my rpi. So as a solution I always opened the path manually from the Debian desktop on my Pi to the NAS, or from vnvserver. From there I could reach my music files. This worked fine unless there was a power failure in which case I had to re-establish the connection to the NAS.
What has worked much better was attaching my storage device directly to my Pi and mounting it via fstab. I also use systemd to auto open JRiver. So when I have a power failure everything restarts successfully.
-
For what it’s worth, I never was successful at mounting a network attached (actually router attached) storage device on my rpi. So as a solution I always opened the path manually from the Debian desktop on my Pi to the NAS, or from vnvserver. From there I could reach my music files. This worked fine unless there was a power failure in which case I had to re-establish the connection to the NAS.
What has worked much better was attaching my storage device directly to my Pi and mounting it via fstab. I also use systemd to auto open JRiver. So when I have a power failure everything restarts successfully.
Thank you erviv,
I am very new to the RPi and don't even know how to mount a drive on the Pi manually. I'll do some research on that. I am currently running MC27 in docker on my NAS and it's working fine. I'd like to keep my media files on the NAS and run MC on the Pi because I can get a HDMI output directly to my AVR which allows me to play multi channel tracks.
-
The path portion of the fstab should not contain a protocol (no smb: prefix), it should be in the form:
//<IP address of NAS>/<sharename>/<directory inside share if wanted>
The uid and gid should be the local uid and gid (on the pi), not the NAS's uid and gid. Those flags set the local user and group of the shares on the pi. That is to say if you want to mount the share so the "pi" user can access it, you'll want to use the uid of the pi user and the gid of a group the pi user is in. You can use names instead of numbers to make it easier, e.g. uid=pi,gid=audio etc.
EDIT addendum:
Some nice to have tips:
These days I would also suggest using a smb/cifs protocal version higher than 1.0 if your NAS supports it, as version 1.0 is deprecated and insecure and may not be supported by all samba server implementations anymore. I use 3.0 here, but your NAS software will determine which version is best.
-
The path portion of the fstab should not contain a protocol (no smb: prefix), it should be in the form:
//<IP address of NAS>/<sharename>/<directory inside share if wanted>
The uid and gid should be the local uid and gid (on the pi), not the NAS's uid and gid. Those flags set the local user and group of the shares on the pi. That is to say if you want to mount the share so the "pi" user can access it, you'll want to use the uid of the pi user and the gid of a group the pi user is in. You can use names instead of numbers to make it easier, e.g. uid=pi,gid=audio etc.
Thank you mwillems,
I tried many versions but always forgot the trailing":" after the IP address ('cause I didn't know).
<IP address>:/volume1/music /mnt/music nfs defaults 0 0
Thank you for your effort, it is highly appreciated
Hans
-
you don't need a trailing ":".
Are you able to mount the remote share via the shell?
you can replace "vers=1.0", by a higher version, depending on your NAS supported SMB version
sudo mount -t cifs -o rw,vers=1.0,credentials=/home/pi/.credentials //192.168.xxx.xxx/share /home/pi/Music
sudo mount -t cifs -o rw,vers=3.0,credentials=/home/pi/.credentials //192.168.xxx.xxx/share /home/pi/Music
-
Thank you Wheaten,
I have been able to mount the share but I will be changing the version as the Synology can do SMBv3, or, alternatively, I'll try to mount it as an NFS share, as I have good experience with that on my iMac. NFS seems to be more stable. On the iMac, SMB shares disappear for no reason occasionally and I need an automounter to keep them connected. With NFS shares that doesn't occur (as often, I should say).
-
Good to hear, will the mount also work on the /mnt/music folder?
sudo mount -t cifs -o rw,vers=3.0,credentials=/home/pi/.credentials //192.168.xxx.xxx/share /mnt/musicOr is the fstab working now?
-
Good to hear, will the mount also work on the /mnt/music folder?
sudo mount -t cifs -o rw,vers=3.0,credentials=/home/pi/.credentials //192.168.xxx.xxx/share /mnt/musicOr is the fstab working now?
I have this in fstab
<IP-address>:/volume1/music /mnt/music nfs defaults 0 0
and I mount with
sudo mount -a
but when I reboot the Pi I have to mount again
EDIT:
I have more questions, if I may:
- Is there a way to run the sudo mount -a automatically on reboot?
- Is there a way to make the screen resolution better? I use RealVNC server/client.
- Is the MC server running even when the MC interface is not running and if not, is there a way to get this done?
Many thanks
-
your missing "auto" or "automount"
-
your missing "auto" or "automount"
Thanks Wheaten, where would I need to put the "automount"?
-
<IP-address>:/volume1/music /mnt/music nfs defaults,auto 0 0or
<IP-address>:/volume1/music /mnt/music nfs defaults,x-systemd.automount 0 0
can't check this one
-
Thank you Wheaten,
I'll try this
-
I recommend including both noauto and the x-systemd.automount options rather than the auto option. The former options don't try to mount the share during boot, but instead automount the drive on demand at first user access. By contrast the "auto" option tries to automatically mount the share during the boot process which can delay the boot process or fail outright if the network isn't up in time for the mount. Mounting on demand is more robust IME. To be clear I haven't tested those options personally with nfs, but they should work, and with cifs they work a treat.
In re: samba/cifs if you want to use cifs but your share "goes away" periodically and gets "stuck" in a mounted or unmounted position, I feel your pain! I've also struggled with the issue. Linux sometimes doesn't recover gracefully when a network mount goes away while mounted. Here are my current cifs network share fstab options that I've refined over a few years to address the issue as a reference (you'll need to modify the share name, mount point, usernames, etc if you want to use them):
//192.168.xxx.xxx/sharename /local/mount/point cifs noauto,x-systemd.automount,x-systemd.idle-timeout=5min,_netdev,uid=user,gid=users,credentials=/home/user/samba-credentials,vers=3.0 0 0
This does three things: (1) doesn't mount during boot to avoid network readiness issues; (2) waits to mount until someone tries to access the mount (it takes less than half a second to mount so its pretty seamless) and (3) automatically unmounts the share after five minutes of idleness. This has the advantage that the share is only mounted when in use, which greatly reduces the likelihood that the share will "go away" while mounted and get stuck. From the user perspective, it's transparent: when you access the share it's just there, and I haven't had issues with the share getting stuck or being unavailable since I adopted these options.
-
Thank you mwillems, I appreciate your help. I am very new to this
-
Unfortunately, I am getting the "Parse Error" again with
//192.168.7.224/volume1/music /mnt/music nfs noauto,x-systemd.automount,x-systemd.idle-timeout=5min,_netdev,uid=1000, gid=1000 0 0
-
Unfortunately, I am getting the "Parse Error" again with
//192.168.7.224/volume1/music /mnt/music nfs noauto,x-systemd.automount,x-systemd.idle-timeout=5min,_netdev,uid=1000, gid=1000 0 0
There should be no spaces in any of the comma separated options. You've introduced a space between the uid and gid options which is giving you the error, I suspect. The fstab format has six elements separated by spaces and there should only be spaces between those different elements, i.e.
device mountpoint filesystemtype options,separated,by,commas,only dump pass
If you're curious, there's more detailed info here:
https://www.man7.org/linux/man-pages/man5/fstab.5.html
https://en.wikipedia.org/wiki/Fstab
or by typing man fstab on the command line
-
oh boy, thank you so much.
-
shouldn't this "//192.168.7.224/volume1/music" be "192.168.7.224:/volume1/music" when using NFS?
Or stick to mwillems example and replace NFS by cifs
-
shouldn't this "//192.168.7.224/volume1/music" be "192.168.7.224:/volume1/music" when using NFS?
Or stick to mwillems example and replace NFS by cifs
Thanks Wheaten, I went back to my original
192.168.7.224:/volume1/music /mnt/music nfs auto 0 0but
//192.168.7.224:/volume1/music /mnt/music nfs noauto,x-systemd.automount,x-systemd.idle-timeout=5min,_netdev,uid=1000,gid=1000 0 0works too
-
mwillems ; I tried using your suggestion for the /etc/fstab file and unfortunatley it locks up my system on boot. So I have had to go into emergency mode to allow me to comment out the line in /etc/fstab/
I don't see the error in the line however.
This is the line that works to manually mount my NAS.
sudo mount -t cifs -o rw,vers=1.0,credentials=/home/pi/.credentials //192.168.1.1/"all folders"/"MUSIC - router" /mnt/music
This is the line in /etc/fstab/, now commented out, that is causing the issues. (sorry I don't know how you post code lines in this forum).
I tried it with and without uid and gid to no avail. Adding nofail also didn’t prevent the lockout. I would have thought the problem would only occur when I tried to access the mount as it has noauto.
#//192.168.1.1/"all folders"/"MUSIC - router" /mnt/music cifs noauto,x-systemd.automount,x-systemd.idle-timeout=5min,_netdev,credentials=/home/pi/.credentials,uid=1000,gid=1000,vers=1.0 0 0
-
I don't think you're allowed to use quotes and spaces in a fstab line.
You should write it like (not tested):
//192.168.1.1/all\040folders/MUSIC\040-\040router /mnt/music cifs noauto,x-systemd.automount,x-systemd.idle-timeout=5min,_netdev,credentials=/home/pi/.credentials,uid=1000,gid=1000,vers=1.0 0 0
-
I don't think you're allowed to use quotes and spaces in a fstab line.
You should write it like (not tested):
//192.168.1.1/all\040folders/MUSIC\040-\040router /mnt/music cifs noauto,x-systemd.automount,x-systemd.idle-timeout=5min,_netdev,credentials=/home/pi/.credentials,uid=1000,gid=1000,vers=1.0 0 0
Yes, you can't use quotes or spaces in the fstab paths they need to be "escaped" as Wheaten shows.
If you have a choice, it's generally better to avoid using spaces in directory names or paths to begin with (e.g. by using underscores, or dashes, or camelCase instead), as there will be other situations on Linux where spaces in paths can create problems.
-
Thanks for the help. I had forgotten that I couldn't use quotes in /etc/fstab.
If I were setting things up again I would not use spaces in my Router share.
I will give this a shot.
Ok that clears things up. I have the auto version working. The noauto version hasn’t responded for me yet, but I will tinker more later. It’s not an issue. Ok the noauto sort of works, however when I boot up the files get mounted and they don’t unmount when the system is idled. I rebooted and the files again mounted. I ran umount to dismount the folder and tried to use JRiver to call the folder to open. It wouldn’t open. It said the files couldn’t be found. So I have gone back to the simpler auto line in fstab.
Either way it’s not an issue.
-
I am happy to report that on my Pi4B/8GB the JMark for MC27 is now better than on my Synology 1819+ (1662 vs. 1436). I have boosted clock frequency to 2GHz and voltage to 6 and given the app a priority of 5 in Task Manager. Using the Argon One Fan enclosure keeps the temperature at around 55C at load. It's now good enough for tag editing, with some patience.
-
I am happy to report that on my Pi4B/8GB the JMark for MC27 is now better than on my Synology 1819+ (1662 vs. 1436). I have boosted clock frequency to 2GHz and voltage to 6 and given the app a priority of 5 in Task Manager. Using the Argon One Fan enclosure keeps the temperature at around 55C at load. It's now good enough for tag editing, with some patience.
MC does it's own control of scheduling priorities. How does "given the app a priority of 5 in Task Manager" change things?
Also, is there a guide you can recommend on this overclocking/overvoltage/cooling options?
-
MC does it's own control of scheduling priorities. How does "given the app a priority of 5 in Task Manager" change things?
Also, is there a guide you can recommend on this overclocking/overvoltage/cooling options?
Bob, I don't know if the priority setting in task manager makes a difference. Being a complete noob for Linux I discovered this option by chance and thought it might help. I haven't measured its influence separately as I did all changes at the same time. Are you saying that system priority settings for MC can be changed within MC itself?
Regarding OC, I followed this:
https://www.tomshardware.com/reviews/raspberry-pi-4-b-overclocking,6188.html
I didn't go all the way to maximum and kept the clock at 2000. However, I haven't seen the temperature go above 55C, even at load, so going to 2147 may be an option still.
-
Bob, I don't know if the priority setting in task manager makes a difference. Being a complete noob for Linux I discovered this option by chance and thought it might help. I haven't measured its influence separately as I did all changes at the same time. Are you saying that system priority settings for MC can be changed within MC itself?
Regarding OC, I followed this:
https://www.tomshardware.com/reviews/raspberry-pi-4-b-overclocking,6188.html
I didn't go all the way to maximum and kept the clock at 2000. However, I haven't seen the temperature go above 55C, even at load, so going to 2147 may be an option still.
MC manages it's thread priorities via an entry in /etc/security/limits.d/mediacenter27.conf check out the comment in there.
MC fine tunes it's thread usage and will put low priority tasks at a background priority and playback for example at RT (real time) priority with a bunch of different types of threads in between those two.
-
Thanks Bob, that's good to know.
-
I have another issue that I'd like to find out about. I am connecting my RPi4 via HDMI to my Marantz SR7007 AVR. For some reason, I do not see the playing track info anymore (on the Marantz Display). I don't think I changed anything on the Marantz so I believe it's MC.
I did see it when I was playing from the Mac via HDMI. Does anyone know what I could try to get that working again?
many thanks
-
I have another issue that I'd like to find out about. I am connecting my RPi4 via HDMI to my Marantz SR7007 AVR. For some reason, I do not see the playing track info anymore (on the Marantz Display). I don't think I changed anything on the Marantz so I believe it's MC.
I did see it when I was playing from the Mac via HDMI. Does anyone know what I could try to get that working again?
many thanks
Are you certain you were playing to the Marantz from the Mac with HDMI and not DLNA?
I don't think there is a way that metadata is passed through HDMI.
-
Thanks Bob. I was actually doing both, DLNA and later HDMI from the iMac. I might not have noticed that the metadata was gone with HDMI before I switched to the RPi. That's a shame though that metadata can't be passed through HDMI.
-
For those wondering how to set the VNC screen resolution on your Raspberry Pi (I use a Pi4/8GB) to one fitting your monitor here is what I did to get the default 2560x1440 (60Hz) resolution for my iMac 5K (late 2015). This makes it much easier for me to see my MC27 views properly.
Disclaimer: I am very new to Linux and Raspberry so no guarantees, your milage may vary. My system is Raspberry Pi4B/8GB: Linux RPi4 5.10.17-v8+ #1403
1) open a terminal on the RPi/VNC session
2) The following commands will show the current display and resolution, the right parameters for a display mode supporting 2560x1440, create that mode and add the mode to the existing modes
xrandr# This will show the current display name (start of second line) and the current resolution (amongst other things)
cvt 2560 1440 60# this reveals the necessary parameters to create a new mode
xrandr --newmode "2560x1440_60.00" 173.00 1920 2048 2248 2576 1080 1088 1120 -HSync +VSync# this creates the new display mode. Replace everything starting with the opening quote mark (") with what you see in the output after the cvt command
xrandr --addmode HDMI-1 2560x1440_60.00# this adds the new mode to the existing modes. Replace 'HDMI-1' with what you see after the xrandr command as the display name
xrandr --output HDMI-1 --mode 2560x1440_60.00# this activates the new mode and changes the resolution to 2560X1440
If you run into permission issues use sudo in front of the commands.
The following should make these changes persistent upon every reboot:
1) Create (if not existing) a file in ~ named .bash_profile
cd ~sudo nano .bash_profile
2) Copy the three xrandr commands from above into the file and save it (<ctrl>o) and exit (<ctrl>x)
Disclaimer: I haven't tested the persistence yet
Sources:
https://unix.stackexchange.com/questions/274506/how-to-set-persistent-resolution-in-xfce-on-debian
https://www.raspberrypi.org/forums/viewtopic.php?t=201245
EDIT: changed incorrect cvt command to xrandr command
-
Stupid question. Do I have to start from scratch with a USB boot or can I save my MC 27 setup ?
If I update my SD card .... can I have a USB SSD raspberry Pi by doing this:
Use SD COPY and copy the SD Card to the USB SSD drive
Change the Boot drive to the USB using Sudo raspi-config
shut down and remove the SD Card.
-
- You need to enable boot from USB in raspi-config
- Then you can copy the complete content of the SD to a USB drive, as shown in the screenshots
- shutdown the rPi
- Remove the SD
- Boot the rPi
It should boot form the USB disk, and no settings etc lost.
So the short answer to your question..... No and Yes
-
That's exactly what I was asking.....I was afraid I needed to burn a fresh image on the SSD and start from scratch.
Thank you thank you.
I'll get right on it.
PS: I have a Sandisk SSD that had recognition problems from my 2020 iMac and after 6 months of Apple troubleshooting - I gave up and tried a Samsung SSD - which worked fine. Now I have two Sandisk 1 TBs to do something with. They work fine in the Raspi and even my Apple laptop. So why not boot from the USB with a fast SSD drive??
-
Well you have 2 advantages, booting form a SSD on USB 3.0
- Speed improvements
- Stability
A big problem when using a SD card as OS-disk, is that there is no monitoring if the SD cards is being accessed or written to. If in these case the power get interrupted or a user performs a reboot, the state of the files become unknown, as the dirty flag is set. The Pi won't boot from it as it has no idea what happened to the file.
-
Well you have 2 advantages, booting form a SSD on USB 3.0
- Speed improvements
- Stability
A big problem when using a SD card as OS-disk, is that there is no monitoring if the SD cards is being accessed or written to. If in these case the power get interrupted or a user performs a reboot, the state of the files become unknown, as the dirty flag is set. The Pi won't boot from it as it has no idea what happened to the file.
I was aware of that SD problem and I did frequent backups. So...that isn't an issue with a USB SSD dive? I was wondering how I'm going to back up the 1TB
-
- You need to enable boot from USB in raspi-config
- Then you can copy the complete content of the SD to a USB drive, as shown in the screenshots
- shutdown the rPi
- Remove the SD
- Boot the rPi
It should boot form the USB disk, and no settings etc lost.
So the short answer to your question..... No and Yes
It didn't work. I had the following after the rpi-update command
WARNING: This update bumps to rpi-5.10.y linux tree
See: https://www.raspberrypi.org/forums/viewtopic.php?f=29&t=288234
'rpi-update' should only be used if there is a specific
reason to do so - for example, a request by a Raspberry Pi
engineer or if you want to help the testing effort
and are comfortable with restoring if there are regressions.
DO NOT use 'rpi-update' as part of a regular update process.
##############################################################
Would you like to proceed? (y/N)
pi@pi:~ $ y
bash: y: command not found
And after I copied the working SD image to the SSD, and rebooted, I got an error that the Raspi OS software is not the latest .
It didn't boot.
I tried imaging the SSD with the latest from the Raspi web sight and after removing the SD card -- it worked. It booted just fine from USB - but it was a new OS.
My SD card OS is somehow lacking.
I checked the eeprom and it is the latest.
-
you did run
sudo rpi-update
prior to copying?
-
Yes...I was up to date,
I'm guessing there was insufficient SD card memory?
I've since given up and started with a fresh install on the SSD. So far I am having troubles with the JRiver install.
-
Please elaborate, so i can give you support.
What errors of trouble do you encounter?
-
Please elaborate, so i can give you support.
What errors of trouble do you encounter?
My current Raspi has MC 27 working perfectly. I use the VNC viewer that comes with the Raspi and it also works perfectly.
When I tried to update my SD card, after I copied it and booted with the card removed, I got an error that the USB boot device software needed an update and it gave me the link for the raspberry pi downloads. One of the help sites at raspberry cautioned about no warnings if the memory is insufficient ( https://www.raspberrypi.org/documentation/raspbian/updating.md ) and I thought I may not have enough room - especially with Wolfram Mathematica.
However, if I take the SSD and use Rasperries Mac software to load it with the latest operating system and I reboot....the SSD boots without a hitch.
Since the only thing I use the Raspi for is JRiver, I decided it might be less hassle to just load MC 27 again onto this fresh OS.
I installed VNC again and worked through the above steps - skipping over the X11 VNC --- but I had a typo on the public key and now I get an error as follows
--------------------
Hit:2 http://raspbian.raspberrypi.org/raspbian buster InRelease
Get:3 http://dist.jriver.com/latest/mediacenter buster InRelease [3,612 B]
Err:3 http://dist.jriver.com/latest/mediacenter buster InRelease
The following signatures couldn't be verified because the public key is not available: NO_PUBKEY C30B25C6077765D5
Reading package lists... Done
W: GPG error: http://dist.jriver.com/latest/mediacenter buster InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY C30B25C6077765D5
E: The repository 'http://dist.jriver.com/latest/mediacenter buster InRelease' is not signed.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.
pi@raspberrypi:~ $ sudo apt-get install mediacenter27
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Unable to locate package mediacenter27
pi@raspberrypi:~ $
---------
I am thinking of wiping it and starting over again......unless you can see an easy fix
-
Easy fix. There was a typo in the instruction. A "-" was added behind the "add". Code below is the correct one,
wget -q "http://dist.jriver.com/mediacenter@jriver.com.gpg.key" -O- | sudo apt-key add
-
Easy fix. There was a typo in the instruction. A "-" was added behind the "add". Code below is the correct one,)
wget -q "http://dist.jriver.com/mediacenter@jriver.com.gpg.key" -O- | sudo apt-key add
That did it...thanks (I kept staring at that line)
Update: - I also increased the swap to 1024.....there's still a little lag.....I need to boot with the SD card to compare....I forget what it was like
-
Hello. I'm still having some troubles. Currently running MC 26 on Raspberry Pi 4 (one generation behind on everything, I guess). Anyway, I followed the instructions above on a new install, except that I just use RealVNC's vnc connect from a Windows 7 desktop, since that is what is packaged with Raspberry Pi OS. Everything runs OK if I have a hardware monitor, mouse and keyboard physically attached to the pi. But when I try to run headless, JRiver MC doesn't launch. So that's detach all hardware, wlan connect to local network, reboot, PuTTY connect to Pi via SSH from Win 7 remote desktop, run vncserver, then connect to Pi through vnc connect. I can see the desktop and run the native apps, but MC doesn't launch. Any suggestions?
Thanks!
-
Hmmm...I also use the VNC....but with a Mac. I have my keyboard and mouse unplugged and it boots OK.
I can't remember doing anything in setup for that. I'm also booting from a USB drive.
Do you have the latest Raspi OS?
-
I did write this for a reason:
• Now we need to open a VNC session to the rPi. Don’t use Microsoft RDP as RDP can’t connect to a console session on Linux. We’ve already installed the VNC server, so we need a VNC Viewer, like “ultraVNC” (windows), or the built in VNC viewer on the MAC “Screen Sharing”.
JRiver did start up and is running, but you can't connect via windows RDP to the started console session on Linux. You need a VNC viewer for this.
RDP will create a new session. In this session MC didn't start, as this session did not boot the Pi. And JRiver started during the boot in the first session.
-
It just dawned on me.....I have a wireless keyboard and mouse and a dongle is always plugged into the USB A port...so I in effect have a keyboard/mouse
-
you have a MAC, Unix based. So it will logon to the console session (first user). this session was the booting one and started MC.
-
I have updated to the latest raspberry pi OS.
-
The VNC viewer I was trying to use on my Win 7 desktop is VNC connect, made by RealVNC. I chose it because RealVNC provides the server software included with official Raspberry Pi OS.
No luck yet.
-
I use the same...VNC Connect.....
-
The VNC viewer I was trying to use on my Win 7 desktop is VNC connect, made by RealVNC. I chose it because RealVNC provides the server software included with official Raspberry Pi OS.
No luck yet.
Don't know what is going wrong. I can't reproduce it. Using the VNC server from the raspbian image works without any issues. Using it headless.
Maybe some other users have an idea
-
OK, I finally noodled this out. I have two inputs to my desktop monitor, so when I set up the pi, I can go back and forth between the console session with hardwire to monitor, keyboard and mouse, and the remote session from my Windows desktop. I could see that when connecting via VNC, the remote session was not identical to the console session I see when on the hardwire connection. So, what I think was happening was that when I first booted the pi, the pi would boot to desktop and auto log on pi as the user. When I then connected via SSH and ran vncserver, a second session would start, that was not the console session, and that was the conflict. I briefly attempted to have the pi boot to cli instead of desktop, but when that didn't immediately work, I set it back to boot to desktop. Instead of connecting via SSH and running vncserver for another session, I instead went directly to my VNC viewer and connected without the :1 at the end of the network address. Voila! it worked. I connected to the console session, now have JRiver auto launch at boot, and I can see and control JRiver.
-
Good to hear.
Guess the ":1" you found on internet, as this is not a default setting by VNC viewer?
-
When you connect to the pi remotely via SSH, and then run vncserver from the command line, the vnc server returns the address to use to connect to the session. The :1 was included in the address I was was getting from the server. Not sure exactly where I got it from, since I read through a number of threads to try to solve the problem.
-
if you need to re-install sometime, just activate VNC server via raspi-config. There is no need to start it from a SSH session. Guess that's why the VNC server opts for the :1, as user pi is already connected through SSH. the ":1" indicates a screen number.
-
I have the Raspi booting from an SSD just fine but I just changed the external USB drive with the music files from a hard drive to an SSD drive and copied the music files from my Mac to the SSD.
Previously the external hard drive worked OK with Raspi. Now, the SSD is read only and as a newcomer to Linux, changing read/write permissions on the drive seems more complicated than I think it should be.
Is there an easy fix for this?
-
You should never have copied the files with a MAC, without taking care of owner and rights.
As I have no clue, how you did the copy or even which file system you used, it's an educated guess for me.
I should start with, having the user pi take ownership:
sudo chown pi:pi -R <path to mount>
Next some trial and error, validate by each step if you have R/W access.
sudo chmod -R 744 <path to mount>When fail:
sudo chmod -R 774 <path to mount>When fail:
sudo chmod -R 777 <path to mount>
I'll hope this will work, but I would advise to partition the disk on the Pi box and perform the copy on this box.
As it might be that the UNIX and LINUX rights will give you all kind of conflicts.
-
Thanks
Since I just started this, I can start over.
I have a 500GB and two 1TB SSD drive....currently using for Linux (500GB) and MC 27 (1TB) music
So I believe you are suggesting taking the blank 1TB and formatting it with Linux and then copying the files from the Mac formatted drive?
I do Tag editing on the Mac and would like to - from time to time - sync the Raspi disk with the Mac disk - so the Mac will need to read/write to the Raspi drive.
Or I suppose I could keep the above blank drive as a Mac drive and then sync it with the Raspi using SD Copy ??
-
Your music is on the USB thingy?
So connect that thing to the rPi, take the empty 1TB drive. As you indicate you want to connect the 1TB to both MAC and rPi, then only FAT32 is compatible. Not exFAT as this will not allow dynamic links. (you can also go for NTFS, but then you need to load additional drivers on your MAC.)
Only issue for FAT32 is the max file size of 4GB, but with music you won't reach this boundary.
You can also share the rPi 1TB disk, with your MAC via a network share.
If you TAG via JRiver, you can set the rPi as main library and have the MAC use this library. Then you can TAG on the MAC, the files from the rPi.
To sync on the MAC, you have Rsync or use filezilla
-
OK...got it to work. Thanks for your help
I first tried FAT32 but kept getting file size errors as you suspected. I then tried Windows NTFS and it worked. There were no read/write errors and I had access with both the RASPI and MAC.
Now I am going to try your suggestions for TAG edit syncing. I'm a little fuzzy on that.
-
Hi people
Been giving this a try and all went well, until I moved the RPi to another room and rebooted with no monitor.
Now I can't connect with VNC. It looks like the x11vnc command in the boot script may be failing as I connected with putty and tried it manually.
XOpenDisplay failed (:0)
I've googled a bit, tried a few things, but no luck. Help appreciated.
Edit: OK managed to sort, I went into raspi-config and forced the display resolution to 1920x1020. Rebooted and now VNC connects.
-
Interesting. Thanks for the tip.
I wonder why forcing the moinitor resolution worked?
-
I've chosen a different VNC server in this tutorial. If you are going deviate from it, you should know that x11 doesn't know what resolution it need to display. So you need to let the pi know.