Print

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

[wer]

This often seen error message "Playback could not be started" sometimes displays information that can be confusing to users.  The example shown below comes from trying to play a DSF file over HDMI.

There are some things about this message that could be modified with trivial effort to make things more clear to users and reduce the number of questions posted about it.

1. Note the first line.  Although if the user clicks cancel, a more descriptive dialog appears, it would be better if this initial message was a little more clear on why the problem occurred.  I'd suggest putting the following text right below the first line:
"Either your sound card or Receiver/DAC is reporting this format is not supported."

2. Note the second line, showing the format that "would work".  64bit will not in fact work. Since it is unlikely MC thinks it is going to push 64bit audio across HDMI, it would be better if this line showed the actual bit depth MC is going to use, instead of the internal working depth. (In this case it was 24bit padded, for other cards it might be 32bit).

3. Also regarding the second line:  Is MC actually looking at the available format possibilities and making a selection?  If so, it would be much better if it suggested and selected the next available format UP instead of down. This is a 5-channel file. Playing it as 2-channel would probably not be the user's first choice, if 5.1 channels is available, which of course it is.  If MC suggested and selected 5.1 instead, the user would hear everything they were supposed to hear, instead of having a cause for complaint.

These changes would take just a few minutes to implement, and since we all know how often users see and ask about this message, I think it would be beneficial.

[AndrewFG]

^
+1

Apropos the second line: I also think that for DLNA errors, MC should check the renderer’s SinkProtocolInfo to see which format that the renderer has declared that it CAN play.

[bytestar]

^
+1

[Matt]

I'll try to tune this for a coming build.  Thanks for the help.

[dtc]

Matt - If you have not already, take a look at this thread. It shows the problem well.  Handling these error cases is never going to be exact, but the more it can be improved the better.

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

The root cause in that thread seems to be how to handle unusual configurations like 5.0 including with HDMI cards that do not like odd numbers of channels.  And, in this case since it is a DSD to PCM conversion, control is somewhat out of the control of the user.

Thanks for looking at this.

FYI - The 5.0 DSD sampler files from that thread are available free if you want to use those for testing.

https://www.nativedsd.com/catalogue/albums/ndsd017-nativedsd-music-free-starter-pack/

[mattkhan]

A related issue is how this is handled on remote devices (like jremote). Unless I am doing something wrong you don't even get an error message in that scenario which is even worse than a confusing error message.

[Matt]

I also made this change:
Changed: When opening 3, 5, or 7 channel files, we will try to auto-configure as 7.1 and offer that as one of the choices.

[dtc]

How about changing 5.0 to 5.1 instead of 7.1.

[wer]

Yes, 3.0, 4.0 and 5.0 should be offered as 5.1.  Only 7.0 should be offered as 7.1.

The reason is everyone who can do multichannel will be able to process 5.1, but not everyone can process 7.1.

[Matt]

Because I'm trying to make you all happy

Changed: When opening 3 or 5 channel files, we will try to auto-configure as 5.1 and offer that as one of the choices.
Changed: When opening 7 channel files, we will try to auto-configure as 7.1 and offer that as one of the choices.

[wer]

It's doubtful this will benefit anyone reading this thread, but I do think it will reduce support questions.  Thanks.

[wer]

So regarding the changes made in .62:

4. Changed: Tweaked the text of the auto-configure dialog to be more clear and to not report the bitdepth (since that isn't the actual output bitdepth).

I don't think this is a good change.  I think it should report the actual output bitdepth, not the working depth (as it was) or nothing (as this new change does).

As an example why, I wrongly configured my audio options to have a bit depth of 32-bit floating point. My hardware doesn't like that.

MC reported it couldn't start playback with the format "44.1 kHz 4 ch".

So that is still misleading. In fact, the hardware WILL accept 44.1 kHz 4 ch, IF the bit depth is set appropriately. It should have reported "44.1 kHz 4 ch 32-bit (floating point)"

The information communicated to the user needs to be accurate, and needs to help solve the problem.  When MC was always communicating the bit depth as 64 bits, that was inaccurate.  Now it communicates no bit depth, and sometimes that is not helpful.

So again I'd like to suggest that the bit depth be reported as the correct output depth that MC is going to use.  Preferably the language should correspond to one of the choices on the bitdepth menu.

I also think the phrase "This output format may not be supported by your hardware" is not direct enough for some people.  Too many people claim MC is broken when they see this message.  They need to hear "Either your sound card or Receiver/DAC is reporting this format is not supported."

[wer]

If behaviour  was changed I don't like it.  I don't want MC to make guesses and it shouldn't play anything if DSP settings are incorrect with Wasapi (or ASIO) for a specific device...People should know what they are doing !

You're not quite following the thread. Nothing has changed, in the sense that MC still has, and has long had, a dialog box that appears when an output format doesn't work, and that dialog ASKS if you want it fixed automatically.  We're talking about what that dialog says, and the options it presents. We're not talking about new "guessing" or new automatic fixing. One aspect of it is that if 5.0 fails, but 5.1 is valid, MC should suggest 5.1 instead of 2.0.

You have always been able to control that behavior with the option "Auto configure output setting on playback error".  That hasn't changed, so there's nothing for you to not like here if your goal is for playbaack to fail on format mismatch.

[Hendrik]

The only thing that changed was the information presented on the dialog, and the formats it may offer you. There is no additional automatism or anything like that.

[jmone]

I had a head scratcher today after updating a NUC (Windows, BIOS, drivers etc etc).  Same Diag box warning when playing some videos, but with no details of what the stream was or what would work... just that playback could not start. 

Turns out it was the Audio Device disappears briefly during the "Display Settings automatic change mode" switching frame rate.  Adding a "Wait after change" fixed it prevents the issue, but no idea if you want to check for that and add to the warning/advice.

[fitbrit]

I had a head scratcher today after updating a NUC (Windows, BIOS, drivers etc etc).  Same Diag box warning when playing some videos, but with no details of what the stream was or what would work... just that playback could not start. 

Turns out it was the Audio Device disappears briefly during the "Display Settings automatic change mode" switching frame rate.  Adding a "Wait after change" fixed it prevents the issue, but no idea if you want to check for that and add to the warning/advice.

I had a similar problem on multiple systems and it took me over a year to figure out that it only occurred when custom resolution/refresh rate changes were being made. I did report it and asked for this to be added as a possibility in the error message. I believe it was implemented at the time, but haven't checked whether it is still there.

[imeric]

You didn’t get my point. In a nutshell there is resampling happening when it shouldn’t.  I know exactly how the DSP tool works. I was just referring to the other post thinking it may be related to a possible change. Like I said I’ll be testing a bit more on other DACs and PCs...I should have posted this somewhere else though you’re right :-)

Someone else experienced what I was trying to explain by a "change of behaviour in MC":

https://yabb.jriver.com/interact/index.php/topic,128583.msg892975.html#msg892975

[wer]

There's a recently introduced bug where the warning dialog would not engage when it should. I reported it, and Matt's on top of it.

[dtc]

There's a recently introduced bug where the warning dialog would not engage when it should. I reported it, and Matt's on top of it.

I think this is a different issue. WASPI Exclusive seems to be producing strange results with some configurations.  See the other thread.

[imeric]

I removed my posts in this thread which were confusing everyone...myself included ... Just read this post:  https://yabb.jriver.com/interact/index.php/topic,128583.msg892309.html#msg892309  for the resampling and WASAPI issues...