My goal was to change the name that was advertised for Airplay, since I didn’t think “rpi” read very well. I should mention that I’m using the stock Kodi skin and not the OSMC skin, in case there are substantial differences in this context.
I experienced three distinct problems trying to change the Airplay service name:
I changed from “rpi” to “Raspberry Pi” as the device name in Kodi Settings → Services. After changing it, the Airplay service name still did not change, so I restarted Kodi. But instead of applying my new name it reverted back to the old name. I received no feedback that anything had gone wrong after I had input my new device name (input was made through web interface for easy typing).
Workaround: I could discover the problem by using the switch right below the device name text field, “announce services to other systems”. Throwing that switch gives an error message saying it can’t be disabled because it’s currently used by Airplay. After disabling Airplay I could then change the device name.
After having confirmed that the Airplay service was now broadcast as “Raspberry Pi” instead of “rpi” I was satisfied. Then I restarted the system. After a restart, the Airplay name had lost all whitespace, turning into “RaspberryPi”, which was not expected.
The entire system became unreachable using the rpi.local hostname, and started using RaspberryPi.local instead. I did not find it obvious that this would happen, and it took some time to figure out what had happened.
The solution to the above problems is to not conflate “device name” and “host name”, since the former concept is a user facing string while the latter is constrained by various rules. For instance, macOS generates a valid hostname from the device name, but doesn’t attempt to change the device name to meet the constraints of the hostname, which would have the undesirable result of propagating the constraints of one subsystem into other subsystems that don’t have those constraints (like how OSMC currently constrains Airplay’s service names to being valid mDNS hostnames).
I think user facing strings, like Airplay service names, should reasonably be decoupled from the mDNS hostname, which is why I think the “device name” field needs new semantics.
It is intentional on OSMC that changes to ‘services.devicename’ cause a change to the contents of /etc/hostname. Users in the past have been confused why the system hostname is not changed when changing this option in Kodi, particularly as there is a system hostname prompt during the initial setup process.
It doesn’t make sense and leads to confusion if we offer two separate dialogues for ‘device name’ and it would not be easy to convey to users that one device name is used for mDNS and some APIs that Kodi clients can consume; and another is used for system services such as Samba and SSH that can be consumed by other clients.
If you want a separate hostname from Kodi’s device name, then sudo chattr +i /etc/hostname.
Relying on local lookups like this is notoriously unreliable, and many consumer routers will not transmit broadcasts across different mediums, i.e. Wired to WiFi.
I described the difficulties it caused from a usability perspective. Do actual difficulties due to unclear concepts not qualify as a problem?
Of course the users you describe are confused by that: they’re not offered anything other than the “device name” field as a means to change a “hostname” property that they were previously introduced to but now cannot find anywhere. What else can they do other than to expect that? I know I would expect that too in that situation — but we’re not all fresh out of the setup process. In fact, I’d say that 99% of the time we’re not.
This is still conflating “hostname” with “device name”. They’re just not the same thing, which is the root of the usability problems that I described.
I do not propose two “device name” fields, but I do propose clearly separate concepts: device name + mDNS hostname. The latter is derived from the former. The former is not silently edited to conform with the latter, however — unlike what happens currently. This is not a confusion problem for users who can’t tell the difference between the two things since there are several levels of visibility for settings depending on how advanced the user wants to go, i.e. “hostname” doesn’t even have to be an editable property for most users.
As for easily conveying it to users, how about mentioning it? For instance: “The address to this OSMC device is ‘your-device-name-converted-to-a-hostname.local’”. I think explicitly mentioning the address to the very users who are confused by the difference between “device name” and “hostname” is an improvement over just assuming that the same users will understand that they can reach the device by adding .local to their device name. A device name that can magically edit itself between reboots, might I mention. An explicitly mentioned address that is slightly different is superior to an implicit unmentioned verbatim address that the user might not even know exists.
As for other services, they’re of course all free to put arbitrary constraints on their names, but that doesn’t change what the user actually wants to call his device. If some services try to raise the bar and respect the user in that regard by offering free-form names — like Airplay does — then it’s just good design to use the closest form of the device’s name as the name for that particular service. Thus the need to separate the concepts.
Self-announcing services, like Airplay, can be presented to the user through a list of available services, i.e. the user isn’t required to juggle those service names and addresses manually. That significantly reduces the problem that the device name might have been slightly altered to conform with the particular constraints that these services put on their names, e.g. “no-whitespace-allowed” is still easily identifiable by the user. This makes a case for using a free-form device name as a source for the names of those services.
Thank you, it’s kind of you to provide a workaround. I will try it out.
But I wrote this rationale hoping to help improve OSMC.
I appreciate the advice, that’s good to know. However I think this issue could move forward more easily if we focus on the problem described with OSMC; I personally have found local mDNS lookups very reliable, and I have no complaints with it. It is the unexpected behavior of OSMC that is the root cause of the problem in this case.
I believe that is an exaggeration, but even so it wouldn’t exactly be strange that OSMC users think it’s the same thing when OSMC itself is conflating the two. OSMC, the software, actually plays a role here. I even went to great lengths to describe how I, as an OSMC user, was bitten by the vagueness of the property “device name”. It literally changes itself as a result of its identity crisis; it asks me to freely name my device to my liking, just to turn around the next second and edit itself to its liking. It’s a clear indication of something trying to be multiple things at once.
They are not the same thing in the sense that asking a user for a “device name” is to ask the user to freely name his device, i.e. a free-form user-facing string that should let the user name his device to his liking, without imposing arbitrary constraints whose roots lie in implementation details (like which service allows what characters). That is not the case with e.g. a mDNS hostname, which has several constraints put on it and which cannot represent what the user wants his device to be called. Plumbing - porcelain.
The user controls the device name.
Services, e.g. mDNS, control their service names. If the user wants whitespace in his .local-address — too bad for the user, because mDNS says no.
My device’s name is not “RaspberryPi” if I’ve named it “Raspberry Pi”. That’s just fact. And if an edit to the device name somehow changes my .local address (a separate concept) then I need to be made aware of it, and not be assumed to just know that. My device name is a source of truth for all other service names to be derived from, in a best effort manner.
After re-reading this, I think there might be some confusion.
This is not correct. The Kodi device name does not determine the mDNS broadcast hostname by default. It does with our downstream patches.
The Avahi daemon runs as an OSMC system service, based on the system hostname. Kodi chooses to publish some services using the device name setting’s value. Our patch ensures that the device name setting in Kodi always reflects the system hostname, thereby unifying it so that all services which utilise mDNS broadcasting have a consistent naming scheme.
Without this patch, you actually have:
Kodi services that use mDNS announcements have their own naming scheme
System services that use mDNS announcements have their own naming scheme devolved from hostname
With our patch, you have a consistent naming scheme regardless of where the announcement has originated from. If I give my living room Vero the name ‘LivingRoom’, I would expect Samba, FTP and AirPlay to all have a consistent naming scheme.
Because:
It doesn’t do that
mDNS does not work reliably on consumer networks and is best avoided for hostname resolution
This is not correct. Any changes to the device name in Kodi are instantly reflected via the system hostname. A reboot is not needed to propagate these changes.
Then there should arguably be a separate name option for AirPlay in Kodi’s settings.
Ironically, this is why we have a unified naming scheme across services and hostname.
It’s a proposition. It’s correct as long as it corresponds to what I’m proposing. If you mean incorrect as in it doesn’t describe how OSMC or Kodi works currently then yes, I guess. Sorry if I was unclear.
I’m writing from the perspective of OSMC as a cohesive system, and I’m assuming I’m actually running these downstream patches you mention if I’m running OSMC, so I don’t see any need to talk about what Kodi does when Kodi is run outside the context of OSMC.
Thank you for the explanation.
Also, I apologise if I caused some unnecessary confusion by my use of the term hostname. I intended it as the host part of a URL in my examples, but I was not clear about that.
I see. You are describing a situation that was worse off before and is better now. That’s good, but in my eyes that does not automatically invalidate potential future improvements in the same area. This would be such an improvement.
I agree that that’s a reasonable expectation. And if I give my device the name “Raspberry Pi” I would expect the device to be named “Raspberry Pi”. I think my expectation is, if anything, even less far-fetched. “RaspberryPi” does not equal “Raspberry Pi”.
“RaspberryPi” is however close enough that I would still accept the name as consistent with my device’s real name of “Raspberry Pi”, and perfectly identifiable anywhere I saw it. Conversely, if this constrained and altered device name were forced upon all my services just because a subset of services (or the OS hostname) can’t handle whitespace in a string, then I would not find it as acceptable. Especially if it starts interfering with and editing what I’ve already submitted as my device’s name.
If I understand you correctly, a few service names are constrained by the constraints placed on the OS hostname that they use as their source, and you’re right that I did not think about the OS hostname when writing, but that’s still an implementation detail that I don’t think should be any reason to dismiss this as a problem. Ok, so it’s actually the OS hostname that unexpectedly constrains the device name – it’s the same result.
I am fully open to that some things are impossible to implement, but so far I’ve mainly felt the reaction “how is this a problem?” which is the level I’ve tried to stay at. Implementation details, sure, that’s unquestionably your area of expertise, and if you decide it’s impossible, fine. I’m not trying to prescribe the exact mechanisms used to accomplish what I’m describing as a possible solution, but I interpreted the situation as that you did not see the problem.
What doesn’t it do? Set up a .local address? Ok, I see, sorry about the confusion. Bad choice of example by me.
Got it. I’m completely fine with OSMC not setting that up by default, of course. You provide a good rationale for not doing it.
mDNS was just a service I used as an example. It would be equally effective to tell users about the other services that OSMC does expose, if their service names are meant to be typed by hand, or if they differ significantly from the kind of free-form device name that I’m proposing and from which they should reasonably be derived.
Well, I’ve already given you a fairly detailed description of it happening to me. I don’t know if I can do much more than that. I don’t know why you don’t believe me.
It literally accepts “Raspberry Pi” as a device name. I activate Airplay, and it broadcasts “Raspberry Pi” to Airplay capable devices. I was happy with that. I then relaunch Kodi and my device name is changed to either “RaspberryPi” or, last time I tried, got reset to its previous name “rpi”.
I don’t claim that a reboot is necessary to edit the device name or to apply it, just that the name changes itself after a reboot of OS/relaunch of Kodi. After accepting the name I gave it. As I wrote in the initail post there were three distinct problems, of which this is one
Yes, that is an excellent alternative solution that will solve the problem – but only for Airplay. My proposed solution was intended to solve it for all services that are aiming a bit higher with their UX, but I suppose that that can wait if Airplay is in fact the only service that gives the user these basic freedoms with naming (i.e. allowing whitespace, special characters, etc).
I agree that there should be consistency, and if some services (or the OS hostname) can’t help but require altering the device name slightly to work – be it by removing whitespace, or replacing it with hyphens – doesn’t mean that other services shouldn’t be able to publish exactly what the user really intends his device to be called, which should be represented by the device’s name.
I’m happy to accept a PR to improve this behaviour so that spaces can be used where possible. But this may be tricky, and even get us back to where we started, because hostnames do not support spaces.
The problem with such a PR though, is it restores the original behaviour and would give us the opposite of a ‘consistent name’.
If this is a problem, your suggestion certainly doesn’t solve it. It just makes the scenario painfully more complicated. You would then cause fragmentation of the naming of services between Kodi provisioned announcements; system announcments and the hostname itself.
So for ‘Living Room’ as my device name in Kodi, I have:
LivingRoom.local (assuming Avahi is working) for referencing a port, such as HTTP
= wlp2s0 IPv4 LivingRoom SFTP File Transfer local (for system services such as SFTP).
And currently, without those changes, I have LivingRoom as a single reference for all of these services.
It won’t. You can look at the code and see that it is immediate.
To achieve this would require serious effort. If someone wants to spend time working on it, then I’m happy to review it. Personally, I’m not bothered about a single space in the name of an advertised service. I still know that “LivingRoom” is in fact, the system in my living room.
I think you need to rethink this. You’ve already been given a solution if you wish to use a different hostname to device name.
Ok, that’s more than I know about. I guess I was under the impression that you were in control of the entire system. I didn’t imagine that introducing a new variable with new semantics would invariably cause things to break down. I don’t know exactly what can and can’t be done with OSMC.
If you say so. I can’t really add much to that since I don’t know any implementation details or how those names are generated, but they’re clearly not being generated into anything pretty.
I only know that when I put “Raspberry Pi” as my device name in Kodi I get “Raspberry Pi” for Airplay and that it doesn’t look like what you’ve listed. Perhaps there’s something wrong with my installation there.
Good one
Jokes aside, no, I actually look at the results I get on screen when testing things. It’s generally a bit quicker and more accurate than running code in my head.
I don’t doubt the code looks exactly as you describe, and I don’t doubt that my results are as I described.
Though I don’t recall saying that something isn’t applied immediately. In fact, I explicitlty agreed that I’m not opposing that claim. I did describe a perceived bug of how I needed to disable Airplay before the device name would stick between reboots, with no error messages to help me figure that out. Other than that I’ve only said that it has changed on its own in conjunction with a reboot. Same bug? Yeah, why not? I don’t know.
Perhaps the change is immediate but the UI doesn’t tell me. Doesn’t matter which – still a problem.
Ok, thanks for the offer, good to know. It’s your call.
Though to be honest I kind of didn’t write this problem description for you or for any particular team member. It was intended to reflect a problem I experienced, and I thought a thorough rationale other than “why not” would count towards having it recognized as a problem.
I don’t think there’s anything to rethink about a problem description and a feature request. They just are. You don’t have to do anything if you don’t want to.
