MediaMonkey forum

I see a topic that seems related here: https://www.mediamonkey.com/forum/viewt ... p&start=15

In that one the issue is that the groups and their components show separately.

In my case my grouped speakers (I have two groups, and lots of individual minis) are not showing at all, either as components or as the groups.

All the little MINI devices do show. They are on the same subnet as the others, really nothing different about them other than they were put into a group a couple years ago (I mention that as I think Google at some point changed how that is done).

On my android phone if I hit the cast button I see them as groups (not individuals).

In MM5 (5.0.4.2690, portable install, standard, windows 10x64 pro current) I do not see them at all, but the only things missing are the groups, so pretty sure this is not some issue with the network or firewall, but the group identifications.

Is there any special setting needed to find grouped google speakers (one pair are "max" and one is the medium size ones, I think they were just called "home" back when I bought them; these are pre-nest-brand).

Linwood

It shows groups on my 5.0.4 installation. You may want to try a router restart, it sometimes clears things up.

It's the same subnet, so the router is not even involved, the packets literally do not go through the router. And it shows all non-grouped cast devices. And my Android shows all the groups while on the same network (again, no router involved).

Are you on 5.0.4.2690? There were numerous changes to the cast routines in .2682 forward. I haven't tried older ones, just started with the latest build (haven't used MM in 2 years or so for irrelevant reasons, just haven't needed it).

I discovered I had a portable installed copy of 5.0.0.2268 (really old). I ran it, same PC, same network, same everything - it shows the speaker groups.

What's bizarre, is after doing so, I reran the 5.0.4.2690 version and it now also shows the groups.

Is there some persistent record of the devices, that one version left behind and the other found? Since this was portable the actual database was separate for each run, but registry? Something else?

Or is there something more random going on?

The old by the way shows both the group and each component speaker, the new version only (now) shows the group. So that's a nice change from a couple years ago.

Hi,
Most likely Portable pinged group to re-announce to network and 2690 picked it up

Peke wrote: ↑Sat Nov 26, 2022 8:48 am Most likely Portable pinged group to re-announce to network and 2690 picked it up

I spent a bunch of time experimenting and I think I understand the issue. The short version is that I have a complicated PC and network setup and I was testing in a configuration unlikely to be common. If you want the details read on, as there is a slight twist...

Cast device discovery depends on broadcast, which may not span subnets, but cast devices can work routed across subnets if the IP addresses are known. MM preserves the IP addresses in LAST_REMOTE_PLAYERS in persistent.json. So if you take a computer and put it on the network with the cast devices, allow them to be discovered, then move to another network it uses persistent.json to remember the IP addresses and can access them even on the other subnet if routing is properly set up.

In my case my computer has multiple NICs. When I was experimenting, the persistent.json was confusing things, so I did some tests emptying that array first.

When ONLY the NIC with the cast devices is present, it correctly sees the groups and all devices, and does not show the individual devices (that are in the group). This is all correct and as expected.

With LAST_REMOTE_PLAYERS empty, and with the NIC leading to the cast devices present, AND another NIC present (irrelevant to all this, or should be), MM finds chromecast devices, but does not find google speakers. For reasons unclear it can 'see' some specific devices not others. I would assume it is listening on the wrong device, but it is unclear how it finds the chromecast devices at all (on the same network as the speakers).

If I start over, only the NIC on the casting network present, let it find all the devices, it saves them in LAST_REMOTE_PLAYERS for individual devices but NOT for speaker groups nor for their components. I am not sure if that is intended or not?

Now with that persistent.json if I bring up the other unrelated NIC and restart MM (the cast NIC is still there also), it uses the persistent.json to get the proper IP addresses and can access the speakers fine, and play through them (despite, if LAST_REMOTE_PLAYERS were cleared, it cannot find them). However, it does not show any speaker groups, nor their components. I assume (but have no way to know) that it is listening on the non-cast NIC for broadcast, but using the persistent.json to show the devices already found. I suspect this is just a design limitation -- that in a multi-NIC system it picks one, in this case it picked a bad choice.

So I understand what is happening for me, and can accommodate appropriately.

I think it is probably just a design limitation that MM cannot work properly with cast devices when the PC has multiple active NIC's on different subnets. It may be luck of the draw depending on to which it decides to listen.

I think it is also a (planned?) design limitation that you cannot persist group devices (e.g. information on the volume setting) across MM runs, since they are not stored in LAST_REMOTE_PLAYERS. Though that seems more odd to be planned.

My initial testing was confused because of a combination of leaving persistent.json present and also not consistently disabling the non-cast NIC. Since paying attention to those, it is consistent (well, except for not storing groups in the LAST_REMOTE_PLAYER array, which seems inconsistent).

Hi,
so with a clean persistent.json build 5.0.4.2690 doesn't detect the groups but 5.0.3 detects them?

If yes, then it could be related to a change in https://www.ventismedia.com/mantis/view.php?id=19278
where the goal was to exclude the "paired" speakers from the list.

But as the detectio was reverse engineered then it might be a bug causing the not listing the groups instead of the individual speakers in your environment?

Could you please generate log using DbgView (with DbgView started prior to MM5) and attach the log to eSupport ticket?
See item 4B here for details: https://www.mediamonkey.com/forum/viewt ... 30&t=86643

Thanks!

Ludek wrote: ↑Mon Nov 28, 2022 10:40 am so with a clean persistent.json build 5.0.4.2690 doesn't detect the groups but 5.0.3 detects them?

No, I think that is working fine. It was confused in my testing by two things:

1) I had a portable install from 2+ years ago, over which I installed the 5.0.4.2690, but that left in place the prior persistent.json with whatever IP's were present (maybe including the group components), and also

2) I think in my initial testing I had both NIC's active, before (re)discovering that it does not work properly with two active NIC's.

I just tried it again, removing the contents of LAST_REMOTE_PLAYERS, and starting with one NIC and it properly found the groups, did not show the components.

The only open issues in my mind from testing are:

1) Did you intend to support multiple active NIC's? I am not sure it is worth the effort for typical users, but if you do, it is not working properly.

2) Are the speaker groups supposed to appear in LAST_REMOTE_PLAYERS at all? They do not, which prevents it from saving attributes, but also prevents that array from being used for off-subnet groups (it works fine for off-subnet individual speakers).

There is also an unrelated oddity I found: If you edit persistent.json in visual studio, allowing visual studio to reformat it, it is no longer acceptable to MM, it gives no error but it discards all (or almost all) of the settings. Editing as one huge string works fine, it is not the editing but the reformatting. That's odd, json should be immune to formatting like that, but it is also hardly an error a typical user will encounter. But I feel if persistent.json is discarded by MM, there should be some popup warning, the old version saved, something.

1) Did you intend to support multiple active NIC's? I am not sure it is worth the effort for typical users, but if you do, it is not working properly.

AFAIR it works to discover devices on multiple NICs by binding to '0.0.0.0'; // INADDR_ANY (to bind socket to all available interfaces). And multicast group 224.0.0.251 (port 5353) when doing the mDNS discovery. Couldn't it be rather blocked by firewall in your environment?

2) Are the speaker groups supposed to appear in LAST_REMOTE_PLAYERS at all? They do not, which prevents it from saving attributes, but also prevents that array from being used for off-subnet groups (it works fine for off-subnet individual speakers).

LAST_REMOTE_PLAYERS was intruduced just like a temporal "cache" to list Google Cast devices that has temporarily failed to discover for some reason, there is currently a timeout (AFAIR 7 days) for which they appear in the list of devices. So maybe in your environment the devices couldn't be discovered temporarily which resulted also in the groups not appearing, right?

There is also an unrelated oddity I found: If you edit persistent.json in visual studio, allowing visual studio to reformat it, it is no longer acceptable to MM, it gives no error but it discards all (or almost all) of the settings. Editing as one huge string works fine, it is not the editing but the reformatting. That's odd, json should be immune to formatting like that, but it is also hardly an error a typical user will encounter. But I feel if persistent.json is discarded by MM, there should be some popup warning, the old version saved, something.

I cannot replicate this, what's your version of Visual Studio? I tried with Visual Studio Code 1.73.1

Ludek wrote: ↑Mon Nov 28, 2022 12:23 pm

1) Did you intend to support multiple active NIC's? I am not sure it is worth the effort for typical users, but if you do, it is not working properly.

AFAIR it works to discover devices on multiple NICs by binding to '0.0.0.0'; // INADDR_ANY (to bind socket to all available interfaces). And multicast group 224.0.0.251 (port 5353) when doing the mDNS discovery. Couldn't it be rather blocked by firewall in your environment?

No, first both are attached, so one would receive it directly not through the router. But just conceptually if it works with NIC #1, adding NIC #2 (if it is listening on both) would not have an impact on what NIC #1 receives.

Also, Chrome (the browser) on this PC sees all the speakers correctly in the one NIC and two NIC configuration.

Finally, just to be sure, I did a packet capture and I can see the broadcast that defines the group coming in on the expected interface (broadcast to 224.0.0.251 UDP port 5353).

It's been too long since I did any socket programming but it just seems to me that you are giving some preference to one NIC over the other, and (again guessing) it's listening on only one. Or, I guess, it is possible it hears the broadcast (listening on both) but somehow decides it doesn't have a proper path to it, comparing to the other NIC's IP (which is on a different subnet of course).

Regardless, the key test to me is Chrome sees it, but MM does not. However, again, I think this is an unusual configuration, but if you want to make it work, I'm more than happy to collect some data.

Ludek wrote: ↑Mon Nov 28, 2022 12:23 pm

2) Are the speaker groups supposed to appear in LAST_REMOTE_PLAYERS at all? They do not, which prevents it from saving attributes, but also prevents that array from being used for off-subnet groups (it works fine for off-subnet individual speakers).

LAST_REMOTE_PLAYERS was intruduced just like a temporal "cache" to list Google Cast devices that has temporarily failed to discover for some reason, there is currently a timeout (AFAIR 7 days) for which they appear in the list of devices. So maybe in your environment the devices couldn't be discovered temporarily which resulted also in the groups not appearing, right?

OK, but I am not sure I understand the implication. Consider this scenario: I removed LAST_REMOTE_PLAYERS content entirely, and connect to the one NIC on the same subnet as the speakers. I can see the groups and individual speakers, all is good, they all appear exactly as expected. I shut down MM and look at persistent.json. Do you expect the groups to be in the list? All I see are the individual speakers (and NOT the individual speakers that make up the groups).

Other than not persisting volume (and maybe other things) this does not keep it from working on a single nic, but groups (and the groups' components) are not present.

There is also an unrelated oddity I found: If you edit persistent.json in visual studio, allowing visual studio to reformat it, it is no longer acceptable to MM, it gives no error but it discards all (or almost all) of the settings. Editing as one huge string works fine, it is not the editing but the reformatting. That's odd, json should be immune to formatting like that, but it is also hardly an error a typical user will encounter. But I feel if persistent.json is discarded by MM, there should be some popup warning, the old version saved, something.

I cannot replicate this, what's your version of Visual Studio? I tried with Visual Studio Code 1.73.1
[/quote]

I haven't been programming in ages so mine is 16.10.3, but I doubt that is the real issue, I suspect it is something in the data. If you are interested in pursuing, can I send you a copy of an unformatted and formatted persistent.json and see if one works and one fails for you? Though obviously there is context in there for my setup. I'd rather not post publicly, not sure what's in those 10,000 plus lines.

I'd rather not post publicly, not sure what's in those 10,000 plus lines.

OK, so feel free to open eSupport ticket and we can go into the details privatelly.

OK, just upgraded to VS 2022 which appears to be the latest community edition, it shows as 17.4.1. Same thing. hardly a killer issue but will post in case it is useful to you, ticket 5135.