UPNP OpenHome renderer: Remember Playlist / Queue after reboot

[the_bertrum]

I suspect there is a moOde bug here where in certain circumstances the UI says OpenHome, but upmpdcli is not actually set that way. Problem is that the "certain circumstances" in question are not known. Could be after an in-place upgrade, or may be a restore from backup?

I'll try to remember to check this periodically to see if I can find what the trigger is.

[Fermion]

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.

[the_bertrum]

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.

[Tim Curtis]

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);
        }],

[the_bertrum]

OK, from a player I haven't touched the UPnP on for a while:

Code:

master@apollo:~ $ pgrep upmpdcli && cat /etc/upmpdcli.conf | grep "upnpav\|openhome"
1304
upnpav = 1
openhome = 0

 Yet in the UI:

   

And the cover art and queue are borked, and BubbleUPnP does not show the renderer as being OpenHome.

This player was the recipient of an in-place update at the last release, maybe that's the process that breaks it?

[the_bertrum]

Pressing "save" on the setting page sorts it out:

Code:

master@apollo:~ $ pgrep upmpdcli && cat /etc/upmpdcli.conf | grep "upnpav\|openhome"
1052545
upnpav = 0
openhome = 1

[Tim Curtis]

OK, from a player I haven't touched the UPnP on for a while:

Code:

master@apollo:~ $ pgrep upmpdcli && cat /etc/upmpdcli.conf | grep "upnpav\|openhome"
1304
upnpav = 1
openhome = 0

 Yet in the UI:



And the cover art and queue are borked, and BubbleUPnP does not show the renderer as being OpenHome.

This player was the recipient of an in-place update at the last release, maybe that's the process that breaks it?

Can never rule out bugs in the in-place update. Your result would indicate the upmpdcli.conf file has been changed while the cfg_upnp SQL table has not and has the correct setting.

I don't see anything explicit in the in-place update script that alters upmpdcli.conf but I'll add to the TODO list to investigate.

[the_bertrum]

The in-place update could also be a red-herring. I have no evidence that says what combination of events left my players in this state.
Sufficient for me is that when moOde is really using OpenHome, it all works correctly and pressing "save" once to fix it in situations where it isn't working is no biggie.

[bsergiu]

Hi @Fermion ,

Thanks for the reply and the updates. Indeed, I am not using OpenHome. Just MPD+upmpdcli , no OpenHome mode.

Enjoy the music!