lms-community / lms-community.github.io Goto Github PK

Two point about how the lyrion.org behaves in a browser

FIRST: The second line of headings only visible when window very wide

I realised that sometimes the lyrion.org home page seemed friendly - with useful links across the top, and other times less so, having to go via the LH sidebar to get anywhere. I now see why it sometimes feels different.

I am viewing on a 1920x1080 HD display. If the Lyrion.org window is about 1530 pixels or wider you get the two line top bar with link, plus three links in LH sidebar.
The moment the window is narrower than that, that second line disappears- even tho that second line takes fits in a bit less than 900 pixels. And the LH sidebar disappears too. So suddenly there is (almost) nothing left to click!

Could we see if we can tweak the numbers in the CSS Grid control settings to keep the second line visible until window much narrower, certainly leave it there until 900 px wide.

SECOND First view of LH Sidebar does not include most important links to use

When the LH sidebar is not visible it can be deployed by clicking on the "three horizontal lines" button which appears top left.

The options immediately displayed are "Home", "Overview" and "Community Forums". You have to click on "Home" in order to bring up the (IMHO much more important) links "Home, Getting started, Players&Controllers, Plugins, Contributing, Reference."

FOr my money I would rather see the "links Home, Getting started, Players&Controllers, Plugins, Contributing, Reference." set of links straight away, and not have to click twice.

Screenshot shows the lyrion.org in as narrow a window you can have before it removes second line of headings and the LH sidebar.

Legacy HTML Document migration plan

Source:

Name: Skin Creation

• Legacy URL: LMSSERVER:LMSPORT/html/docs/skins.html
• HTML file length: 604 lines
• How current: Page starts with line: "WARNING: This documentation is substantially out of date."

Migration option:

• Some sort of Graveyard repository?

Legacy HTML Document migration plan

Source:

• Name: Softsqueeze
• Legacy URL: LMSSERVER:LMSPORT/html/docs/softsqueeze/index.html
• HTML file length: 10 lines
• How current: This is now only a series of links to players like squeezelite, not softsqueeze specific. Links point to Forum posts which is probably suboptimal

Migration option:

• Merge this content with other material already in place. Ensure links go to lyrion.org pages, rather than the forums
• Page location: Players & Controllers -> Software Based

Text of existing page

SoftSqueeze emulates Squeezebox and Transporter on Windows, Mac OSX and Unix Computers.

Since Server 7.4 SoftSqueeze is replaced by SqueezePlay

Meanwhile SqueezePlay isn't shipped the the standard installation anymore.

There are some Squeeze Software Emulations out there eg. the ones that Ralph Irving maintains.

Name:         Description:                                         Link to our Forum:
Jivelite      Graphical Frontend without Playerfunctionality.     Link
Squeezelite   Commandline Player without Frontend.                Link
SqueezePlay   Graphical Frontend with Playerfunctionality.        Windows

On the download page, when trying to download the most recent version of .deb for amd64 Linux, I run into a 404 page.

Please don't forget to update the CLI documentation LMS-Community/lms-community.github.io@main/docs/reference/cli.

Process question: how do we want people to report and request fixes and changes to the documentation - including small typos etc, "rats-and-mice" changes?

Options would include:

• Raise an Issue like this
• Post into the Forums, for example:- Forums -> Developer Forums -> Developers

Recent discussion in forums indicates that we should be planning to migrate the HTML Help pages which were embedded in the LMS distribution to this new Lyrion.org repository.

These pages linked on any LMS install via base url: http://lms-server:LMSPORT/html/docs/

There are about 15 of these pages, excluding menus, of which one has been done.

The content of each page does need a bit of thought:

• if info is up to date does this go to its own new page, or merge with page already migrated from the legacy wiki
• if info obsolete do we just not migrate it - or do we set up a graveyard (as per separate discussion about obsolete plugins).

So proposal (following up other discussions with @Lauret etc) is:-

• to create a separate Issue for each of these files.
• we can discuss best option
• someone can allocate themselves the task
• and once page is migrated the issue can be closed.

This will generate a few issues; on other hand the discussions should be short and easy to follow.

Hope this sounds ok. Respond asap if not!

HELP MENU

• remote.html - Remote Control Reference This is about Infra Red remote controls
• remotestreaming.html - Remote Streaming
• softsqueeze/index.html - SoftSqueeze - Now a short page, mostly just links, link label and page title better 'Software Players' perhaps

TECHNICAL INFORMATION MENU

• artwork.html - Artwork Setup
• radio-compatibility.html - Squeezebox Radio & Logitech Media Server 8+
• http.html - The Logitech Media Server Remote Control This is mostly about how to use the CLI, not about Infra Red remote controls
• cli-api.html - The Logitech Media Server Command Line Interface - DONE
• skins.html - Skin Creation The page says it is out of date
• xpl.html - The Logitech Media Server xPL Interface
• plugins.html - Logitech Media Server Plugins
• buttons.html - Button Mapping
• input.html - Input Modes
• fonts.html - Font Files
• display.html - Display API
• slimproto.html - The Squeezebox Client Protocol

We have a pretty complete CLI documentation built in to LMS. But it doesn't cover the use of those commands using tools like netcat, curl, or wget.

And maybe we could even render a more user friendly version of the above by converting it to markdown?...

Not urgent, the link already redirects to the right place.

Update this page: https://lms-community.github.io/reference/logitech-media-server/

Replace this target of the URL in this line about Sourcecode

Currently:
Sourcecode can be found on Github: https://github.com/Logitech/slimserver.

Replace with:
Sourcecode can be found on Github: https://github.com/lms-community/slimserver.

Legacy HTML Document migration plan

Source:

Name: Plugins

• Legacy URL: LMSSERVER:LMSPORT/html/docs/plugins.html
• HTML file length: 297 lines
• Subject: guidelines on how to create plugins
• How current: Not sure @mherger to assess.

Migration option:

• if info is current
  • Migrate to new page
  • Page location Reference -> Development

Source:

• Name: Input Modes
• Legacy URL: LMSSERVER:LMSPORT/html/docs/input.html
• HTML file length: 361 lines
• How current: To be determined

Migration option:

• If current:
  • Page location: Reference -> Development

Command line interface - CLI commands documentation

Some (not high priority) issues which came up when doing some further testing of the CLI - done mostly with the intention of generating some more examples, particularly JSONRPC ones, which are (IMHO) heaps easier to read.

PURPOSE OF ID PARAMETER WITH JSONRPC ?

See JSONRPC section of Using the CLI
Question about the "id" parameter for JSONRPC. In the JSONRPC notes for use by CURL etc, one of the parameters passed is "id" (along with "params" and "method"). I realise that when running the commmands via JSON I have not included "id" and it still seems to work.

What is its function? - maybe to allow the response to multiple JSONRPC calls to be easily distinnguished?

PLAYER COMMAND INCONSISTENCIES

I was doing some followup checking on behaviour of certain CLI commands for Players.

The command players provides full info about all connected players; this works fine, documentation is inline with behaviour.

There is also group of eight commands like "player name" which return a specific piece of info about a particular player.
The subcommands are: name, uuid, displaytype, id, ip, model, isplayer, canpoweroff

These commands have more than one format to achieve the same result - based on the documentation and examples given. The variants are wrt the parameter used (playerid or playerindex) and where the parameter is placed (as a pre-pended player identifier or after the 'player ' bit).

Syntax Options with Player identifier after the player <subcommand> string

• SYNTAX-1 player name <playerindex> ?
• SYNTAX-2 player name <playerid> ?

where <playerid> is (usually) the player's MAC address, and <playerindex> is a sequence number assigned to players currently recognised by the server, with values like 0, 1, 2 etc

Syntax options where Player identifier precedesthe player <subcommand> string

Some places in the documentation it is shown that these two forms are also permissable.

• SYNTAX-3 <playerindex> player name ?
• SYNTAX-4 <playerid> player name ?

See for instance syntax and examples for player name

Testing results

All of these formats (SYNTAX-1 thru -4) "work" in that they return a result; but I noticed some discrepancies.

So we need to test all four formats for eight subcommands for four players (as one does).

• used all four SYNTAX options as above
• used all eight subcommands (name, uuid, displaytype, id, ip, model, isplayer, canpoweroff)
• while having four players connected (one squeezelite, two Sb Radios one SB Classic v3)

And compared the results with what comes back from the players command

Result of this testing is that SYNTAX-3, and SYNTAX-4 while they work (in that a result is returned) do not provide an accurate response. They seem to always return information about the player currently with Index 0.

Suggested actions:

• Remove any use of Syntax-3 or Syntax-4 from the documentation, including the Examples
• Include a cautionary note

@mherger - Your call as whether this should be raised as a bug?

Number of players: 4
Info on all players from the players command
0 {'playerindex': '0', 'playerid': '98:2c:bc:18:e1:06', 'uuid': None, 'ip': '192.168.5.22:60888', 'name': 'Squeezelite-X', 'seq_no': 0, 'model': 'squeezelite', 'modelname': 'Squeezelite-X', 'power': 1, 'isplaying': 0, 'displaytype': 'none', 'isplayer': 1, 'canpoweroff': 1, 'connected': 1, 'firmware': 'v1.9.9-1419'}
1 {'playerindex': 1, 'playerid': '00:04:20:28:c7:f1', 'uuid': 'ca1c8fbf2d48cbb1c859b5ea7ce4ecf9', 'ip': '192.168.5.102:56551', 'name': 'Stalking Horse', 'seq_no': '12', 'model': 'baby', 'modelname': 'Squeezebox Radio', 'power': 1, 'isplaying': 0, 'displaytype': 'none', 'isplayer': 1, 'canpoweroff': 1, 'connected': 1, 'firmware': '8.0.1-r16924'}
2 {'playerindex': 2, 'playerid': '00:04:20:12:ae:f5', 'uuid': None, 'ip': '192.168.5.103:47742', 'name': 'Dittography', 'seq_no': 0, 'model': 'squeezebox3', 'modelname': 'Squeezebox Classic', 'power': 1, 'isplaying': 0, 'displaytype': 'graphic-320x32', 'isplayer': 1, 'canpoweroff': 1, 'connected': 1, 'firmware': 137}
3 {'playerindex': 3, 'playerid': '00:04:20:2a:e0:74', 'uuid': '7147ee259b66f5c9c39c0eb14cfefb5c', 'ip': '192.168.5.101:53614', 'name': 'Runcible Red', 'seq_no': '220', 'model': 'baby', 'modelname': 'Squeezebox Radio', 'power': 1, 'isplaying': 0, 'displaytype': 'none', 'isplayer': 1, 'canpoweroff': 1, 'connected': 1, 'firmware': '8.0.1-r16924'}
****************************************

Now testing the 'player <subcommand>' set of commands giving info on individual players
Subcommands to test are: ['canpoweroff', 'displaytype', 'id', 'ip', 'isplayer', 'model', 'name', 'uuid']

Subcommand      Syntax 1              Syntax 2              Syntax 3              Syntax 4             
--------------- --------------------- --------------------- --------------------- ---------------------
PLAYER Index:0 ID:98:2c:bc:18:e1:06  Name:Squeezelite-X

canpoweroff     1                     1                     1                     1                    
displaytype     none                  none                  none                  none                 
id              98:2c:bc:18:e1:06     98:2c:bc:18:e1:06     98:2c:bc:18:e1:06     98:2c:bc:18:e1:06    
ip              192.168.5.22:60888    192.168.5.22:60888    192.168.5.22:60888    192.168.5.22:60888   
isplayer        1                     1                     1                     1                    
model           squeezelite           squeezelite           squeezelite           squeezelite          
name            Squeezelite-X         Squeezelite-X         Squeezelite-X         Squeezelite-X        
uuid            None                  None                  None                  None                 
*******************************************************************************************************
PLAYER Index:1 ID:00:04:20:28:c7:f1  Name:Stalking Horse

canpoweroff     1                     1                     1                     1                    
displaytype     none                  none                  none                  none                 
id              00:04:20:28:c7:f1     00:04:20:28:c7:f1     98:2c:bc:18:e1:06     98:2c:bc:18:e1:06    
ip              192.168.5.102:56551   192.168.5.102:56551   192.168.5.22:60888    192.168.5.22:60888   
isplayer        1                     1                     1                     1                    
model           baby                  baby                  squeezelite           squeezelite          
name            Stalking Horse        Stalking Horse        Squeezelite-X         Squeezelite-X        
uuid            ca1c8fbf2d48cbb1c...  ca1c8fbf2d48cbb1c...  None                  None                 
*******************************************************************************************************
PLAYER Index:2 ID:00:04:20:12:ae:f5  Name:Dittography

canpoweroff     1                     1                     1                     1                    
displaytype     graphic-320x32        graphic-320x32        none                  none                 
id              00:04:20:12:ae:f5     00:04:20:12:ae:f5     98:2c:bc:18:e1:06     98:2c:bc:18:e1:06    
ip              192.168.5.103:47742   192.168.5.103:47742   192.168.5.22:60888    192.168.5.22:60888   
isplayer        1                     1                     1                     1                    
model           squeezebox2           squeezebox2           squeezelite           squeezelite          
name            Dittography           Dittography           Squeezelite-X         Squeezelite-X        
uuid            None                  None                  None                  None                 
*******************************************************************************************************
PLAYER Index:3 ID:00:04:20:2a:e0:74  Name:Runcible Red

canpoweroff     1                     1                     1                     1                    
displaytype     none                  none                  none                  none                 
id              00:04:20:2a:e0:74     00:04:20:2a:e0:74     98:2c:bc:18:e1:06     98:2c:bc:18:e1:06    
ip              192.168.5.101:53614   192.168.5.101:53614   192.168.5.22:60888    192.168.5.22:60888   
isplayer        1                     1                     1                     1                    
model           baby                  baby                  squeezelite           squeezelite          
name            Runcible Red          Runcible Red          Squeezelite-X         Squeezelite-X        
uuid            7147ee259b66f5c9c...  7147ee259b66f5c9c...  None                  None                 
*******************************************************************************************************

UUID values truncated to 17 chars to keep the table pretty.
UUID values of None (the Python key word indicating a nullvalue) shown as the string 'None'

For those of us inside the ecosystem it is important to remember the outsiders who could become insiders. Terminology should be clear and abbreviations in particular should be easy to understand/follow. Part of this is ensuring terms are clearly defined and that people can see the connections between things. I therefore would like to suggest this as a starting example (I've bolded body text changes, but note also the headings):

Lyrion Music Server (LMS)

Lyrion Music Server (formerly Logitech Media Server , and often abbreviated as "LMS" ) is open-source software which can control and serve (stream) music to a wide range of physical and virtual audio players called "Squeezeboxes". Lyrion Music Server can stream your local music collection, internet radio stations, and content from many streaming services (with and without subscriptions).

The Lyrion Music Server (LMS) ecosystem

In 2000, Squeezebox players hit the market as hardware and software developed by Slim Devices, later acquired by Logitech. A wide array of hardware and software solutions make up the LMS ecosystem of servers and players for many different operating systems, and these have changed many times over the years.

A few simple rules or preferred vocabulary would aid consistency in documentation. These are a few I am trying to follow. Any additions, corrections?

No particular order:

FORMATTTING

• File extensions
  • Refer to them in upper case, so JPG, FLAC, GIF

VOCABULARY

• The Library
  • Refer to as the Media Library following how it is referred to in Settings (and not Music Library)
• The folder containing the Library
  • Settings calls this "media folder"
  • Checking more carefully in CLI documentation I see I have incorrectly emphasised the alias 'musicfolder' database CLI command rather than the preferred option of 'mediafolder'. A comment in Request.pm source file says "# musicfolder is only here for backwards compatibility - it's calling mediafolder internally". I will fix that. https://lyrion.org/reference/cli/database/#musicfolder
• Music files
  • Refer to them as Media Files (not Music Files)
• Talking about LMS
  • Refer to the LMS Server rather than LMS Software

Legacy HTML Document migration plan

Source:

• Name: Button Mapping
• Legacy URL: LMSSERVER:LMSPORT/html/docs/buttons.html
• HTML file length: 57 lines
• How current: looks ok as far as it goes, but the last line is "more to come"

Migration option:

• Migrate to new page
• Page location: Reference -> Development
• Assignment @Daksol will do this migration

Legacy HTML Document migration plan

Source:

• Name: Remote Control Reference
• Legacy URL: LMSSERVER:LMSPORT/html/docs/remote.html
• HTML file length: 63 lines
• How current: Looks ok. Only includes info on the 31 button remote, not on the 14 button remote.
• Migration option: Create new page. Update page to include info on the 14 button remote.
• Page location: Players & Controllers -> Hardware Based.
• Page Title: "Logitech Player Remote Controls"

Assignment: @Daksol volunteers

Couple of questions:

• Do these remote controls have names?
• DONE Does anyone have a good quality image of the small remote ?

Got this image from the softsqueeze repository (boom_remote.png)

The smaller remote, need better image

Image from Legacy HTML page

Source:

• Name: Display API
• Legacy URL: LMSSERVER:LMSPORT/html/docs/display.html
• HTML file length: 497 lines
• How current: To be determined

Migration option:

• If current:
  • Page location: Reference -> Development

Legacy HTML Document migration plan

Source:

Name: The SlimProto TCP Protocol

• Legacy URL: LMSSERVER:LMSPORT/html/docs/slimproto.html
• HTML file length: 135 lines
• How current: Not sure.

Migration option:

• Merge this content with other material already in place - for instance existing page at https://lyrion.org/reference/slimproto-protocol/
  --Page location: Reference -> Development

https://forums.slimdevices.com/forum/user-forums/general-discussion/1688262-new-product-name-step-2-the-short-list

@sodface Could you please add a few lines to the CLI documentation, too? Explaining how to use the CLI in JSON mode:

https://github.com/LMS-Community/lms-community.github.io/blob/main/docs/reference/cli/introduction.md
https://github.com/LMS-Community/lms-community.github.io/blob/main/docs/reference/cli/using-the-cli.md

Originally posted by @michaelherger in LMS-Community/slimserver#1146 (comment)

Legacy HTML Document migration plan

Source:

• Name: Remote Streaming
• Legacy URL: LMSSERVER:LMSPORT/html/docs/remotestreaming.html
• HTML file length: 21 lines
• How current: looks ok?

Migration:

• Migration option: Migrate to new page
• Page location: Players & Controllers -> Software Based
• Page title: Remote Streaming

Assignment: @Daksol volunteers

Following up brief earlier discussion.

Standard mkdocs-material stylesheet only has vertical borders for the far-left and far-right, not for internal borders.

Given quite complex nature of much of what we are presenting, I think we need to give the future consumer of this info as much help as we can - even at the risk of not following a minimalist-chique.

I found this blog post from Alex Kretzschmar with CSS which claims it makes mkdocs tables look like GitHub tables. Explains things quite well.
https://blog.ktz.me/making-mkdocs-tables-look-like-github-markdown-tables/

Instructions in this comment explain how to add this to a local setup if you want to see this up-close.

Formatting example is from the musicfolder command for CLI Database commands
https://lyrion.org/reference/cli/database/#musicfolder

It looks ok to me - I also looked at it in Dark Mode.
Only negative - the rows with merged cells have a slightly thicker far right border than regular cells in the far right column. I doubt anyone would notice that if not looking for it.

WITH ADDITIONAL CSS

OUT-OF-BOX

To see this in your own local setup**

• Add these two lines to mkdocs.yml

  extra_css:`
        stylesheets/tableformattingtest.css

• Copy this code and save it as .../docs/stylesheets/tableformattingtest.css

th, td {
   border: 1px solid var(--md-typeset-table-color);
   border-spacing: 0;
   border-bottom: none;
   border-left: none;
   border-top: none;
}

.md-typeset__table {
   line-height: 1;
}

.md-typeset__table table:not([class]) {
   font-size: .74rem;
   border-right: none;
}

.md-typeset__table table:not([class]) td,
.md-typeset__table table:not([class]) th {
   padding: 9px;
}

/* light mode alternating table bg colors */
.md-typeset__table tr:nth-child(2n) {
   background-color: #f8f8f8;
}

/* dark mode alternating table bg colors */
[data-md-color-scheme="slate"] .md-typeset__table tr:nth-child(2n) {
   background-color: hsla(var(--md-hue),25%,25%,1)
}

Source:

• Name (link label): The Logitech Media Server Remote Control
• Name (HTML page title): Logitech Media Server Web Interface
• Legacy URL: LMSSERVER:LMSPORT/html/docs/http.html
• HTML file length: 165 lines
• How current: To be determined

Migration option:

• if current
  • Add into reference -> development -> CLI section

Comment: This seems to be another method of invoking the CLI functionality. It has an entire section on "CSRF Security Measures" about cross site request forgery.

Source:

• Name: Font Files
• Legacy URL: LMSSERVER:LMSPORT/html/docs/fonts.html
• HTML file length: 58 lines
• How current: To be determined

Migration option:

• If current:
  • Page location: Reference -> Development

In the LMS bundled documentation there are references to JiveLite, Squeezelite and SqueezePlay forum posts (see Help > SoftSqueeze). It would be nice to add pages for those projects to lyrion.org so we can replace the links in the bundled docs to here.

Some questions remain:

• Is this site the best place to maintain information about these projects?
• How do we keep the information about those projects up-to-date? On a forum thread you can update information by posting a new post, which has the upside that it is very easy to keep up-to-date, but has the downside that a new user can't find the latest state of a project easily.

Hi!
When I add a favorit by enter URL address I am not able to upload Icon for the station

I like to have

Please advise!

Source:

Name: The Logitech Media Server xPL Interface xpl.html
Legacy URL: LMSSERVER:LMSPORT/html/docs/xpl.html
HTML file length: 43 lines
How current: Probably obsolete?
Other info: legacy wiki page https://wiki.slimdevices.com/index.php/XPL.html
External info: https://xplproject.org.uk/ Not sure if this is the entire project, but last blog post from c. 2016 says that this project is now closed.

Migration option: to be determined

This issue has been raised in order to develop a mechanism which will reliably link CLI Commands to their underlying implmementation in the Perl Source. Several threads in Developer Forums showed interest for this.

Purpose of this Comment is to indicate direction this is taking, and request assistance with the CLI command exceptions where no obvious xref vs source is available.

Preparatory info gathering actions include:

• AAA Find Source xrefs for Notifications CLI commands where some info included in Request.pm, but that info does not include Source xref
• BBB Find Source xrefs for the CLI commands mentioned in Documentation but without info in Request.pm)
• CCC Review CLI commands included in Request.pm but not mentioned in documentation

Second stage will be to create some functionality which will (for minimal effort) keep these cross-references in line. Functionality may be automated - for instance by running a regular query thru source code. Will be amplified in future comment.

Relating CLI Commands to Source

Happily there is a ready source of information for maybe 90% of CLI commands, sub init{} on Request.pm.

Info on Request.pm

• See source file ../Slim/Control/Request.pm
• Within that file locate sub init{} (starts about line 450) which consists of a number of calls of addDispatch() which populates the Dispatch database on LMS startup.
• Commands in sub init{} are divided into two groups.
  • The main block which provides excellent xref vs source - example line
    addDispatch(['player', 'uuid', '_IDorIndex', '?'], [0, 1, 0, \&Slim::Control::Queries::playerXQuery]);
  • The "Notifications" commands where there is an addDispatch function call for each CLI command, but which does NOT include a reference to the source and related function - example line
    addDispatch(['playlist', 'newsong'], [1, 0, 0, undef]);
• Question - AAA - where can we find info on these Notifications commands?

CLI Commands in documentation but NOT on Request.pm

• Note though that there are further CLI commands covered in the CLI Documentation which are NOT included in sub init{}. These include:-
  • Mentioned in General - reference/cli/general.md
    • can
    • exit
    • listen
    • login
    • subscribe
  • Mentioned in Notifications - reference/cli/notifications.md
    • favorites changes
    • getexternalvolumeinfo
• Question - BBB - where can we find info on these commands?
  • Is there a separate mechanism here to get them into the system? I searched code base but did not locate more addDispatch() type function calls,

Commands mentioned in Request.pm with a line in sub init{}, but not in documentation

• Question - CCC - are these all current, not deprecated? Any place where there may be documentation on these?

  • which section do they belong in (General, Notifications, Players, Database, Notifications, Alarms, Compound Queries)

• Commands in main block of sub init{}

  • artwork - addDispatch(['artwork', '_artworkid'], [0, 0, 0, \&Slim::Control::Queries::showArtwork]);
    • Note that there is a command artworkspec included in General CLI
    • artwork is mentioned in Database comment section in Request.pm
  • contextmenu - addDispatch(['contextmenu', '_index', '_quantity'], [1, 1, 1, \&Slim::Control::Queries::contextMenuQuery]);
  • rating - addDispatch(['rating', '_item', '?'], [0, 1, 0, \&Slim::Control::Commands::ratingCommand]);
    • rating is mentioned in Database comment section in Request.pm
  • rating - addDispatch(['rating', '_item', '_rating'], [0, 0, 0, \&Slim::Control::Commands::ratingCommand]);
    • rating is mentioned in Database comment section in Request.pm
  • works - addDispatch(['works', '_index', '_quantity'], [0, 1, 1, \&Slim::Control::Queries::worksQuery]);

Commands in Notifictions block of sub init{}

• displaynotify - addDispatch(['displaynotify', '_type', '_parts', '_duration'], [1, 0, 0, undef]);
• fwdownloaded - addDispatch(['fwdownloaded', '_machine'], [0, 0, 0, undef]);
• newmetadata - addDispatch(['newmetadata'], [1, 0, 0, undef]);

Legacy HTML Document migration plan

Source:

• Name: Squeezebox Radio & Logitech Media Server 8+
• Legacy URL: LMSSERVER:LMSPORT/html/docs/ radio-compatability.html
• HTML file length: 12 lines
• How current: looks ok. Info about how certain versions of Firmware for certain Logitech Devices work with different versions of LMS

Migration option:

• Merge this content with other material already in place.
• Page location: Players & Controllers -> Hardware Based

Text of existing page

Squeezebox Radio/Touch/Controller and Logitech Media Server 8+
Unfortunately some firmwares for Squeezebox Radio, Touch, and Controller come with a bug which prevents them from connecting correctly to Logitech Media Server 8+. The version string comparison function fails to recognize 8.0.0 as more recent than 7.7.3. While the bug has been fixed years ago in version 7.8, the fixed firmware never got released to all devices. Unfortunately we're at this point not able to build a fixed firmware for distribution.

But there's a patch available, which you can easily install on an existing Squeezebox Radio/Touch/Controller:

* On the Squeezebox go to Settings/Advanced/Applet Installer, install the Patch Installer. The device will re-boot.

* Once it's back, go to Settings/Advanced/Patch Installer and install the "Version Comparison Fix".

* When done patching all your devices you might need to restart Logitech Media Server to make the warning go away.

Enjoy the music on your Squeezebox Radio/Touch/Controller!

Legacy HTML Document migration plan

Source:

• Name: Artwork Setup
• Legacy URL: LMSSERVER:LMSPORT/html/docs/artwork.html
• HTML file length: 73 lines
• How current: looks ok?

Migration option:

• Migrate to new page
• Page location: Geting Started with LMS -> Advanced Guides

Assignment

• @Daksol will do this migration

In your instructions for building a new Image with the macros module included, it might be useful to mention that there is an essential period character at the end of that line. The period char is there in the notes, but easy to miss!!

docker build -t squidfunk/mkdocs-material .

Good trap for the unwary otherwise - the error message ERROR: "docker buildx build" requires exactly 1 argument. is pretty unhelpful if you leave the period character out.