02-29-2024, 12:44 PM
(02-29-2024, 11:57 AM)the_bertrum Wrote:(02-29-2024, 10:52 AM)Fermion Wrote: I would not trust the UI.
You could use the renderer/device info of BubbleUpnp. Devices and the 3 dot menu right to the renderer and select info.
If BubbleUpnp reported "Family: OpenHome" everything is perfect.
Of course you could also check the upmpdcli config file, which I did before. But BubbleUpnp info should be perfectly fine.
That's the whole point though, we should be able to trust the UI to tell us which parameters moOde is using to start upmpdcli with. We know that if moOde is using upmpdcli in OpenHome mode, then it all works as expected. We also know that sometimes, if moOde is set to start upmpdcli in OpenHome we get behaviours consistent with it not being OpenHome.
It is a reasonable hypothesis that in some cases that the setting shown in the moOde UI does not translate into the correct setting in the commands. We need to identify those situations, and verify what happens when they occur.
If, on a non-working system, we see that the moOde UI reports OpenHome, but the config and control points report otherwise, we have one problem. If we find that the moOde UI and the config and control points all report OpenHome as well, then there's s different problem altogether.
One of the challenges with UPnP is that there a lot of moving parts making it difficult to debug, but you are correct that UI settings should always be in sync with corresponding config files.
I ran a quick test changing the UPnP settings and I'm not seeing any issues in the config file. The 4 digit numbers displayed represent the process id's (PID) of upmpdcli. It shows that after a settings change upmpdcli gets restarted and thus gets a new PID.
# Turning on for first time
pi@moode:~ $ pgrep upmpdcli && cat /etc/upmpdcli.conf | grep "upnpav\|openhome"
7895
upnpav = 1
openhome = 0
# Changing to Openhome
pi@moode:~ $ pgrep upmpdcli && cat /etc/upmpdcli.conf | grep "upnpav\|openhome"
8152
upnpav = 0
openhome = 1
# Changing back to AV
pi@moode:~ $ pgrep upmpdcli && cat /etc/upmpdcli.conf | grep "upnpav\|openhome"
8275
upnpav = 1
openhome = 0
I also checked the code in the Backup/Restore module and did not see any issues with the cfg_upnp params other than I prolly need to add the new Qobuz params.
Code:
'UPnP/DLNA',
['requires' => ['upnpsvc'], 'handler' => setphpSession],
['requires' => ['dlnasvc'], 'handler' => setphpSession],
['requires' => ['upnpav'], 'handler' => function($values) {
setDbParams('cfg_upnp', $values);
}, 'custom_write' => function($values) {
return getDbParams('cfg_upnp', $values);
}],
['requires' => ['openhome'], 'handler' => function($values) {
setDbParams('cfg_upnp', $values);
}, 'custom_write' => function($values) {
return getDbParams('cfg_upnp', $values);
}],
['requires' => ['checkcontentformat'], 'handler' => function($values) {
setDbParams('cfg_upnp', $values);
}, 'custom_write' => function($values) {
return getDbParams('cfg_upnp', $values);
}],