Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Set --hostID to stap spamming of client names #19

Closed
abelmatser opened this issue Mar 1, 2021 · 6 comments
Closed

Set --hostID to stap spamming of client names #19

abelmatser opened this issue Mar 1, 2021 · 6 comments
Labels
next release fixed in dev branch, will be included in next release

Comments

@abelmatser
Copy link
Contributor

abelmatser commented Mar 1, 2021

First, thanks for your awesome work! You make Snapcast more accessible to all of us. (Congratulations on the app store release btw!)

It would be nice if we could be able to set the client name of Snap.Net just like I do on dedicated clients:

SNAPCLIENT_OPTS="-h $IP --hostID woonkamer"

I would like to do this to stop the generation of tons of unused snapclient ids as: Desktop-Name # 1, ..., # 15. I get these when I stop and open Snap.Net after restarting the snapserver during troubleshooting.

@stijnvdb88
Copy link
Owner

Hi there, thanks! Have you tried setting the names from within Snap.Net? (it's kind of hidden away, you need to click on the client name to get that dialog)

image

That ends up calling Client.SetName on the server, which is persistent across sessions :) (https://github.com/badaix/snapcast/blob/master/doc/json_rpc_api/v2_0_0.md#clientsetname)

Let me know please if that doesn't work!

@abelmatser
Copy link
Contributor Author

This seems to work, thanks!

@abelmatser
Copy link
Contributor Author

abelmatser commented Mar 4, 2021

I would like to reopen this issue, because even though setting the name is useful, it does not achieve one of the goals I want it to achieve. Home Assistant obtains snapcast clients and names them by their id (media_player.snapcast_client_${ID}). Currently that id (which I believe is set by Snap.Net or automatically deduced by Snapcast) is the mac address of the computer, with an added #number for the index of the instance on that device.

I would like to be able to set the id (or have it be the same as the name), thus replacing the mac address by which it is currently set. If it enforces a unique name with a trailing number that is fine, then at least the client is recognizable by its id.

(Same is true for groups, in which the id is also non-human readable format)

@abelmatser abelmatser reopened this Mar 4, 2021
@stijnvdb88
Copy link
Owner

That makes sense, I didn't realize there were tools using these id's as names :) I'll add a field in the player settings for overriding the host ID. The mac address + instance ID are automatically filled in by snapclient by the way (see https://github.com/badaix/snapcast/blob/master/common/message/hello.hpp#L98), unless an id is explicitly specified via --hostID, as you pointed out before.

@stijnvdb88 stijnvdb88 added the next release fixed in dev branch, will be included in next release label Mar 23, 2021
@abelmatser
Copy link
Contributor Author

abelmatser commented Apr 2, 2021

Thanks for the update, I just tested it and setting the ID works! Thanks for your time 👍

I'm not sure if I want to make an issue of this, but I do have a small one. Currently a trailing number is added to the id, even though the id is unique. In my case a trailing _6 was added, which I believe is because I have around that many output options on my computer, so this was not generated because this ID was non-unique.

I would think this trailing number is unnecessary if one chooses a unique ID.

@stijnvdb88
Copy link
Owner

Thanks for the update! I had a quick look, the issue you're seeing is caused by the --instance parameter being passed. This parameter helps snapserver tell various players apart when they come from the same machine (which under normal circumstances means they all share the same mac address and therefore the same ID). It's fair to assume that an explicit --hostID override means it'll be unique anyway, so --instance can be omitted in this case. Will fix this for the next release :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
next release fixed in dev branch, will be included in next release
Projects
None yet
Development

No branches or pull requests

2 participants