Logitech Media Server LMS

No, I am not a developer. The problem with LMS on arm machine is the ready-made package doesn't support armel (32-bit arm) and requires one to build perl CPAN for armel to replace what is in the in the LMS package. I have done this once before and that is what is currently running in my Pogoplug Pro. (I actually went a step further and built my own LMS package.) The second thing is LMS itself needs about 250mb to 300mb of disk space but I think there is a way in OpenWrt to use external USB stick/hard drive for the purpose. I hope the scheme would work out.

Thanks for bursting my bubble and offering a way out (or two?). I know I am too optimistic. Make an OpenWrt package is out of my league. I had looked into that direction when I was tinkering with the idea of building my own wifi driver for Realtec RTL8188FTV. Too much to learn. About a fully static-compiled binary do you mean building directly on the router that is running OpenWrt?

@bobafetthotmail there are a ton of people out here who would be grateful if you were to help out with a Howto on deboostrap. I already have a chroot environment, if that's the same. I have lots of space on my USB stick on the router presently. I an also test, as I have an old router I can use. May I then thank you in advance on that Howto? Many thanks, meanwhile, for your contributions to this thread.

There is a chroot/debootstrap guide on the OpenWrt wiki, and is talking of Debian 10 so it's relatively up-to-date. https://openwrt.org/docs/guide-user/services/chroot

The main preparation you need for that is a USB drive or similar storage that is auto-mounted on boot by OpenWrt, where you can create a folder to stuff the Debian OS. In the example it is using the whole drive (/mnt/sda) but you can just make a folder (like /mnt/sda/debian) and do your chroot there.

And you need to at least identify what architecture of CPU your device has, because that is required to choose the right architecture of Debian to put in the chroot.

If you are unsure, post here the device model and I can tell you what Debian architecture you can/should choose.

No, a statically compiled application is a single large executable that contains all the libraries and stuff that it needs, and is therefore not relying on the system's OS libraries.
It is large because you are putting Glibc, plus all other dependencies it may need in the same file.

Compiling directly on the router is not possible (not enough resources, and very limited build environment), and also not necessary. OpenWrt build system is designed to cross-compile so you can use your PC which is vastly more powerful than a router.

According to the wiki techdata https://openwrt.org/toh/hwdata/linksys/linksys_ea7500_v1 the revision 1 of this device has a relatively modern ARM CPU with hardware floating point math coprocessor, so you should be able to use Debian armhf architecture

while the revision 2 https://openwrt.org/toh/hwdata/linksys/linksys_ea7500_v2 has a completely different CPU, and it should work with Debian mipsel architecture

Yes, I have EA7500v1. Good to know it is armhf architecture - one less thing to do. I think I will go with the chroot route. Time to learn chroot/debootstrap. Your comments are very much appreciated.

Hm, maybe a debian chroot isn't a silver bullet.
Since this "logitech media server" isn't something that just comes prebuilt in Debian repositories but is just a third party application downloaded from here https://www.mysqueezebox.com/download, the perl architecture issue you mentioned here may still exist Logitech Media Server LMS - #21 by rwl408?
since they bundle the Perl interpreter application, and it is compiled for x86_64 (normal PC), "ARM" whatever their own interpretation of this term is. ANd on top of that it's probably expecting an OS with Glibc like most Linux PC or Raspberry Pi distros are.

So you might very well need to recompile the application from source again like you said, https://github.com/Logitech/slimserver

But from what I understand, you should be able to just configure it to use the OS's Perl, since from what I'm reading the application is just a pile of Perl scripts (i.e. architecture-independent).
It should theoretically run on anything that has Perl interpreter installed, Debian or OpenWrt, unless the Perl package in OpenWrt is hobbled in some way.
Because OpenWrt has Perl and a lot of Perl modules (the "libraries" needed by perl scripts, you will need to figure out which of these you need as well) https://openwrt.org/packages/index/languages---perl

See this dude for the cheeky "compiling from source" that is mostly just "quickly hacking the perl scripts to use the system's Perl interpeter instead than the bundled one"
https://angerman.net/articles/lms/

Now I know I make this sound easy and fun and whatnot, it probably is not all fun and games, if it was so easy to port it and make a package for it someone would have made it I guess.

But that's at least someone else's opinion on the matter.

I have not tinkered with docker on openwrt, but i see a arm/v7 tagged release here?

In the past (last 5 years) the issue was that normal docker images where most often x86-64 only and docker itself also needed a 64bit host. So if this has changed, it might be much easier now to get stuff like LMS running on 32bit arm router hardware.

So check if openwrt docker can run on arm/32 and than you should be able to use the "official" armv7 image from dockerhub.

PS: Btw aside from the disk space, which can be relatively easy extended via usb/sata on most modern routers, what about the RAM usage for a normal LMS server? Will it run on 128/256MB devices or need 512MB+?

This will work only on devices with relatively modern ARM processors like the EA7500v1 of rwl408.

Kirkwood, older Raspberrys and others are too old ARM (armv5 or v6), a bunch of other targets that have mips CPUs can't use that and I don't think mips can even use docker at all.
Assuming you can run docker on most of them due to resource constraints.

I personally find baffling that the only/main thing that is causing this cpu arch incompatibility mess is the bundled Perl language interpreter, that is not even specific for their project. It's like requiring someone to use your own pre-compiled Bash shell to run a shell script.

And to "solve" the problem someone is making a docker image, so they can pull in hundreds of MB of dependencies and require the resources to run docker itself, to run a Perl language interpreter to read Perl scripts.

(insert jackie chan wtf meme)

@bobafetthotmail Your analysis is to the point. You cut through the chase and very quickly pin point the main problem. I wish we can do same with the solution for LMS on openwrt, now that we know, so clearly, and thanks to you, the precise problem to be solved. Not a programmer myself, I cannot venture past your beautiful and clear explanation of the problem. Now the solution! Ha! Where do we now go?

Yeah but from a developer side, you only have to support/test your own docker image and can be sure this container runs well on all container targets. The overhead for a small dev to support even a few linux distros and target archs is very steep, that's why nearly all linux distros need package maintainers. So you trade size/resources for the ability to quickly test and deploy, your product yourself, without any extra maintainers involved.

I'm also not sure, but how is the state of target compiling perl scripts + deps into a static binary? This way you wont need the interpreter at all, which might be easier to get a working openwrt makefile? I know this works ok'ish with python/java scripts, but never done this for perl.

You can use lxc or docker on some arch as arm64.
I was using the lxc method described here, OpenWrt ARM64 QUICK LXC HOWTO/GUIDE (LMS in Debian System in LXC Container)

But I have now replaced it by a docker installation, which is simpler to maintain and update and look also faster…

@erdoukki thanks for your contribution. Can to share your docker solution process?

The above is mostly irrelevant for interpreted languages since as long as the target has the same version of interpreter it will work.

Python scripts or shell or ruby or node or whatever the heck can be easily deployed without the need of containers because you can just install the runtime and the libraries at the right version, that's the whole point. They are self-contained

That's what that package is doing by default already.
For Perl and Pyton that means bundling the interpreter and the libs and the scripts in a single binary. So yeah you are still using an architecture-specific interpreter. https://www.marcbilodeau.com/compiling-perl/

For Java and Net if you do this to get native-ish code then it's native-ish and therefore architecture-specific.

Either way you are not solving the problem that just expecting to have an interpreter in the target would solve.

I already asked you to tell your device model and revision so we can see if you can actually use these fancy container technology on it or if you are stuck waiting for someone to actually do a proper porting, or maybe we can suggest a new (or used) device that might be compatible with said fancy container technology.

@bobafetthotmail I am sorry. I missed that. To be honest, my devices, all of them, are rather old or not ideal for running Openwrt. For example, my main router now runs 19.07. So, I welcome, very much, from some as you, the suggestion for a device. And I will try and get it. You might see, for example, 3 days now, my thread trying to install OpenWrt on a Fritzbox 7362SL, without much luck. As you have great experiences, perhaps you could contribute to that thread. In fact, I opened a new thread today, related to it, in trying to figure out how to increase ram space on my device and ftp eva-ramboot to it. anyway, back to LMS, without your input, yes, waiting, as I've been for years now, was my only option. Thanks a lot!

Yes, sure...
I have already planned to write a docker LMS article.
I will try next week to share my notes

Thanks a lot. Very nice of you. Pleas,e do, please, assume the reader(s) know very little. I've seen a lot of guides where the author clearly thinks the reader knows as much as they do, which would make a guide unnecessary :slight_smile:

did you check this?

btw any of you knows how can i delete my previous post. tx