With the x86 DietPi image, you have the option to install and use Roon Server, from the optimized software menu.
This works just fine, and i use it with pleasure on my ASRock J-4105-ATX barebone.
However, on each update of the Roon software, the database is completely lost and i have to restore my backups to resume function. Can this, please, be fixed? Or can i do something about it to prevent it?
atb Mike
Hi,
many thanks for your report. Just one little question for my understanding: How do you update your Roon Server? What method you are using?
Roon contain its own update engine, so when a new release is made available, the Control unit pops up a notification. If one accepts this, the procedure is automatic and interventionless (normally).
So, when you connect to it after the update it is completely empty, with no settings, prefs or anything left of the media database.
Thanks for your quick response!
well the Roon Software itself is out of DietPi scope. It’s an own product. So if there is something wrong with Roon Update process, it might be better to contact Roon guys.
Thats not the case, the Roon update engine works flawlessly in all operating systems, MacOs, Win and Linux.
Whether you do a manual install or run the easy install scripts. Something differs in the DietPi install or the general behaviour of the distro.
And i’m really not in the mood for a discussion of who’s to blame… 
All i’m saying is, the “Optimized software” Roon Server in DietPi x86 is flawed, as it corrupts it’s database when the application performs maintenance. Which it is designed to do, regularly.
As I said, Roon software is downloaded directly from Roon side and put in place. There is nothing DietPi specific on this. Even DietPi is not changing anything on the Roon software. Means, as well the update function is done/provided by Roon software.
Download_Install 'https://download.roonlabs.com/builds/RoonServer_linuxx64.tar.bz2' $G_FP_DIETPI_USERDATA
mv $G_FP_DIETPI_USERDATA/RoonServer $G_FP_DIETPI_USERDATA/roonserver
Next to that DietPi is not an own operation system or destro. DietPi is a set on scripts on top of a normal Debian. As well a comparison between Win, Mac and Linux doesn’t really fit. These are totally different OS system, platforms. Even between Linux bases systems you will have quite some differences.
I have the same problem.
Indeed DietPi is based on Debian but there are some differences.
Roon server installation script is modified and Roon is installed in another directory than normal linux installation.
To be more specific, default Roon installation uses ‘opt’ as installation folder, and on DietPi Roon is installed under mnt/dietpi_userdata
Maybe this is a possible problem with Roon updates?
installation script is modified
Not sure what you mean by this. I had a look to the dietpi-software script and as far as I can see, the only thing done is to have software archive extracted to /mnt/dietpi_userdata. Doesn’t looks like there is any install script executed at all.
As well I had a look to the Roon Install Guide located at https://kb.roonlabs.com/LinuxInstall
There is no strong requirement for /opt/ directory as software location. Even it points to a possibility to customize $ROON_DATAROOT location. And this is done on the Roon Server service
/etc/systemd/system/roonserver.service
...
Environment=ROON_DATAROOT=$G_FP_DIETPI_USERDATA/roonserver
ExecStart=$G_FP_DIETPI_USERDATA/roonserver/start.sh
...
I think you are right, but I don’t know if the automated update process does not preserve the database.
Maybe it is something that we miss here.
that’s why it would be good to get in touch with Roon guys to understand what their update process is doing and what could be a reason for loosing the configs during update process.
Sure, we can ask the support-team to outline the update process.
I suspect this behaviour might have something to do with DietPi’s logging to ramdisk? I’m not sure what i’m talking about here, but DietPi made some change that would prevent corruption of the boot disk on sudden power loss. (Based on the lack of a power-button on most SBC’s) Either that or some file access issues…
This is what is written on Roon install guide for logs
If you’ve customized $ROON_DATAROOT, then they will be located in $ROON_DATAROOT/RoonServer/Logs and $ROON_DATAROOT/RAATServer/Logs
means they should be located at /mnt/dietpi_userdata/roonserver
I quickly installed a Roon server on one of my Demo VM’s and yes log file located there. Means on a physical device and not on a RamDisk
root@DietPiVM1:/mnt/dietpi_userdata/roonserver/RoonServer/Logs# ls -l
total 20
-rw-r--r-- 1 root root 19004 Apr 23 14:33 RoonServer_log.txt
root@DietPiVM1:/mnt/dietpi_userdata/roonserver/RoonServer/Logs#
root@DietPiVM1:/mnt/dietpi_userdata/roonserver/RoonServer/Logs# df -h .
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 9.8G 2.5G 6.9G 27% /
root@DietPiVM1:/mnt/dietpi_userdata/roonserver/RoonServer/Logs#
Are there any logs from update process that could be checked? At least to know what happen during update process.
Sorry, i had prepared myself to pull some logs from the update but i forgot to. And when i remembered my database was already gone/corrupted.
Does DietPi do anything else which is out of the ordinary concerning temporary data or user rights?
Personally, I don’t think there is something special. As far as I have seen, Roon server is executed as user root and I would not expect issues on file permissions. But you never know. Therefore I would be good to get an understanding on the Roon update process and to have some update logs. Hopefully we than see what happen and went wrong during update. My guess is, that the update is going to copy data from A to B. Maybe there is something overwritten or not copied correctly??
Well, as it happens a second service release was published a few minutes ago.
The appropriate log should be attached now.
I plucked it from the dietpi users “roonserver” library, after the download was completed and I was urged to reboot the Roon Server.
Then I rebooted and noted that the three directories that are named Roon* in this picture was erased, and then returned:
But i followed my standard procedure, logged in (registered the Core with my account online) and accepted that it’s database is completely empty.
I just go directly into Settings-Backup and them do a restore of my latest backup.
After the restore the Server requires one more reboot. This procedure does not take very long, about 45 minutes in total. (I had my backup drive already attached to the Server hardware)
Don’t know if this makes any more sense?
And, I haven’t got any feedback from the Roon crew with outlining the upgrade procedure.
RoonServer_log.txt.zip (678 KB)
ok I had a look into youlog file. It seems the full server log. Luckily the update procedure is at the end. This seems to be the procedure
04/23 21:07:36 Info: [base/updater] Installing update
04/23 21:07:44 Info: [stats] 4799mb Virtual, 2431mb Physical, 1096mb Managed, 0 Handles, 82 Threads
04/23 21:07:46 Trace: [base/Roon updater script stdout] Install package is at: /tmp/20192b42-9aca-4c94-9aad-43ae02cff536__RoonServer_linuxx64_100700537.tar.bz2
04/23 21:07:46 Trace: [base/Roon updater script stdout] Installing to: /mnt/dietpi_userdata/roonserver
04/23 21:07:46 Trace: [base/Roon updater script stdout] Removing any old update...
04/23 21:07:46 Trace: [base/Roon updater script stdout] Untarring new install to /mnt/dietpi_userdata/roonserver/.update.tmp
Looks like it’s going to remove the old installation and copy a new one in place. Maybe this is remove your config files as well if they are located in these directories that are removed by roon update process.
I have checked roon kb and found this, related to roon server database:
‘ Linux Core
If you used our “easy installer” scripts, then Roon’s database is located in /var/roon/RoonServer
If you ran Roon from the .tar.gz package by executing ./start.sh without configuring the ROON_DATAROOT environment variable, then it will be in $HOME/.RoonServer
If you have configured $ROON_DATAROOT manually, then it will be in $ROON_DATAROOT/RoonServer’
In roonserver service on DietPi, we have this:
’Environment=ROON_DATAROOT=/mnt/dietpi_userdata/roonserver’
So, I suppose the database is rewritten on every update because of that.
I think the Roon_Dataroot should not be modified, and the database let to be on var/roon
Well Roon themselves is offering to have it changed as part of their install guide. That’s why you have the variable $ROON_DATAROOT as documented on the room guide.
Indeed, they do offer this possibility, but it seems not to be the right solution in this case.
Even it is not explicitly specified, I think that the database shall not be put on the server install folder !
Maybe, changing the roonserver.service file and keeping the default location on var/roon/RoonServer for the database will solve the problem
If not, the best solution will be to manually install roonserver via unmodified easyinstall script.
Or, the install script on DietPi could be modified.
After some research, Roon developers suggested this:
“It sounds like the proper folders might not be persistent on the DietPi build. I would make sure that all of these folders are set as persistent and that the creators of the image haven’t set up a Deep Freeze kind of capability on the image.
This does appear to be a permissions issues and it appears that part of your Roon directories are getting wiped each time since they are not set as persistent. While I can’t comment on where exactly this behavior is happening, you should double check the Linux Install guide to try and find any directories which this will occur at or set your Linux machine to persist on all folders as this is exactly the kind of “Deep Freeze” behavior.”
Could someone check if this happening ?
Thank you !