Home of the Squeezebox™ & Transporter® network music players.
Page 3 of 3 FirstFirst 123
Results 21 to 29 of 29
  1. #21
    Senior Member
    Join Date
    Sep 2005
    Posts
    2,788
    Quote Originally Posted by Paul Webster View Post
    My understanding - if you launch the player with a -N filename where the named local file has a player name in it then that is the name that the player will give to LMS when it connects.
    If you then change the name of the player from LMS web interface (etc) then LMS will tell the player itĺs new name and the player should store it back into the named local file.
    [OT]
    The only reason to use this feature is more than one lms and always rename the playernames..?
    [/OT]
    Thanks

  2. #22
    Senior Member
    Join Date
    Apr 2005
    Location
    UK/London
    Posts
    1,275
    plus, as in this case, to get around bugs in some software/scripts that do handle spaces in player names very well.
    Paul Webster
    http://dabdig.blogspot.com
    Author Radio France (FIP etc) plugin

  3. #23
    Senior Member chill's Avatar
    Join Date
    Mar 2007
    Posts
    758
    Quote Originally Posted by ralphy View Post
    I've been using the -N option for ages, well really since Triode added it back in Dec 2013 and I've never noticed that behaviour.
    I usually populate the file with the playername when I first add the -N option and I don't change player names very often.
    Permissions could be the issue updating the -N file if squeezelite is not running as root however squeezelite will log that with an 'unable to store new name in file' warning.
    I'm struggling with this, and it's frustrating, given that it was working when I first tried it.

    @ralphy - that warning message, do I need to enable logging/debugging somehow in squeezelite? Just running it from from a terminal with ...
    Code:
    squeezelite -v -o sysdefault:CARD=MID -N /root/squeezelite/bin/JogglerPlayerName -m 00:0e:8e:24:ce:36
    ... gives me no feedback at all.

    It's definitely taking the startup player name from the file, but name changes in LMS aren't getting back to the file, despite apparently being applied within the LMS interface. I'm running squeezelite as the root user (for now), but I've also tried changing the permissions of the named file to 777, as well as the folder it sits in.

    Any tips to investigate this would be appreciated.

  4. #24
    Senior Member chill's Avatar
    Join Date
    Mar 2007
    Posts
    758
    I found the -d option in squeezelite, and captured some debug information.

    I can see where squeezelite is getting the name from the file, and where it then sets the name immediately afterwards:

    Code:
    root@openframe:~# /root/squeezelite/bin/squeezelite -v -d all=debug -o sysdefault:CARD=MID -N /root/squeezelite/bin/PlayerName -m 00:0e:8e:24:ce:36
    [09:13:04.047426] stream_init:294 init stream
    .
    .
    .
    [09:13:09.275626] discover_server:795 got response from: 192.168.1.46:3483
    [09:13:09.276186] slimproto:858 retrieved name Joggler from /root/squeezelite/bin/PlayerName
    [09:13:09.276556] slimproto:883 connecting to 192.168.1.46:3483
    .
    .
    .
    [09:13:09.319463] process:514 setd
    [09:13:09.319661] sendSETDName:238 set playername: Joggler
    [09:13:09.319806] process:514 setd
    But when I then change the name in LMS there doesn't seem to be any sign of that coming back to squeezelite.

  5. #25
    Senior Member
    Join Date
    Apr 2005
    Location
    UK/London
    Posts
    1,275
    I just had a quick look at bits of code.
    It is the setd slimproto command (as shown in your captured debug info).

    One thing I saw on the LMS side is that this is not sent while the player is active - so try a name change while the player is stopped.
    It looks like it queues up the info to be sent later in that case but I did not work through that to see if it works.

    Also - it is for firmware settings updating ... is there a chance that Squeezelite is not recognised as a device with firmware?
    (I did not check for that)
    Paul Webster
    http://dabdig.blogspot.com
    Author Radio France (FIP etc) plugin

  6. #26
    Senior Member chill's Avatar
    Join Date
    Mar 2007
    Posts
    758
    Quote Originally Posted by Paul Webster View Post
    One thing I saw on the LMS side is that this is not sent while the player is active - so try a name change while the player is stopped.
    It looks like it queues up the info to be sent later in that case but I did not work through that to see if it works.
    Thanks Paul - that could be the key. With Jivelite running on the Joggler I can see the player name at the top of the screen, and this changes almost immediately when I change the name in LMS. But I do think that all my testing has been while squeezelite has been running*, so maybe the command isn't being sent to squeezelite itself. That might explain the 'occasional' success that I had. Will test that this evening.

    * I've been playing with making the Joggler autostart squeezelite at boot if it was running when the Joggler was shut down. I'm finally starting to get my head around lua settings files/menu operation/scripting/greping/awking......

  7. #27
    Senior Member chill's Avatar
    Join Date
    Mar 2007
    Posts
    758
    After a quick test it looks as though you've solved the mystery Paul. Name changes get saved back to the specified file when the player is stopped. It's not enough to pause the player, or to (soft) power it off while playing or paused - it has to be explicitly stopped. Name changes also seem to get saved while the player is (soft) off, provided it was stopped first.

    I can't believe that I didn't spot this pattern in all my testing, but in my defence the browser interface doesn't have 'stop' function that I can see, and it's not obvious in the Jivelite interface - it takes a long press on the pause button to stop the player.

    I wonder if this 'stopped' condition really needs to be present. Paul - could you point me to the relevant bit of the source code and I might have a go at lifting that restriction to see what the consequences are.

  8. #28
    Senior Member
    Join Date
    Apr 2005
    Location
    UK/London
    Posts
    1,275

    Spaces in Player names?

    Slim/Player/Squeezebox2.pm

    Code:
    # Only send a setd packet to the player if it is stopped and we are not
    # still waiting for a response to a previous setd packet for this pref
    if ( $client->controller() && $client->isStopped() && !($status & SETD_WAITING) ) {
    
    my $data = pack('C'.$currpref->{pack}, $currpref->{firmwareid}, $value);
    $client->sendFrame('setd', \$data);
    
    # We are now waiting for a response to this setd call
    $client->pendingPrefChanges()->{$pref} = SETD_WAITING;
    }
    else {
    
    # we can't update the pref's while playing, cache this change for later
    $isInfo && $prefslog->info("Pending change for $pref");
    
    # Mark this pref as pending, will be sent to the player later
    $client->pendingPrefChanges()->{$pref} |= SETD_PENDING;
    }
    }
    I think that an issue with changing it will be verifying the change across the range of devices and situations ... so perhaps if removing the check on being stopped then add other checks that limit which hardware/software players that it will be sent to to include only those that are readily testable.
    Michael probably best advisor on the though.
    Last edited by Paul Webster; 2019-02-18 at 09:35.
    Paul Webster
    http://dabdig.blogspot.com
    Author Radio France (FIP etc) plugin

  9. #29
    Senior Member chill's Avatar
    Join Date
    Mar 2007
    Posts
    758
    Thanks Paul

    Good grief - I wouldn't have the first idea how to code this little workaround. As you say, the consequences on different types of player might be different, and this restriction was obviously put there for a reason. I would guess that the 'setd' doesn't only handle player name changes, so it would be wise to restrict the change such that it only affects 'squeezelite' players, and only refers to name changes. I could see it taking me a week or more just to get to grips with the perl syntax and scratch the surface of the LMS structure. I think I'll just leave it, and live with the fact that squeezelite on the Joggler is behaving as programmed.

    On the other hand, whilst I can understand that it might be best to limit this type of communication while a player is playing, I wonder if it's really necessary for it to be explicitly 'stopped'. It seems like it might be just as safe to send this 'setd' while the player is paused, which is a much more common condition for a software player without a stop button.

    Quote Originally Posted by Paul Webster View Post
    Michael probably best advisor on the though.
    Agreed.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •