UniversalMediaServer
UniversalMediaServer copied to clipboard
Assign account not saving
If I assign an account to VLC, it says it saved it, but there is still no account assigned
When I change it, my logs say:
Renderer User: No change made, 2fba0240-ab15-3a98-ac08-e096935480de is already linked to userId 3
and the UMS.conf entry confirms that, but that does not change the display of "No account assigned"
@SurfaceS any ideas? This stops me from being able to use the content filtering feature
This is still happening in latest main 39e8c47
@SubJunk I'll need the logs.
Having a very similar issue from the version that brought the sharing filtering feature. I will post logs later on, but in my case it is happening only on one renderer and on an account that has more sharing points than the others. The account is never saved, but the greenish success message appears if doing so. Also, I cannot set the account above, if I haven't set it to another account first and then back to the desired one.
I have this too but it will not allow you to assign the admin account to some devices but will set to other accounts. However this is lost on restarting.
This does not effect every renderer though.
My PS4 will not allow me to set my main account but my TV will and that is saved.
looking at the logs if a renderer is unassigned "userId=-1" then assigned to admin "userId=1" it will say it is already linked
Finding user id: -1
Renderer User: No change made, 0c9aa9fd-d117-363c-bffe-c20c14178780 is already linked to userId 1
but any other user it works and allows to select user 1 afterwards
Renderer User: linking renderer 0c9aa9fd-d117-363c-bffe-c20c14178780 to userId 2
Renderer User: linking renderer 0c9aa9fd-d117-363c-bffe-c20c14178780 to userId 1
Selecting default user causes an error but does set to it.
ERROR 2025-05-19 14:47:56.539 [webgui-server-128] Renderer User: trying to link renderer 0c9aa9fd-d117-363c-bffe-c20c14178780 to inexistant userId 0
https://github.com/user-attachments/assets/07cfc9ae-604a-494f-8411-3cbeb686ec89
What is the purpose if default account? Should all renderers that are unassigned be this default account instead of having "no account assigned"
Edit:
I thought this was stored in the users database but just discovered it is stored in UMS.conf
If I comment out renderers_user it will allow me to link a renderer to user 1 first time but still does not come in effect even though it is saving this. This could be why it was saying user already linked.
The TV linking does always work and I have tried changing the order when linking but makes no difference.
Something about the UUID of my PS4 is breaking things and is not being applied to a user.
This first one is the PS4 and second my TV.
renderers_user = {|0c9aa9fd-d117-363c-bffe-c20c14178780|:1,|0c845881-00d2-1000-9438-f47b5ebe1def|:1}
I was debugging this yesterday too and got the same experience. Some are saving and others aren't. Thanks for the extra info. I'll look into it more today
There are a few files for renderers and it looks like they don't quite connect together - the user is being set in one file (RendererItem), but that reference isn't updated in the other file. I have a workaround for it already which is working but I'm trying to do a nicer fix
Using my issue mentioned above, in version 14.13.0 -visually, the account is correct preselected for the device BUT it is not been used/utilized by the device's app, even after reloading for available folders for this device. So, basically to fix the issue, another half step is needed. Thanks for tackle this issue
@timiman thanks for the message. The fix for that is in the release that is in the process of rolling out now, 14.13.0
My mistake. I meant version 14.13.0.
I see, can you please let me know exact replication steps? I thought it was working for me
I see, can you please let me know exact replication steps? I thought it was working for me
I'm away so I cannot send you fresh api responses or logs from v1/api/renderers/ . I only have the last one before leaving home, so it might not be a broken one to help you more. This last response has correct bindings between users and renderers entities:
"renderers": [
{
"id": 9,
"name": "BubbleUPnP",
"address": "____",
"uuid": "_____________________________________",
"icon": "BubbleUPnP-MXPlayer.png",
"iconOverlays": "",
"playing": "",
"time": null,
"progressPercent": 0,
"userId": 34,
"state": {
"playback": 0,
"mute": false,
"volume": 0,
"position": "",
"duration": "",
"buffer": 0,
"name": " "
},
"isActive": true,
"isAllowed": true,
"isAuthenticated": false,
"controls": 0
},
...
...
"users": [
{
"value": 33,
"label": "TV user"
},
{
"value": 1,
"label": "admin"
},
{
"value": 34,
"label": "Timi"
}
],
The steps to follow are:
- "Restart server" from webui
- Try to connect from playback device
- No available shared folders in DNLA app on device
- On UMS webui the device IS visible and the correct account IS pre-selected -"Timi"
- Change the account of the device to other than the correct -ex. "TV user", save and then back to "Timi" and save again
- Back to device, reload for available shared folders and they now appear as they should if using the "Timi" account
I don't know if it helps, but between step 2 to 5 I see the logs of:
07:55:20 INFO Finding user id: -1
07:55:44 INFO Listing all users
07:55:48 INFO Listing all users
07:55:54 INFO Listing all users
So, it is correctly binding renderer and account -at least webui-wise, but not truly using it.
That's very helpful, thanks. I will investigate more soon
I noticed this on the V15 alpha too but thought this had not been merged yet, same with the cache and thumbnail issue.
The correct user is assigned in the settings and is saving but the played status is not being used. If marked as played on the web player it does not show as played in the renderer. I have not tried if access control works or not though.
I have been focusing on our infrastructure and API lately but I will take a break to fix this since I think it's important. Starting on that now
I spent some time on it today and it looks like the problem is that some renderers are not assigned their UUID until after their root folder is populated. So the logic goes:
- Found renderer via browse request
- See what folders it has access to with UUID=null
- All group-scoped folders are not granted access, because null does not match any UUID and therefore the checks for user and group permissions also return false to be safe
So the next time I or someone looks at it, we need to see why the UUID is not there at that stage. I am using VLC on iPhone for the testing
@SubJunk Again this topic :) For this specific issue you might want to check out or merge #4886? Maybe it helps, since it put's the control point UUID to the "known renderer" list.
Please keep in mind, that according to the UPnP Av architecture a control point is the only component that initiates UPnP actions. Therefore, you will only identify a control point in step 1. In case of a combo device (TV, VLC, etc.) accessing UMS, step 1 might also identify an in the future visible renderer, in case the control point and the renderer use the same UUID (encouraged, but not guaranteed). There is still a design weakness in UMS.
@ik666 I have fixed the case that I can reproduce and requested your review please https://github.com/UniversalMediaServer/UniversalMediaServer/pull/5655
If anyone in this issue wants me to build the fix for them to run, let me know :)
Using latest 15.0.0 I still have the same issue of showing the correct account on the device in UI, but it is not really bind in the background, as it does not show any shared folders as it should be showing. Again, setting/saving to another account and back again to the correct one makes it work as it should be.
@timiman thanks for your comment, I made a new issue for that at https://github.com/UniversalMediaServer/UniversalMediaServer/issues/5749
@timiman Do you have a 3-box setup? Looks like you're using BubbleUPnP as a control point and MX-Player as a renderer?
I'm using BubbleUPnP as a control point and VLC as a renderer on a mobile device.