Print

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

[fitbrit]

The Issue
In the last year I have posted a few times about HDMI zones not being able to get exclusive multichannel access to HDMI AVRs or pre-pros. I build a new media PC every one to two weeks for people, so I have encountered MC on more different machines (albeit with similar hardware) than most forum members I suspect.

The symptom
When trying to play any multichannel video, the message that "the format is not supported and to try 2 channel 48 KHz} pops up. Therefore, the video file cannot be played in its native capacity. Eschewing WASAPI for Direct Sound works fine, but we all know that that is not optimal quality. All the settings are set correctly, with Windows knowing that the sound device should be open for exclusive access, and is a multichannel device. All connection settings work fine because Win 10's built in video player can actually bitstream lossless formats through them and play the files.

Circumstances of it happening
This can end up happening in any of the following ways:

1. It works fine in my test system, but when it ends up in its final destination, the above issue occurs
2. An HDMI handshake issue or other glitch occurs and then it happens... For one person it was while one track was transitioning to the next.
3. All is well, but then you change a setting in MC (that is not intuitively anything to do with this) and the issue occurs
4. The three known cases were through Datasat, Classe and Anthem AVRs, so not some of the most common brands.
I suspect that at least one instance 3. was precipitated by editing the display device properties in MadVR - e.g. setting that the device connected is an AVR and the connected display is a digital projector. But it is only a suspicion.

Solutions

1. Twice, the problem was solved by restarting the audio service, which I believe resets the HDMI connection and forces a new handshake. Therefore, whatever caused the glitch is removed. However, in some cases that has not worked.

2. Also twice (out of two times), the solution has been to quit wasting time trying everything repeatedly, restarting 100 times in the process, loading new drivers, reinstalling MC etc. Once you make peace with that, simply create a new HDMI zone, configure it exactly as before, and delete the old one. Voila!
I don't recall whether I copied the original zone settings when creating the zone the first time I tried it. The second time, however, I decided to be sure and start from scratch. I think this is the more reliable solution. I will find out for sure later this week, as I am scheduled to fix it for another client, who until now has been forced to have MC open up the Microsoft built-in video player for movies.

This leads me to suspect that something about MC's HDMI zones can lead to corruption of some kind. I have seen this issue 4 times out of maybe 120 systems overall. All that were affected had Gigabyte H270 motherboards and have occurred in the last one year.

[blgentry]

Have you tried an HDMI EDID device in between to prevent this problem?  I'm curious if it would "fix" this issue without messing around with software.

If it worked, it might become part of your standard package (that your company sells).  Or an optional extra that is "highly suggested for those that use video on their systems".

I don't envy your troubleshooting efforts on this.  But I commend you and wish you good luck!

Brian.

[bob]

You might want to check to see if the settings for "Disable display from turning off (useful for HDMI audio)" is different between the zone you created that doesn't work and the new one that does.
It sounds more like a hardware glitch with the EDID negotiation to me but then I can't see why simply creating a new zone would fix it.
Maybe you could compare the settings for the the zone between working and non-working zones in the registry.

[fitbrit]

Have you tried an HDMI EDID device in between to prevent this problem?  I'm curious if it would "fix" this issue without messing around with software.

If it worked, it might become part of your standard package (that your company sells).  Or an optional extra that is "highly suggested for those that use video on their systems".

I don't envy your troubleshooting efforts on this.  But I commend you and wish you good luck!

Brian.

Using an HD Fury device was the first solution that worked, but it took several days of setting it up, and it seemed to defy all logic. Settings that should have worked - possibly could not fail to work - did not fix the issue. It was a ruined Christmas break for me, with constant stress due to a dissatisfied customer of my then fledgling company. Eventually, suddenly, it worked, but it could have been because I did something drastic like reformatting and reinstalling. The fix was only temporary - when playing with MC's settings, mostly switching from ROHQ to ROStd or tweaking some MadVR settings, the problem came back.
It was fixed eventually, after several more days, and I am not convinced now that the HD Fury was needed at all, or was the reason for the fix.
With another customer that was experiencing this in MC, bitstreaming in 7.1 with other software worked just fine, and the issue really seemed to be with MC - I will get to reexamine this issue later in the week.

Still the HD Fury line of products could be recommended at the time of sale, but so far customers are not that thrilled to have to buy yet another device. Also, some of them insist on multi-hundred dollar HDMI cables, and having something else in the chain is not looked on favourably.

[fitbrit]

You might want to check to see if the settings for "Disable display from turning off (useful for HDMI audio)" is different between the zone you created that doesn't work and the new one that does.
It sounds more like a hardware glitch with the EDID negotiation to me but then I can't see why simply creating a new zone would fix it.
Maybe you could compare the settings for the the zone between working and non-working zones in the registry.

"The Disable display from turning off" setting is a good idea to check, Bob. It's one of what I consider to be minor settings and I may have overlooked this. However, the situation is never a system-wide EDID recognition issue. Rather it seems that the EDID info is just not being passed on to MC, since other software continues with exclusive, multichannel access just fine. It really seems like the WASAPI in MC simply cannot kick in for some reason.

Unfortunately, I lack the know-how to compare the registry settings.

[fitbrit]

Here is another recent example of what I think is the same issue from another person:

https://yabb.jriver.com/interact/index.php/topic,117404.msg813446.html

[Hendrik]

MC doesn't really retain any information about the output device that may get "stale" or anything like that, other then the device ID to identify the device of course, so unless that changed and therefor got mismatched, I wouldn't know what else could possibly go wrong.

If you can create a new zone which then works, and still have the non-working zone in MC at the same time, exporting the zone settings for comparison might be useful.

In the registry you can find the zone settings here:
HKEY_CURRENT_USER\Software\JRiver\Media Center 24\Zones

Exporting Registry Keys for dummys:
1) Open regedit.exe
2) Navigate to the wanted "folder" just like in a file explorer
3) Right click the target folder (in this case "Zones"), and select "Export"
4) Save the resulting file and share it with us, and we'll do the comparison (either here or mail it to bob or myself, or both, always <firstname> at jriver dot com for both of us)

[fitbrit]

Thanks Hendrik

That's excellent information.

[millst]

MC doesn't really retain any information about the output device that may get "stale" or anything like that, other then the device ID to identify the device of course, so unless that changed and therefor got mismatched, I wouldn't know what else could possibly go wrong.

I've seen this quite a bit with my HDMI output. The name used to change randomly e.g. HSR-1 to HSR-2 (probably some kind of HDMI/EDID glitch). Other times the name stays the same, but the configuration gets lost and I have to reconfigure it to be 8 channels instead of the default 2 channels. I've learned to always verify the config after updating NVidia drivers.

-tm

[fitbrit]

I've seen this quite a bit with my HDMI output. The name used to change randomly e.g. HSR-1 to HSR-2 (probably some kind of HDMI/EDID glitch). Other times the name stays the same, but the configuration gets lost and I have to reconfigure it to be 8 channels instead of the default 2 channels. I've learned to always verify the config after updating NVidia drivers.

That's quite common, and very easy to fix. It's usually the first thing I check. In the cases above, multichannel in MC would not engage even when this setting was correct, and worked for other software.

[fitbrit]

Hendrik/Bob

I sent the registry key by email. There are two copies - one with the .txt file suffix instead of .reg in case your mail reader will not let you open the attachment. Please let me know if you do not get the email and I will send with only the .txt attachment.

Quick recap:
Customer couldn’t play multichannel audio in Wasapi mode in his zone: Zone 1 - HDMI
I think it was set to Source number of channels, but did not matter if it was set to 5.1 in DSP studio.

I copied the zone to create another one. That did not work.
I created a new HDMI zone and it worked right away. This has been the observable pattern for several systems now.

Zone 2 - HDMI is the bad one
HDMI Test is the good one

Thanks for any insight and sincere apologies if the answer is glaringly obvious.

[Hendrik]

Some differences, but nothing too obvious. Can you also provide a Log of the failure to open the device?

[fitbrit]

If I get a chance to access the system again, I shall do so. Since it is not my PC, I will email the log again rather than posting it here.

[fitbrit]

Sent the log. Interestingly another issue showed up, which might be an MC bug. Will start a new thread.

[Hendrik]

I can see it failing to open the device once, but then it succeeds. Unfortunately it doesn't log enough to let us know what exactly is going on. I'm extending the logging now.

[fitbrit]

I switched zones to the zone that worked after the original one failed. This was intended to  demonstrate for the log the difference between the zones. So when you say it worked right after, there was a zone changing step in between