Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[mattkhan]

reported back in https://yabb.jriver.com/interact/index.php/topic,135621.msg954328.html#msg954328

I noticed this again today

I have no idea when or why windows does this but, for whatever reason, it does. For JRVR to respond by appearing to silently delete your entire config, which can be quite complex, is a genuinely abysmal user experience. I honestly don't think it could be worse than this. It 100% looks, in your own UI, like MC has just deleted your entire display configuration (which can be quite complex) and it's impossible to recover unless you know how MC stores this in the registry and that this is not how it displays it in the UI (so you just have to delete 1 registry key and rename another one to recover).

The MC bug in this instance is not that it can't control windows display UID, it's that it informs the user that the display is named X and doesn't merge UID updates to the same named display into a single configuration.

[Hendrik]

Display names are very limited, as its just the model of your monitor. I have two of the same, merging solely on that is not possible.

I would be happy to identify a stable identifier for monitors, but name isnt it.

For the record, this ID change never happened to me, across several systems and display reconfigurations.

[mattkhan]

In my case it's a pc connected directly to a display via hdmi with nothing in-between

Regardless, jrvr is the only piece of software afflicted by such a bug. I don't know how everyone else deals with it but doesn't seem like it is an insurmountable hurdle.

What id is this exactly right now? Could you read something like the edid instead if it's different as surely that isn't changing?

[JimH]

Use Google search to read about EDID problems and solutions. 

[mattkhan]

Use Google search to read about EDID problems and solutions. 

I don't see how that is relevant, can you expand on it?

this is strictly about how MC handles a windows device name/id which is of the form

[JRVR\\Monitors\\??DISPLAY#JKC9070#5&2cf56480&0&UID372993#{e6f07b5f-ee97-4a90-b076-33f57bf4eaa7}]
[JRVR\\Monitors\\??DISPLAY#JKC9070#5&27b3c7a3&0&UID372994#{e6f07b5f-ee97-4a90-b076-33f57bf4eaa7}]


only certain fragments of that ID change, I don't know where that comes from or why windows decides to change it. The point is that JRVR handling of this is brittle and the impact of a break is catastrophic with respect to display configuration.

[JimH]

Are you connected via HDMI?

[Hendrik]

only certain fragments of that ID change

Only those parts that are actually unique, which means it might as well change entirely.

JKC9070 is your device identifier, which is essentially just the name again, and the GUID at the end just means "this is a display" and is constant for everyone.
The middle part is the actual monitor identifier .. which changes entirely.

I thought about looking at the serial number in the EDID, but many devices seem to just not set it at all.

[Hendrik]

Can you venture into the registry and check something for me?

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\DISPLAY\JKC9070

Check the potentially multiple entries in there, which is what makes up the MC identifier. What I'm interested in is if "ContainerID" on all of them are constant?

ContainerID is supposed to be a unique identifier that identifies devices uniquely with a bit more stability (obtained from the device itself, if it supplies one, or created by windows from some properties if not), but I have limited sampling and am seemingly not suffering from this issue.

[mattkhan]

Yes it's direct connection to projector via a single hdmi cable, nothing else in the chain

I will check those registry values later on, thanks for considering it

[mattkhan]

Can you venture into the registry and check something for me?

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\DISPLAY\JKC9070

Check the potentially multiple entries in there, which is what makes up the MC identifier. What I'm interested in is if "ContainerID" on all of them are constant?

ContainerID is supposed to be a unique identifier that identifies devices uniquely with a bit more stability (obtained from the device itself, if it supplies one, or created by windows from some properties if not), but I have limited sampling and am seemingly not suffering from this issue.

Yes, I have 3 such entries and all child keys, Inc containerid, have identical values

[eve]

reported back in https://yabb.jriver.com/interact/index.php/topic,135621.msg954328.html#msg954328

I noticed this again today

I have no idea when or why windows does this but, for whatever reason, it does. For JRVR to respond by appearing to silently delete your entire config, which can be quite complex, is a genuinely abysmal user experience. I honestly don't think it could be worse than this. It 100% looks, in your own UI, like MC has just deleted your entire display configuration (which can be quite complex) and it's impossible to recover unless you know how MC stores this in the registry and that this is not how it displays it in the UI (so you just have to delete 1 registry key and rename another one to recover).

The MC bug in this instance is not that it can't control windows display UID, it's that it informs the user that the display is named X and doesn't merge UID updates to the same named display into a single configuration.

Yeah this is a pretty major problem. Mine tends to be pretty stable even with 2 identical displays (both LG OLED C2s) that serve different purposes. However, I've had this crop up a couple times, seemingly randomly. It's frustrating. Not really sure what the fix is though, not everything reports a serial # via EDID.

[Hendrik]

Thanks for checking, i'll add some logic soon to try to migrate the settings if a "new" monitor is detected, and we have an unused entry with a matching container id.
Might be a bit though, as i'm working on some other JRVR things right now, and don't want to mix too many changes.

If someone is currently running two identical screens, it would also be helpful to confirm that they do in fact not share a ContainerID.
I would have to go deep into storage to get one of my old ones when I still had two identical ones.

[leezer3]

This isn't *quite* identical, but I've got a pair of Dell U2715H displays.

One connected via DisplayPort, one via HDMI.

The container IDs are unique.

(No spare DisplayPort cables, otherwise I'd give you an absolute definitive answer)

[eve]

Yes, I have 3 such entries and all child keys, Inc containerid, have identical values

For one display, I have 6 entries. 2 share a ContainerID, the rest are unique.

[flac.rules]

If i am checking the right place (I had to go into the "default monitor" folder. I have 2 identical monitors bought the same time, the container IDs are quite different.