Hi k-plan,
thanks a lot for taking the time and your very thorough response! I am seeing clearer now what´s going on and why it´s not that easy to just implement a recent version of LMS along with the missing features. I think I will get rid of the C2, hardkernel´s efforts in providing current software for at least this SBC are just too limited.
I am wondering though which SBC would work well instead with dietpi? I would like to have something a bit more beefy than the RPI3 (memory especially as well as CPU power) since it really helps speeding up the scanning times and building of the database of larger music libraries. XU4 is not an option though, because of the dreaded fan noise.
I´ll do some research, in case you have any recommendation I would be glad to hear it.
Thanks again & Cheers,
Oliver
Alas, I don’t read german…
Is there any reasonable way to update the packages diet-pi uses for LMS to something newer than the Feb 2018 release currently being used?
notherNewbie
There is no newer release. Actually 7.7.6 is current stable while DietPi ships current Beta 7.9.1: http://downloads.slimdevices.com/
The download page is confusing, while 7.9.1 is listed as the latest release, if you go to the nightly build page you’ll see that the current beta is 7.9.2.
http://downloads.slimdevices.com/nightly/index.php?ver=7.9
The main maintainer is always posting tweaks, the last was two days ago.
http://htmlpreview.github.io/?https://github.com/Logitech/slimserver/blob/public/7.9/Changelog7.html
https://github.com/Logitech/slimserver/blob/public/7.9/Changelog7.html
The version DietPi uses suffers from issues when using spotify.
Nightlies is a different topic. Those are in-dev builds, containing untested commits, clearly not recommended for production use. We already ship a (the most recent) beta, which is already not what most conservative distros would do. But at least a Beta is already meant to be used not only by developers but external testers.
There are many cases where software releases are done very rarely and much development is done for years in dev/nightly or beta only. But this is a schedule issue/decision of the developers and we are not going to ship in-dev nightly builds to our end users 
.
I understand the desire to avoid betas, much less nightly builds, however the maintainer of LMS views the nightly builds as stable. Here’s a quote from the maintainer of LMS on discussion I started on this topic.
It is a beta build. It is a nightly. It is stable. Call it what you
want. It’s really only the DietPi’s dev’s understanding (or lack
thereof) preventing him from “allowing” his users to use it. Giving it a
different name won’t make it any more stable. In theory 7.9.2 is just
another bugfix release for 7.9.x. The dev should accept 7.9.x.
I would respectfully recommend either you recognize the nature of the LMS nightly releases as ‘stable’ or drop it from your distribution since anyone who wishes to use the spotify plugin for LMS will encounter nothing but frustration.
I just read the discussion:
- Actually we do no checks about LMS version (or running system) and you ARE indeed able to install any version you want on DietPi.
- It is only the dietpi-software script that grabs the latest beta instead of nightly. At best install this first, then simply install the nightly on top of it according to their install instructions for Debian. Should work well.
However this understanding of stable > beta > nightly is confusing to me. A nightly is called a nightly because it’s automatically created from the current development code every day/night, at least according to widely accepted conventions and this is where the naming comes from. Okay it depends on the individual procedure but at least one cannot expect more than max one day of (public) testing. This simply CANNOT be considered as “stable”. Of course devs can (and should) run deep tests before merging their commits into the development branch, but still having a final downloadable binary (or source) that is just available for max 24h to public testers, and, not even linked from any download page on the website, is what no professional coder or user would recommend you as “stable”.
So of course “Giving it a different name won’t make it any more stable.”, but by giving it at least the name Beta and linking it from prominent place on the website will allow public testers to run the code on various different machines and setups to “prove” it stable in a way that devs simply cannot. If this is skipped with above quotes, then the whole nightly/beta naming is obsolete and can be skipped and you better publish every as “stable” expected code change as new release directly, taking the possible stability decrease. At least users will see the update at all.
In this case I am not sure how much development was actually done. If it was only a tiny fix with minor code that can be well overviewed, then it might be correct that one can accept it as stable. Not my business to check all commits, I usually trust public releases, this is what the effort about releases is for.
notherNewbie
However if you can find at least 1-2 other users that prove the nightly LMS stable on Debian, we can implement this into DietPi as well. Or we implement this directly and hopefully find some willing Beta testers for our next Beta phase to prove it stable.
Thank you for looking into this. I realize that the definition of nightly builds of LMS as ‘beta’ and/or ‘stable’ is non-standard and, thus, can be confusing. My understanding is that most of the changes to the code base are small.
Thanks for clarifying that there is no incompatibility caused by installing more recent .deb files. I had run into problems with that set up, but it could have been an error on my part somewhere. I will try it again and post back later.
Perhaps someone else reading this thread will also volunteer to test the nightly builds.
Again, thanks for taking the time to consider my request.
notherNewbie
Jep please report any issues with the LMS nightly here first, so I can recheck our install and config code for possible reasons first. But should work well.
I indeed overlooked the Completed appendix… so I erased my post!