Logitech squeezebox docker image is out of date

[jfearon]

Hi,

The logitech squeezebox docker image is now pointing at an old version (and technically its been renamed to logitech media manager too). Is it ok to simply update the rock on to point at another image on docker hub? For what its worth the most popular image works with something similar to:

{
    "Logitech Media Server": {
        "containers": {
            "logitech-media-server": {
                "image": "larsks/logitech-media-server",
                "launch_order": 1,
                "ports": {
                    "9000": {
                        "description": "Webserver Port. Suggested default: 9000.",
                        "host_default": 9000,
                        "label": "Webserver port",
                        "protocol": "tcp",
                        "ui": true
                    },
                    "9090": {
                        "description": "CLI Port. Suggested default: 9090.",
                        "host_default": 9090,
                        "label": "CLI port",
                        "protocol": "tcp"
                    },
                    "3483": {
                        "description": "SlimProto Port. Suggested default: 3483.",
                        "host_default": 3483,
                        "label": "Slimproto port"
                    }
                },
                "volumes": {
                    "/srv/music": {
                        "description": "Select the Share containing your Media",
                        "label": "Logitech media server data storage",
                        "min_size": 1073741824
                    },
                    "/srv/squeezebox": {
                        "description": "Select the Share to store your library",
                        "label": "Logitech media server config storage",
                        "min_size": 1073741824
                    }
                }
            }
        },
        "description": "Server for Squeezebox Devices",
        "ui": {
            "slug": ""
        },
        "volume_add_support": true,
        "website": "http://mysqueezebox.com",
        "version": "1.0"
    }
}

[magicalyak]

Go for it, just fork and submit a PR

[phillxnet]

@jfearon Dealing with older backlog here but if you are still game, as per @magicalyak suggestion your contribution would be most welcome.

If we don't hear back from @jfearon, as it's been quite a while, maybe we could leave this issue open in case others want to pick-up where they left off.

[Hooverdan96]

Hi, I have built a newer Rockon for the lms, which is based on the recent 8.x versions. I have selected a fork from the larsks/logitech-media-server built, because it gets updated more frequently (apnar/logitech-media-server). It also separates the config/cache/ media shares from the container. I can submit a pull request for that.
Only thing is that it requires the net=host option, otherwise one of the streaming pieces doesn't work (from LMS to airplay devices).
Regards,

[phillxnet]

@Hooverdan96 Hello again. Re:

I can submit a pull request for that.

That would be great. We do have a bit of a backlog unfortunately but I'm expecting that to clear shortly as we are close to getting our act together on 'capacity' re merging. More on that soon.

Only thing is that it requires the net=host option

Yes, that is a tricky one. We have allowed this on the Plex Rock-on for similar reasons, and because of the extreme popularity of Plex. I say pop in the Pull request and we can discuss this network 'overreach' there. If you link back to this issue with a "Fixes #" line it would help for context, and tidy up.

Thanks for stepping up to this one.

[Hooverdan96]

Thanks for the feedback. I will go ahead with the pull request. One more question, should I go for updating the existing rock-on (that runs on the 7.x branch) or should I create a new one that's starting to use the new 8.x path? Understood that the "old" version is not up to date anymore, but wondering whether it should be kept around for current users?

Thanks.

[phillxnet]

@Hooverdan96 Great. Re:

or should I create a new one that's starting to use the new 8.x path?

I favour starting a fresh rock-on using a different name. That way we can phase out the old one and if folks really need it then they can pick it's definition up from git history as we will likely drop it soon anyway if it's not being updated, or with docker hubs new policies it may end up deleted and so not available anyway.

In your image selection are you taking into account Arm64 compatibility? We are trying to favour multi arch images if they are at all available. See issue by @mcbridematt :
rockstor/rockstor-core#2191
From that issue it looks like our existing Logitech Squeezebox is not currently Arm64 compatible so it would be good to tend to another dangling incompatibility on that front.

But I would defer to @FroggyFlox on this new or replace question. But starting out a fresh is likely a safe bet and given the shares will be different, I'm assuming, it's not easy to migrate from old to new anyway. So if separately developed we can simply delete the old one when the time comes.

[Hooverdan96]

You had to ask for the arm aspect, didn't you 😊?
The container I had picked does not have an Arm compatible build. I did find one that has all (amd64, arm and arm64) now (https://hub.docker.com/r/doliana/logitech-media-server), that seems to be pretty popular. I will experiment with that one, and if that works, I will drop that one in instead. Otherwise I will report back "why not". Eventually I am hoping for LinuxServer.io to publish one (like they have done for Plex and others) because I consider these usually very well made, and long-term supported), but I'm not holding my breath since that has been open over there for over 2 years I think. Logitech will not create an "official" image, I assume, because it's really open source now, and I suspect the maintainer has too many other things going on for also putting out an official docker image ...
I also favor the "new" approach, especially since the old container did not expose the configuration share, which I find critically important (LMS has a ton of settings one can take advantage of, so it would be a pain to have to recreate them any time something goes wrong ...

[FroggyFlox]

I also favor the "new" approach

Yes, me too!

Nice find on the Arm64 compatible image. I noticed its documentation on Github stipulates it's only a test image based on a PR from the larsks/logitech-media-server image, but the latter is now archived and will thus never be merged and updated. Your image seems like the best one so far.

Thanks a lot for stepping up to this one, @Hooverdan96 !

[Hooverdan96]

@FroggyFlox,
while testing the new image, I realized that unlike the linuxserver.io images (a VERSION variable that's passed into the image, which then takes care of the installation of the corresponding version) I won't be able to specify a version during the installation.
Is there a way to surface the tag in the UI during the installation?
This image is using the conventional approach for versioning (i.e. the tag on the docker hub identifies it). To make it more flexible it would be great to be able to manually define the version (so we don't have to create a json for every flavor).
The tags for this image have the format "latest-7.9.3", "latest-8.0" or "latest-7.9.4" - representing stable/alpha/beta releases.
And reading through your excellent wikified post (https://forum.rockstor.com/t/rock-on-framework-implementation/6288/2) I couldn't tell whether it's easily possible or not.

[FroggyFlox]

Is there a way to surface the tag in the UI during the installation?

Not at the moment but that is something that has been brought up earlier and I personally really like the idea. I personally will not be able to attend to that any time soon but I believe this is something we definitely need in the future, yes. See the comment below where this was brought up:
#190 (comment)

As you can see, this was needed as well for our postgresql rock-ons and we ended up making different ones as postgresql versions can be critical. With regards to Logitech Squeezebox, I have no idea so I would refer to your own expertise there.
It seems to me that the latest stable version would be preferred, of course (so "latest-8.0"?), unless there is some specific hardware depending on an older version or something like that.

Sorry I couldn't give a clearer answer. I would personally choose the most up-to-date and stable version that we can use, but that can be reconsidered if there is a need for it.

[Hooverdan96]

Right, I remember now having that discussion in a couple of places. I will probably go with the latest-8.0 version at this time. Longer term I hope we'll get Linuxserver.io to provide one and then the version is likely parameterized (if other images are any indication).
Thanks, then I will proceed with the pull request, etc. and we go from there.

[Hooverdan96]

Created Pull Request for this: #238

[Hooverdan96]

A couple of comments on this Pull Request:

1. I decided to go with the latest 7.9.4 release at this time, as I observed some instability with the 8.0 branch (that one seems to be more like the alpha branch still). If this RockOn version is accepted, and the 7.9.x version increases, I can quickly change the tag and push again at a later point. If the development and release focus switches to 8.x in the near future, we can decide to either create yet another version of this, or make changes (and retitle) this RockOn.
2. I tried and tested without using the "--net=host" option, but in order to get AirPlay and Chromecasting to work with the plugins available within the server, I had to revert to this, as (at least for me) I could not get it to work without that. That's also what I had read in a few comments on some message boards ...