PDA

View Full Version : Building LMS for 64-bit Debian running on ARM Single Board Computers



dsdreamer
2017-10-21, 10:31
1) Motivation: I don't want to run a power-hungry PC 24/7 with spinning fans etc, but I want something faster the a Raspberry Pi to run LMS (I still use the web interface). There are number of fast, cheap SBC's out there that handily out-perform the RPi3, such as OdroidC2 (which supports an eMMC module for storage), ROCK64 (which has USB3 and eMMC). Quad-Core ARM Cortex A53 64-Bit Processors and support for 2GB or 4GB of 1600MHz LPDDR3 memory, endow these tiny machines with similar power to the x86 PCs many of us used as LMS servers back in the day.

2) Issue: ARM64/AARCH64 architectures are not currently supported in the highly build Debian packages as of now. It seems you have to roll your own.

3) My solution: Build Debian install packages using the method and scripts supplied here: https://github.com/Uplink03/logitechmediaserver-deb. This, in turn, pulls together the source repositories from https://github.com/Logitech/slimserver-vendor.git, https://github.com/Logitech/slimserver.git and https://github.com/Logitech/slimserver-platforms.git. After checking out the repo


git clone --recursive -b public/7.9 https://github.com/Uplink03/logitechmediaserver-deb.git
I wanted to make sure I was using fully updated sources, so I did the following (probably not the right way to do it, but it worked for me).


cd logitechmediaserver-deb/source/vendor
git pull https://github.com/Logitech/slimserver-vendor.git
cd ../server
git pull https://github.com/Logitech/slimserver.git
cd ../platforms/
git pull https://github.com/Logitech/slimserver-platforms.git

Now the only problem I has was that those CPAN libraries that use automake/configure generally fail to complete the ./configure script on 64-bit ARM machines. To fix this, I modified ./logitechmediaserver-deb/source/vendor/CPAN/buildme.sh to copy the platform's config.guess file into each of the unarchived source directories, immediately before running ./configure. A suitable patch for doing this is attached, but you might have to edit the path to config.guess to suit your installation,(dpkg -L automake | grep guess) will tell what it should be. In my case, it was /usr/share/automake-1.15/config.guess. This simple trick is enough to allow ./logitechmediaserver-deb/source/vendor/CPAN/buildme.sh to run to completion without further issues.

Then, it is sufficient to the following command in ./logitechmediaserver-deb


dpkg-buildpackage -rfakeroot -b -us -uc


This should leave you with the following files, ready to install with dpkg -i


rw-r--r-- 1 charles charles 4476976 Oct 20 21:16 logitechmediaserver_7.9.0+lmce1_all.deb
-rw-r--r-- 1 charles charles 2549430 Oct 20 21:16 logitechmediaserver-code2000-font_7.9.0+lmce1_all.deb
-rw-r--r-- 1 charles charles 4908774 Oct 20 21:16 logitechmediaserver-cpan-bundle_7.9.0+lmce1_arm64.deb
-rw-r--r-- 1 charles charles 1745448 Oct 20 21:15 logitechmediaserver-firmware_7.9.0+lmce1_all.deb
-rw-r--r-- 1 charles charles 3396910 Oct 20 21:16 logitechmediaserver-html_7.9.0+lmce1_all.deb


This is a reasonably easy route to follow, the only trickery being the need to patch CPAN/buildme.sh to work around automake's config.guess being so old in many packages. Can anyone suggest a more elegant way to solve this, that we could perhaps get merged into the official logitech repo version of buildme.sh?

Roland0
2017-10-21, 14:34
This is a reasonably easy route to follow, the only trickery being the need to patch CPAN/buildme.sh to work around automake's config.guess being so old in many packages. Can anyone suggest a more elegant way to solve this, that we could perhaps get merged into the official logitech repo version of buildme.sh?

See this github issue (https://github.com/Logitech/slimserver-vendor/issues/9) for discussion.
See this post (http://forums.slimdevices.com/showthread.php?107222-Howto-build-LMS-for-aarch64) for a slightly more elegant modification for the the build script (as is fetches the newest config.guess automatically and doesn't depend on a local copy), plus a update to build the newest versions of the libraries / perl modules (a LMS built this way has been running on my 64bit RPi3 for a couple of months without any issue).

atrocity
2017-10-21, 15:02
Is there a guide out there for dummies who are comfortable with the command line and have git installed on an Odroid C2 but have never tried to do something like this from scratch? Or is the first post in this thread all I need?

dsdreamer
2017-10-21, 18:31
Is there a guide out there for dummies who are comfortable with the command line and have git installed on an Odroid C2 but have never tried to do something like this from scratch? Or is the first post in this thread all I need?

I can try to post more detailed steps, and/or provide feedback in this thread if you get stuck. I did this on an odroidc2, as well. Are you running Jessie or Stretch and which system Perl is installed? (Also, is this armbian or dietpi or some other variant?)

A few things I neglected to mention in the first post were:


sudo apt-get install fakeroot
sudo apt-get install yasm
sudo apt-get install debhelper quilt libz-dev libgd-dev
sudo apt-get install libmodule-build-perl
sudo apt-get install libmodule-install-perl
sudo apt-get install libio-socket-ssl-perl

uname -a; perl -v, on my machine shows the following:


Linux music2 4.13.7-odroidc2 #32 SMP PREEMPT Mon Oct 16 21:38:07 CEST 2017 aarch64 GNU/Linux
This is perl 5, version 24, subversion 1 (v5.24.1) built for aarch64-linux-gnu-thread-multi
(with 75 registered patches, see perl -V for more detail)


I will try to do better write-up in the next 24 hours, but to make it better targeted to your system please let me know which OS (cat /etc/os-release) and which perl (perl -v) you are starting with.

Thanks.

atrocity
2017-10-21, 18:49
I can try to post more detailed steps, and/or provide feedback in this thread if you get stuck. I did this on an odroidc2, as well. Are you running Jessie or Stretch and which system Perl is installed? (Also, is this armbian or dietpi or some other variant?)

A few things I neglected to mention in the first post were:


sudo apt-get install fakeroot
sudo apt-get install yasm
sudo apt-get install debhelper quilt libz-dev libgd-dev
sudo apt-get install libmodule-build-perl
sudo apt-get install libmodule-install-perl
sudo apt-get install libio-socket-ssl-perl

uname -a; perl -v, on my machine shows the following:


Linux music2 4.13.7-odroidc2 #32 SMP PREEMPT Mon Oct 16 21:38:07 CEST 2017 aarch64 GNU/Linux
This is perl 5, version 24, subversion 1 (v5.24.1) built for aarch64-linux-gnu-thread-multi
(with 75 registered patches, see perl -V for more detail)


I will try to do better write-up in the next 24 hours, but to make it better targeted to your system please let me know which OS (cat /etc/os-release) and which perl (perl -v) you are starting with.

Thanks.

Thank you! There's definitely no hurry, though. I don't strictly need another server, it's just fun to play around with this stuff. I got as far as running git apply --check on the patch and wound up with:



error: slimserver-vendor-patched/CPAN/buildme.sh: No such file or directory
error: slimserver-vendor-patched/flac/buildme-linux.sh: No such file or directory
error: slimserver-vendor-patched/sox/buildme-linux.sh: No such file or directory


I had not yet installed the additional packages (fakeroot, yasm, etc.), but now that I have I still see the same error.

This is an Odroid C2.

Result of cat /etc/os-release is:



NAME="Ubuntu"
VERSION="16.04.3 LTS (Xenial Xerus)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 16.04.3 LTS"
VERSION_ID="16.04"
HOME_URL="http://www.ubuntu.com/"
SUPPORT_URL="http://help.ubuntu.com/"
BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/"
VERSION_CODENAME=xenial
UBUNTU_CODENAME=xenial


Result of perl -v is:



This is perl 5, version 22, subversion 1 (v5.22.1) built for aarch64-linux-gnu-thread-multi
(with 58 registered patches, see perl -V for more detail)


Result of uname -a is:



Linux odroid64.wywh.com 3.14.79-108 #1 SMP PREEMPT Mon Feb 27 23:18:26 BRT 2017 aarch64 aarch64 aarch64 GNU/Linux


Thank you again!

dsdreamer
2017-10-21, 18:54
See this github issue (https://github.com/Logitech/slimserver-vendor/issues/9) for discussion.
See this post (http://forums.slimdevices.com/showthread.php?107222-Howto-build-LMS-for-aarch64) for a slightly more elegant modification for the the build script (as is fetches the newest config.guess automatically and doesn't depend on a local copy), plus a update to build the newest versions of the libraries / perl modules (a LMS built this way has been running on my 64bit RPi3 for a couple of months without any issue).
Okay, good to know this has been tackled by others before me. I see the patched buildme.sh updates the troublesome, outdated packages to overcome the staleness of the config.guess. My thought was not to stray further from the beaten path than necessary, so using the same (outdated) source code as the official Logitech build scripts seemed a better idea to me, but that's arguable both ways.

I have experimented with actually running automake again instead of just copying in a newer config.guess, e.g., invoke automake -a -f, in all those places where outdated packages won't build. I'm not sure if that's better or worse, but it does work.
We could have the following inserted at all the critical places in buildme.sh


if [ "`uname -m`" == "aarch64" ]; then
automake -a -f
fi

or


if [ "`uname -m`" == "aarch64" ]; then
cp `dpkg -L automake | grep 'config.guess'` .
fi


Either of these would be non-destructive to normal users of buildme.sh.

dsdreamer
2017-10-21, 19:09
Thank you! There's definitely no hurry, though. I don't strictly need another server, it's just fun to play around with this stuff. I got as far as running git apply --check on the patch and wound up with:



error: slimserver-vendor-patched/CPAN/buildme.sh: No such file or directory
error: slimserver-vendor-patched/flac/buildme-linux.sh: No such file or directory
error: slimserver-vendor-patched/sox/buildme-linux.sh: No such file or directory

Thank you again!

1) Make sure that /sbin is in your PATH. I needed to edit my ~/.profile to include PATH=$PATH:/sbin:/usr/sbin

2) When applying the patch, do so as follows:


cd ./logitechmediaserver-deb/source/vendor
patch -p2 < ~/slimserver-vendor.patch

atrocity
2017-10-22, 05:52
1) Make sure that /sbin is in your PATH. I needed to edit my ~/.profile to include PATH=$PATH:/sbin:/usr/sbin

2) When applying the patch, do so as follows:


cd ./logitechmediaserver-deb/source/vendor
patch -p2 < ~/slimserver-vendor.patch


Your hints were perfect. I started the process last night and found it had finished when I woke up this morning. I installed everything via sudo dpkg -i with the only snag being that LMS complained about the CPAN package not being installed. So I installed it along with the two others, then re-installed LMS, which is now cheerfully scanning my 100,000+ tracks.

THANK YOU!

dsdreamer
2017-10-22, 08:19
Your hints were perfect. I started the process last night and found it had finished when I woke up this morning. I installed everything via sudo dpkg -i with the only snag being that LMS complained about the CPAN package not being installed. So I installed it along with the two others, then re-installed LMS, which is now cheerfully scanning my 100,000+ tracks.

THANK YOU!
You're welcome!

Just so that this thread can be more useful to any others who want to follow this method, I retraced my steps from a new install of Ubuntu 16.04.3 LTS on an odroidc2 to LMS installed and running. Here they are:


sudo apt-get update
sudo apt-get upgrade
sudo apt-get install fakeroot
sudo apt-get install yasm
sudo apt-get install debhelper quilt libz-dev libgd-dev
sudo apt-get install libmodule-build-perl
sudo apt-get install libio-socket-ssl-perl
sudo apt-get install libmodule-install-perl
git clone --recursive -b public/7.9 https://github.com/Uplink03/logitechmediaserver-deb.git
cd logitechmediaserver-deb/source/vendor/
git pull https://github.com/Logitech/slimserver-vendor.git
cd ../server/
git pull https://github.com/Logitech/slimserver.git
cd ../platforms/
git pull https://github.com/Logitech/slimserver-platforms.git
cd ../vendor/
wget http://forums.slimdevices.com/attachment.php?attachmentid=23873&d=1508605856 slimserver-vendor.patch
mv attachment.php\?attachmentid\=23873 slimserver-vendor.patch
patch -p2 < slimserver-vendor.patch
rm slimserver-vendor.patch
cd ../..
dpkg-buildpackage -rfakeroot -b -us -uc
cd
ls -l *.deb
sudo dpkg -i logi*.deb
sudo /etc/init.d/logitechmediaserver start
systemctl status logitechmediaserver.service

However, you may want the specially-patched versions of the helper binaries for flac, sox and faad as well.


cd ./logitechmediaserver-deb/source/vendor/flac/
./buildme-linux.sh
tar xvf flac-build-aarch64-.tgz --strip-components=7
sudo cp ./bin/flac /usr/share/squeezeboxserver/Bin
cd ../sox
./buildme-linux.sh
tar xvf sox-build-aarch64-.tgz --strip-components=7
sudo cp ./bin/sox /usr/share/squeezeboxserver/Bin/
cd ../alac_decoder
make
sudo cp ./alac /usr/share/squeezeboxserver/Bin/
cd ../faad2
git clone https://github.com/ralph-irving/faad2.git
cd faad2/
cp `dpkg -L automake | grep guess` .
./configure
make
cd frontend/
sudo cp ./faad /usr/share/squeezeboxserver/Bin/
cd ../../../wavpack
sed -i '/cd wavpack-4.50.1/a cp `dpkg -L automake | grep guess` .' build.sh
./build.sh
sudo cp ./wvunpack /usr/share/squeezeboxserver/Bin/


Hopefully this helps someone.

Charles.

mherger
2017-10-22, 08:55
Thanks for these notes! At some point I might get around to finally
build support for this platform...

But may I ask why you go all the way as to build a .deb file? Why not
just run from the source?

--

Michael

atrocity
2017-10-22, 09:21
You're welcome!

Just so that this thread can be more useful to any others who want to follow this method, I retraced my steps from a new install of Ubuntu 16.04.3 LTS on an odroidc2 to LMS installed and running. Here they are:

Great stuff, thanks so much! A couple things, though:

1. Am I mis-remembering, or does git also have to be explicitly installed?

2. When I attempted to put the steps for the helper binaries into a script, the wavpack step failed. I believe the initial cd step should just be
cd ../wavpack.

Would running the entire process from the top be the correct way to update to the latest nightly?

Also curious if the same steps would work on a C2 running Debian. It's not my computer and not in my house, so I don't know the exact OS details and understand if there's no way you can answer that. Just wondering if I could script all this stuff and send it to a friend.

Thank you again for doing this! I was a programmer for decades but my specialty was SAS and JCL on the mainframe. So I find myself in the annoying position of having a head full of lots computer/programming knowledge with almost none of it being relevant here.

atrocity
2017-10-22, 09:24
Also curious if the same steps would work on a C2 running Debian. It's not my computer and not in my house, so I don't know the exact OS details and understand if there's no way you can answer that. Just wondering if I could script all this stuff and send it to a friend.

Come to think of it, after reading Mr. Herger's comments, I wonder if I could just supply the .deb files.

Roland0
2017-10-22, 10:11
Okay, good to know this has been tackled by others before me. I see the patched buildme.sh updates the troublesome, outdated packages to overcome the staleness of the config.guess.

It's a mix of both - some packages do not support aarch64, even in their newest version. For those, config.guess is updated.



I have experimented with actually running automake again instead of just copying in a newer config.guess, e.g., invoke automake -a -f, in all those places where outdated packages won't build. I'm not sure if that's better or worse, but it does work.
We could have the following inserted at all the critical places in buildme.sh


if [ "`uname -m`" == "aarch64" ]; then
automake -a -f
fi

or


if [ "`uname -m`" == "aarch64" ]; then
cp `dpkg -L automake | grep 'config.guess'` .
fi



ad 1: automake doesn't seem to be fully downwards compatible, so there is a risk that it will fail (on my gentoo system, there are 3 versions of automake installed for that reason...)
ad 2: will only work on debian-based linux variants

dsdreamer
2017-10-22, 20:26
It's a mix of both - some packages do not support aarch64, even in their newest version. For those, config.guess is updated.



ad 1: automake doesn't seem to be fully downwards compatible, so there is a risk that it will fail (on my gentoo system, there are 3 versions of automake installed for that reason...)
ad 2: will only work on debian-based linux variants

Agreed, it is not a good idea to do something that is Debian-specific, so that was why I was not totally happy and asked for a more elegant solution. What I really meant was a more robust solution. Another way to copy in the latest, known config.guess file without risking a broken automake would be to use: wget -O config.guess 'http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD' or curl 'http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD' > config.guess
The only assumptions used here a working wget (or curl) and an Internet connection. These extra build steps would be protected by an if [ "`uname -m`" == "aarch64" ]; then conditional, so the probability of breaking the script for existing platforms for which it works would be minimal.

Any thoughts on why the above is not a good change to propose?

Charles.

dsdreamer
2017-10-22, 21:52
Great stuff, thanks so much! A couple things, though:

1. Am I mis-remembering, or does git also have to be explicitly installed?

On the armbian version of Ubuntu I picked up to try this, it was already installed.


2. When I attempted to put the steps for the helper binaries into a script, the wavpack step failed. I believe the initial cd step should just be
cd ../wavpack

Looking at this again, I find an extra pair of dots would be necessary, since you should be in ./vendor/faad2/faad2/frontend at that point. I should have written "cd ../../../wavpack/"


Would running the entire process from the top be the correct way to update to the latest nightly?

If you have already run this once, and can keep the build directories in-tact (i.e., you have room for them), then updating to the latest nightly should start with the "git pull" commands and go from there.


Also curious if the same steps would work on a C2 running Debian. It's not my computer and not in my house, so I don't know the exact OS details and understand if there's no way you can answer that. Just wondering if I could script all this stuff and send it to a friend.

I had previously developed this process on Debian Stretch, (armbian). I have successfully used it on Debian Jessie too. I only tried it on Ubuntu so I could give you meaningful guidance.


Thank you again for doing this! I was a programmer for decades but my specialty was SAS and JCL on the mainframe. So I find myself in the annoying position of having a head full of lots computer/programming knowledge with almost none of it being relevant here.
I was glad to share it, and happy it worked for you.

dsdreamer
2017-10-22, 22:09
But may I ask why you go all the way as to build a .deb file? Why not
just run from the source?

--

Michael
Ah, good question.The automation of the Debian package installer is helpful in that it automatically creates /etc/init.d/ scripts, creates the user squeezeboxserver, changes ownership of files so that they can run under that user, and provides proper daemon monitoring (and restarting behavior, if it ever crashes). I've done all this by hand before on different machines, but I like the automation and system accounting that Debian packages always provide.

I guess I've become used to the convenience of easily installing and updating Debian packages, and wanted to maintain that convenience, even if I couldn't use your nightly builds anymore due to lack of direct aarch64 support.

Charles.

mherger
2017-10-22, 23:57
> I've done all this by hand
> before on different machines, but I like the automation and system
> accounting that Debian packages always provide.

Ah, the "on different machines" part makes sense. For a single machine
it wouldn't imho. Yes, I had to manually configure things and set up the
startup script on my server. But updates now only take me a few seconds
to "git pull" and restart :-).

But assuming we had binaries for your platform, would the regular .deb
package work? What platform/architecture does Settings/Information report?

--

Michael

Roland0
2017-10-23, 13:08
Another way to copy in the latest, known config.guess file without risking a broken automake would be to use: wget -O config.guess 'http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD' or curl 'http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD' > config.guess

As mentioned (http://forums.slimdevices.com/showthread.php?108166-Building-LMS-for-64-bit-Debian-running-on-ARM-Single-Board-Computers&p=897624&viewfull=1#post897624) that's how my script does it:


function refresh_config {
[ -f /tmp/config.guess ] || wget -O /tmp/config.guess 'http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD'
[ -f /tmp/config.sub ] || wget -O /tmp/config.sub 'http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;hb=HEAD'
cp -vf /tmp/config.guess .
cp -vf /tmp/config.sub .
}




The only assumptions used here a working wget (or curl) and an Internet connection. These extra build steps would be protected by an if [ "`uname -m`" == "aarch64" ]; then conditional, so the probability of breaking the script for existing platforms for which it works would be minimal.

If you wanted to check for arch, then one would just put the test into the refresh_config function. Same approach could be used to check for availability of wget/curl/network.


Any thoughts on why the above is not a good change to propose?

Except for the caveats already mentioned by you (which I think are minor - wget is available everywhere and usually already installed and if there is not net connection, one couldn't download the modules/script in any case), no.

dsdreamer
2017-10-23, 20:00
> I've done all this by hand
> before on different machines, but I like the automation and system
> accounting that Debian packages always provide.

Ah, the "on different machines" part makes sense. For a single machine
it wouldn't imho. Yes, I had to manually configure things and set up the
startup script on my server. But updates now only take me a few seconds
to "git pull" and restart :-).

Okay, I am aware of that usage model -- very nice when tracking nightly changes.


But assuming we had binaries for your platform, would the regular .deb
package work? What platform/architecture does Settings/Information report?
Michael
Yes, regular .deb packages would work very nicely, and I would prefer to use them if they were available, rather than brew my own. LMS reports "Platform Architecture: aarch64-linux".

dsdreamer
2017-10-23, 20:15
As mentioned (http://forums.slimdevices.com/showthread.php?108166-Building-LMS-for-64-bit-Debian-running-on-ARM-Single-Board-Computers&p=897624&viewfull=1#post897624) that's how my script does it:


function refresh_config {
[ -f /tmp/config.guess ] || wget -O /tmp/config.guess 'http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD'
[ -f /tmp/config.sub ] || wget -O /tmp/config.sub 'http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;hb=HEAD'
cp -vf /tmp/config.guess .
cp -vf /tmp/config.sub .
}



If you wanted to check for arch, then one would just put the test into the refresh_config function. Same approach could be used to check for availability of wget/curl/network.

Except for the caveats already mentioned by you (which I think are minor - wget is available everywhere and usually already installed and if there is not net connection, one couldn't download the modules/script in any case), no.
Thanks, Roland, you make perfect sense and are well ahead of me as usual.

Wouldn't it be nice to get these changes (or something very like them) merged into the main Logitech slimserver-vendor git repo? What were discussing seems like reasonable fix and could close this issue (https://github.com/Logitech/slimserver-vendor/issues/9).

mherger
2017-10-23, 23:38
>> But assuming we had binaries for your platform, would the regular .deb
>> package work? What platform/architecture does Settings/Information
>> report?
> Yes, regular .deb packages would work very nicely, and I would prefer to
> use them if they were available, rather than brew my own. LMS reports
> "Platform Architecture: aarch64-linux".

Is there any de-facto standard distribution most people are using? Or
are the most popular options at least using the same Perl version?
Otherwise adding support for this platform would be opening another can
of worms...

BTW: where do you put the binary files so LMS does find it? It currently
doesn't support the aarch64 architecture string, does it?

--

Michael

dsdreamer
2017-10-24, 09:11
>> But assuming we had binaries for your platform, would the regular .deb
>> package work? What platform/architecture does Settings/Information
>> report?
> Yes, regular .deb packages would work very nicely, and I would prefer to
> use them if they were available, rather than brew my own. LMS reports
> "Platform Architecture: aarch64-linux".

Is there any de-facto standard distribution most people are using? Or
are the most popular options at least using the same Perl version?
Otherwise adding support for this platform would be opening another can
of worms...

Yes, I see that doing this for multiple perl versions would be painful. I suggest considering Debian Stable (stretch), which is using Perl 5.024, and possibly also Ubuntu 16.04 LTS which is on Perl 5.022.


BTW: where do you put the binary files so LMS does find it? It currently
doesn't support the aarch64 architecture string, does it?

--

Michael
Currently, as my instructions earlier in this thread show, I am copying binaries into /usr/share/squeezeboxserver/Bin/.

If you would be willing to consider a pull request, I am currently in the process of trying to make the existing build scripts run on aarch64, but with a "do no harm" philosophy to ensure all other platforms keep building as they do today. See for example: here (https://github.com/crazzell/slimserver-vendor/commit/a381441dde084bdddce360a13e4040d7a156e64e). Notice the function refresh_config takes no action at unless the platform is Linux and the ARCH is aarch64. In that sense it is hopefully safe, but your review comments would be welcome. I am doing the same for the other buildme-linux scripts as well (work in progress).

Charles.

mherger
2017-10-24, 23:34
> Currently, as my instructions earlier in this thread show, I am copying
> binaries into /usr/share/squeezeboxserver/Bin/.

What about the perl Modules?

> If you would be willing to consider a pull request, I am currently in
> the process of trying to make the existing build scripts run on aarch64,
> but with a "do no harm" philosophy to ensure all other platforms keep
> building as they do today. See for example: 'here'
> (https://github.com/crazzell/slimserver-vendor/commit/a381441dde084bdddce360a13e4040d7a156e64e).

Nice! Did you base this on that other pull request which already exists?

I did merge yet another pull request earlier today which should handle
new perl versions much better than before. Make sure you rebase your
changes.

> Notice the function refresh_config takes no action at unless the
> platform is Linux and the ARCH is aarch64. In that sense it is hopefully
> safe, but your review comments would be welcome. I am doing the same for
> the other buildme-linux scripts as well (work in progress).

Thanks! Ordered a Rock64 today. Hopefully it won't take forever to ship...

--

Michael

Roland0
2017-10-25, 09:26
> Currently, as my instructions earlier in this thread show, I am copying
> binaries into /usr/share/squeezeboxserver/Bin/.

What about the perl Modules?


Seems enough that perl knows about the arch - buildme.sh queries perl for the arch, and at startup, perl includes the aarch64-x-y/auto/... automatically

-ol-
2017-10-26, 00:03
Hi,

I was wondering whether the described installation procedure could also work with an Odroid C2 using DietPi as OS (based on Debian Jessie)? DietPi has its own installation routine for the LMS but the version it is installing is completely outdated, updates are not possible, too. Transcoding options (like MP3, Flac, Sox) are not working either.

Any help would be very much appreciated.

Thanks & Cheers,
Oliver

dsdreamer
2017-10-27, 18:05
Hi,

I was wondering whether the described installation procedure could also work with an Odroid C2 using DietPi as OS (based on Debian Jessie)? DietPi has its own installation routine for the LMS but the version it is installing is completely outdated, updates are not possible, too. Transcoding options (like MP3, Flac, Sox) are not working either.

Any help would be very much appreciated.

Thanks & Cheers,
Oliver
IIRC, DietPi is still on Debian 8 for the odroidc2, which means it uses automake-1.14, whereas my patch file assumed automake-1.15. You can verify this by typing 'dpkg -L automake | grep guess' to see if "/usr/share/automake-1.14/config.guess" shows up.

You can patch the patch as follows:


wget -O slimserver-vendor.patch http://forums.slimdevices.com/attachment.php?attachmentid=23873
sed -i 's/automake-1.15/automake-1.14/g' slimserver-vendor.patch


If you do as shown above, I give it a reasonable chance of working. Or you can wait a little bit and I suspect Michael will have fixed the main git source repository so that patches aren't needed at all.

Charles.

dsdreamer
2017-10-27, 18:11
> Currently, as my instructions earlier in this thread show, I am copying
> binaries into /usr/share/squeezeboxserver/Bin/.

What about the perl Modules?

> If you would be willing to consider a pull request, I am currently in
> the process of trying to make the existing build scripts run on aarch64,
> but with a "do no harm" philosophy to ensure all other platforms keep
> building as they do today. See for example: 'here'
> (https://github.com/crazzell/slimserver-vendor/commit/a381441dde084bdddce360a13e4040d7a156e64e).

Nice! Did you base this on that other pull request which already exists?

I did merge yet another pull request earlier today which should handle
new perl versions much better than before. Make sure you rebase your
changes.

Michael
I was not smart enough to check back here before making my pull request. It did say "This branch has no conflicts with the base branch," so I thought I was okay. Tell me if I need to rebase. Hopefully, this change is pretty simple and shouldn't be hard to merge, but let me know.

Best regards,

Charles.

-ol-
2017-10-28, 00:30
If you do as shown above, I give it a reasonable chance of working. Or you can wait a little bit and I suspect Michael will have fixed the main git source repository so that patches aren't needed at all.

Charles, thanks for clarifying! I think I will then wait for what Michael is coming up with...

iPhone
2017-10-28, 07:51
.
.
Sure looks like a bunch of trouble to do something that can just be done using a quick Vortexbox Image. The reason I say that is if one doesn't want to run a big server but one also feels that a Raspberry Pi is not powerful enough or doesn't have enough storage, why not run a NUC or a Micro Server? Is 5 watts really going to make that much difference especially if one can just install a Vortexbox Image from a USB Thumb Drive and be done with it? Almost any 64 bit Micro Server, NUC, or Atom is a good candidate for a very energy efficient LMS/PLEX media server. If efficient but still need a bunch of storage, go for the 4 bay Micro Server with Optical Drive and rip CDs and Movies automatically. Just need a music server with 2TB or less, then a 4 by 4 by 2 inch NUC is perfect. Want small but still want auto ripping with 4 to 8TB of storage, then build a Vortexbox using an Atom.

Burn the Vortexbox Image to USB Thumb Drive and be done in 10 minutes.

atrocity
2017-10-30, 07:52
BTW: where do you put the binary files so LMS does find it? It currently
doesn't support the aarch64 architecture string, does it?

Might this be why DSDplayer and IckStream don't work on an Odroid C2?

dsdreamer
2017-11-05, 15:00
Might this be why DSDplayer and IckStream don't work on an Odroid C2?

I found out that I needed to compile dsdplay for aarch64, and copy it into /usr/share/squeezeboxserver/Bin. This would likely work for you too.


sudo apt-get install libflac-dev
sudo apt-get install libsoxr-dev
git clone https://github.com/SqueezeOnArch/dsdplay.git
cd dsdplay/src
make
cd build
sudo cp ./dsdplay /usr/share/squeezeboxserver/Bin/


Getting the Ickstream helper executables to build is harder (at least I couldn't find the source files on Github to give it a try). However, you might be able to get the armhf binaries to work by installing compatibility libraries, such as:


sudo dpkg --add-architecture armhf
sudo apt-get update
sudo apt-get install libc6:armhf libncurses5:armhf libstdc++6:armhf

The following commands can be used to check whether armhf is currently supported as a foreign architecture and whether the Ickstream armhf binary is loadable.


dpkg --print-foreign-architectures
armhf
cd /var/lib/squeezeboxserver/cache/InstalledPlugins/Plugins/IckStreamPlugin
./ickHttpSqueezeboxPlayerDaemon-arm-linux-gnueabihf
Usage: ./ickHttpSqueezeboxPlayerDaemon-arm-linux-gnueabihf IP-address daemonPort wrapperURL logFile authorizationHeader


If the above works, i.e., the usage line gets printed out as shown, you are good to use IckStream on your Odroid C2.

atrocity
2017-11-12, 11:11
I found out that I needed to compile dsdplay for aarch64, and copy it into /usr/share/squeezeboxserver/Bin. This would likely work for you too.

I apologize for taking so long to respond. I got myself stuck on a jury for a trial that went on for weeks and ate what little brain I had left when I started.

I was able to perform all the DSDPlayer steps as described without any errors, however attempting to configure a player under Settings just tells me "DSDPlayer does not currently include a version of dsdplay which supports your server. DSD playback has been disabled for this player." There is nothing relevant in the log, at least not at the default settings.

Running ./ickHttpSqueezeboxPlayerDaemon-arm-linux-gnueabihf gives me "error while loading shared libraries: libz.so.1: cannot open shared object file: No such file or directory"

I really, really appreciate your assistance, but there's probably not much point in pursuing this further, at least not on my behalf. This really is just a fun little backup server project for me and I'm not dead in the water without it by any means.

Thank you again!

dsdreamer
2017-11-24, 19:16
In case others are interested, I noticed that the nightly build here: http://downloads.slimdevices.com/nightly/7.9/sc/12c414e/logitechmediaserver_7.9.1~1511211491_all.deb now has binary support for AARCH64 when used with Perl Version: 5.24.1 - aarch64-linux-gnu-thread-multi.

Logitech Media Server Version: 7.9.1 - 1511211491 @ Mon Nov 20 21:08:22 UTC 2017
Hostname: rock64
Server IP Address: 192.168.0.100
Server HTTP Port Number: 9000
Operating system: Debian - EN - utf8
Platform Architecture: aarch64-linux
Perl Version: 5.24.1 - aarch64-linux-gnu-thread-multi
Audio::Scan: 0.95
Database Version: DBD::SQLite 1.34_01 (sqlite 3.7.7.1)
Total Players Recognized: 5

This suits Debian "stretch" and Ubuntu "zesty" (17.04). I was able to uninstall my self-built .deb packages and install this one from Michael with no issues on a rock64 SBC running stretch-minimal-rock64-0.5.10-118-arm64.img from here (https://github.com/ayufan-rock64/linux-build/releases/tag/0.5.10)

asplundj
2017-11-30, 06:25
In case others are interested, I noticed that the nightly build here: http://downloads.slimdevices.com/nightly/7.9/sc/12c414e/logitechmediaserver_7.9.1~1511211491_all.deb now has binary support for AARCH64 when used with Perl Version: 5.24.1 - aarch64-linux-gnu-thread-multi.

Logitech Media Server Version: 7.9.1 - 1511211491 @ Mon Nov 20 21:08:22 UTC 2017
Hostname: rock64
Server IP Address: 192.168.0.100
Server HTTP Port Number: 9000
Operating system: Debian - EN - utf8
Platform Architecture: aarch64-linux
Perl Version: 5.24.1 - aarch64-linux-gnu-thread-multi
Audio::Scan: 0.95
Database Version: DBD::SQLite 1.34_01 (sqlite 3.7.7.1)
Total Players Recognized: 5

This suits Debian "stretch" and Ubuntu "zesty" (17.04). I was able to uninstall my self-built .deb packages and install this one from Michael with no issues on a rock64 SBC running stretch-minimal-rock64-0.5.10-118-arm64.img from here (https://github.com/ayufan-rock64/linux-build/releases/tag/0.5.10)

Good to hear. Does that setup work with spotty as well?

mherger
2017-11-30, 06:48
> Good to hear. Does that setp work with spotty as well?

Yes, the latest Spotty update comes with improved support for this platform.

--

Michael

asplundj
2017-12-01, 02:33
> Good to hear. Does that setp work with spotty as well?

Yes, the latest Spotty update comes with improved support for this platform.

--

Michael

Tried it out last night and it works perfectly, thanks