holografik wrote: ↑Wed Feb 19, 2020 8:02 pm
That is what I did. It was very simple to add the the SUBSCRIBE processing. Annnnnd ... drum roll ...
it worked.
That's
great news, very well done
holografik wrote: ↑Wed Feb 19, 2020 8:02 pm
I'd like to submit a PR in order to get a fix into the official releases (eventually). I created a local branch off of master at
ceb7ec312fed15f95a5db8ceafc4e852b39106f7. Is there any more to the process for this? I haven't yet looked for dev process doc.
I'm not sure exactly how much documentation exists, but I fear not very much. That said, the "standard GitHub" process is used. That means: Fork UMS to your own GitHub account (do you have one?), create a branch in your fork (or just push the one you've made locally to your fork), then create a PR from your fork to the "master" repo/UMS. Others can then comment, request changes and/or approve the PR. You can push new commits to this branch, and the PR will be updated - you can even rebase and force-push to replace the entire PR/clean up commits. There's really not more to it than that. Try to make sensible commits and sensible commit messages, so that it will make sense to someone looking at the history in.. 5 years
I feel a bit stupid trying to explain things you might already know perfectly well, so it's better if you tell me what you do and don't know, and I can try to fill in.
holografik wrote: ↑Wed Feb 19, 2020 8:02 pm
In the 4311 descriptor document, there's an attribute at the
device node. It's
ms:X_MS_SupportsWMDRM, and it's set to
true. I suspect that this attribute indicates whether the device will require the presence of an MediaReceiverRegistrar service. I looked into the possibility of detection of this attribute, but the parsing of descriptor xml is buried deeply in
cling. Modification of cling document parsing doesn't appear to be easy. I'm sure the code base custodians would regard such a change more warily. And the change would be for something which kind of breaks the schema of the descriptor document.
Cling is currently unmaintained/looking for a new maintainer, so it's extremely unlikely to be able to modify it at this point. That said, it's often possible to use some creative subclassing and possibly reflection to "modify" library behavior, but it gets messy pretty fast. Any changes that breaks standard UPnP compliance probably wouldn't be accepted anyway.
That said, it might be more ways to do this - like getting a "hook" in somewhere to get hold of the raw document and parse it for this purpose outside of Cling for example. But, I'm wondering if this is at all a viable approach. It's a bit of a "the chicken and the egg" situation, in that we have to assume that we get the renderer's description
before it gets ours (because we need to modify ours based on its). This isn't the way UPnP is supposed to work, the whole idea of modifying the description based on the recipient that UMS already does, is a hack. But, to "get away" with such a hack, you need to be able to decide to apply the hack with just very basic information about the other party.
UMS will often get the first HTTP request (usually for the description) before "Cling has disovered" the renderer, which is why UMS has a "dual detection" based either on HTTP headers or UPnP details. It's a flawed logic in any ways, but it's still tricky to get out of because the order of events is unpredictable.
holografik wrote: ↑Wed Feb 19, 2020 8:02 pm
I -do- want to avoid the hack of having to include the phrase 'XBOX 360' in the rendererName, so I'm going to look into the addition of a configuration variable. Perhaps something like, 'emulateWMDRM', or 'provideWMDRMAuth', or ... ?
The usual way to handle this in UMS is to add another option in RendererConfiguration. This option could then be set in any renderer configuration that would need it, and the existing "XBOX 360" hardcoded logic could probably also be migrated to this, making sure that the option is set in the Xbox 360 configuration.
The question that comes to my mind is why one would need to hide the "service" at all. I would assume that renderers that's not interested in a particular service simply disregards it, so that it could be exposed to all renderers. But, there are so many strange renderer implementations out there, that chances are that some will try to subscribe even to services they don't know or simply be confused by services they don't expect. I don't know, but it must be a reason why other servers have chosen to make this configurable. To me the natural thing, and I think the idea behind UPnP, is that the server simply lists all the services is supports, and then the clients make use of those that are of interest to it.
holografik wrote: ↑Wed Feb 19, 2020 8:02 pm
Any suggestions on how to proceed would be greatly appreciated. The goal is to get the solution incorporated into master in a timely fashion.
I've tried to give my inputs above, if you ask specific questions about what you want to know, I will try to give specific answers.