Print

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

[voodoo5_6k]

As MC29 is considered more or less "final" with version 29.0.87 (https://yabb.jriver.com/interact/index.php/topic,133998.0.html) I have to assume that the progress bar and skip issues won't be fixed there.

Although I don't have access to MC30 yet, I also have to assume that it'll behave exactly like MC29 does.

I had everything detailed in this MC29 thread: https://yabb.jriver.com/interact/index.php/topic,133623.0.html

The issues:

1. Progress bar indicator: It'll vanish a few seconds before the played track is over. It'll also do this when turning off gapless and switching to normal track transition.
2. Skip scenario: Wait for a track transition (track x to track x+1). While track x+1 is playing, skip backwards twice (the first skip brings one back to beginning of track x+1, as expected). This'll move playback to track x-1, skipping track x completely (and incorrectly). Now, skipping forward brings one back to track x+1, not track x which is skipped again completely (and incorrectly).

It would be great if these issues got sorted out to make MC30 then work like any other media player I know, showing the progress indicator to the very end of a track, and skipping from one track to another sequentially, without leaving one out.

Thanks in advance (as it's still some time before MC30 will hit the broader public)

[voodoo5_6k]

So, MC30's there Congratulations to Jim and the team!!!

Installed it first thing in the morning. This time the upgrade went perfectly smooth! Cool

And now, back to topic. Of course, I had to test straight away.

1. The progress indicator is now working almost perfectly. It moves along until the end of the track. But (and that's just a very nitpicky but) it's pretty "jerky" over the last few seconds (where it formerly would just vanish), it stops, jumps forward a little, stops etc. Maybe something can be done about that?

2. The skip issues remain. An idea: Why not make selecting skip backward just move to the previous track, just as skip forward moves to the next track? Basically, getting rid of the nuance of first going to the beginning of the current track. Because it is now very hard to actually use skip backward to get to the previous track. One has to click multiple times, and then I don't necessarily end up at the previous track. Sometimes I'm at track 1, although the previous track would have been 4 or whatever. Maybe, moving to a strict and simple approach (1 skip backwards = beginning of the previous track, or x skip backwards = beginning of current track # - x) could eliminate this random and strange behavior of the application.

[Matt]

You can set the previous button behavior in options.  Try picking a different mode.

[voodoo5_6k]

Hi Matt,

Thanks for the hint, didn't know about that

However, there's still something wrong with "skipping". I logged an example.

I started with a certain track, and then alternating between skip backwards and skip forwards, you can observe an interesting behavior. Starting with track x, skip back now directly brings playback to x-1, skip forward directly back to x, skip back again, but now I'm at x-2 (not x-1). Skip forward, back at x (not x-1). Skip back again, now I'm at x-3 (not x-1), skip forward, x again (not x-2). I repeated that until I reached track 1 of the disc. This can't be intended (just for the fun of it tested Windows Media Player, and it sure doesn't do this).

So, I was expecting:
Track x, skip back to x-1, skip forward to x, skip backward to x-1, skip forward to x, and so on.

However, I'm getting:
Track x, skip back to x-1, skip forward to x, skip back to x-2, skip forward to x, skip back to x-3, skip forward to x, skip back to x-4, skip forward to x, and so on.

Logs attached.

[Matt]

I roll through a local album of APE files with Ctrl+N and Ctrl+L and it just works exactly as expected.

So I'm not seeing any skips.

I did set the previous button to always seek to the last track, although I'm not sure if that matters.

[voodoo5_6k]

Thanks Matt, I can reproduce the same behavior with CTRL+N & CTRL+L. I have set the previous button to "Previous track always" today, before it was "CD player style". That's all I see when searching the options for "previous".

[voodoo5_6k]

And no changes with 30.0.18.

To add to this:

I started with a certain track, and then alternating between skip backwards and skip forwards, you can observe an interesting behavior. Starting with track x, skip back now directly brings playback to x-1, skip forward directly back to x, skip back again, but now I'm at x-2 (not x-1). Skip forward, back at x (not x-1). Skip back again, now I'm at x-3 (not x-1), skip forward, x again (not x-2). I repeated that until I reached track 1 of the disc. This can't be intended (just for the fun of it tested Windows Media Player, and it sure doesn't do this).

So, I was expecting:
Track x, skip back to x-1, skip forward to x, skip backward to x-1, skip forward to x, and so on.

However, I'm getting:
Track x, skip back to x-1, skip forward to x, skip back to x-2, skip forward to x, skip back to x-3, skip forward to x, skip back to x-4, skip forward to x, and so on.

Logs attached.

Say, I started with track 10. When doing this, and skip backward reaches track 1, 1x skip forward brings me back to track 10 again, and now skip backward will stop working altogether (as there is no track before track 1, although it should bring me to track 9 in the first place).

[HPBEME]

That is some really bizarre behavior!  I cannot duplicate it.

I assume you have messed around with all the various settings in Audio/Track Change options already just to check. There are also some tangentially related settings under General/Behavior and General/Advanced that might somehow be involved? Grasping at straws here I know, but that seems to be the stage we are at.  It just seems like it would have to be that certain MC settings are combining in some bizarre way to produce the (unintended) behavior you are seeing.

Or maybe....  Do you have any other media programs installed that have preassigned (global) hotkeys? Or hotkeys you may have custom assigned? If so, maybe those are crossing over into MC. 

[voodoo5_6k]

Haha, yeah, bizarre is a good description

Thanks for your suggestions! Yes, I had tested everything I could find that's remotely related to track changes, but no dice. I just went back and tried again, but there's no difference (even with restarting MC after making changes in the options).

Regarding the other media program idea. There are the usual suspects (Windows 10 Pro defaults a.k.a. Windows Media Player and the Movies & TV application, or whatever its name is) and also Winamp (only used for ripping CDs). But none of these are running or even configured for actual playback.

The attached log is from a few minutes ago, cold start of the PC, no other applications running except for the Windows baseline and the command prompt.

Regarding reproducing. I start MC, select a disc and start playback at a random track. I click close to the end of the progress indicator and wait for the track change. Then, I click skip backward, wait a second, click skip forward, wait a second, click skip backward etc.pp.

[HPBEME]

Skipping multiple tracks backward with a single click - which grows by one incrementally each time - that is just truly weird. I wonder if anybody else is experiencing this. As for the attached log file, I think I will leave it to those who actually get paid to slog through that .

The only other thing I can think of is, maybe it is somehow related to running MC remotely, using a network/DLNA, multiple drives in a NAS set-up… etc.  I have nothing useful to add in that regard however, as I don't use any of that. My set up is very vanilla - my computer is hardwired straight to my TV with zero audio gear in-between, and all my media files are on a single 8 TB drive.

Good luck! Hopefully the JRiver team will somehow get it figured out.

[JimH]

JRiver, not J River, please.  It works better with searches.

[HPBEME]

Well all right sir.

That is just how Dragon NaturallySpeaking spits it out when I say "J River". Just spent the last five minutes training Dragon to spell it as "JRiver", but it just won't do it. I will try to remember to manually remove the space between the "J" and "R" going forward - a thousand apologies for any confusion.

[eve]

Well all right sir.

That is just how Dragon NaturallySpeaking spits it out when I say "J River". Just spent the last five minutes training Dragon to spell it as "JRiver", but it just won't do it. I will try to remember to manually remove the space between the "J" and "R" going forward - a thousand apologies for any confusion.

Can we take a moment to appreciate that somehow Dragon still exists? I remember playing around with it as a kid, it seemed so promising and futuristic. It was *so* not there however. I'm really curious where it's at now since speech recognition elsewhere is really excellent. Does it work reliably now?
For speech to text (not dictation) I'm using Watson mostly. Its *really* helpful for subtitling interviews and footage, we pretty much don't have to pay for dedicated closed captioning now.
Personally, I've been playing with it to transcribe the audio of film commentaries, in step with another OCR / Subtitle extraction project to build an elastic search database of film dialogue. It's frankly pretty pointless but it's a cool premise, " hey how many movies have the like 'you look like s***'? "

[HPBEME]

I don't want to hijack this thread with my response, so I will reply to you via PM.  Jim has moved my share of off-topic discussions to standalone threads in the past, so I will do my best not to make him do it again

[JimH]

I don't want to hijack this thread with my response, so I will reply to you via PM.  Jim has moved my share of off-topic discussions to standalone threads in the past, so I will do my best not to make him do it again

I move my own sometimes.

[voodoo5_6k]

Thanks, HPBEME!

Although there's nothing in the changelog that would suggest a change, I nevertheless tested with 30.0.19. As expected, nothing's changed (in that regard).

[JimH]

What are you playing to?

[voodoo5_6k]

Hi Jim!

It's still my nice little Henry Audio USB DAC 128 Mk 3 (https://www.henryaudio.com/), connected directly to the PC via a good 2m cable.

[voodoo5_6k]

1. The progress indicator is now working almost perfectly. It moves along until the end of the track. But (and that's just a very nitpicky but) it's pretty "jerky" over the last few seconds (where it formerly would just vanish), it stops, jumps forward a little, stops etc. Maybe something can be done about that?

I have to make an addition to that. Yes, it works better as before, but still:
- The last few seconds (that would vanish before) are very "jerky", the progress indicator is stuttering forward.
- When listening to several tracks in a row (e.g. an album), after each track change the progress indicator will only start with a small delay like a second (one can still see the waveform of the previous song, but already hear the next one, briefly).
- Once the buffering for the next track starts, MC will ignore clicks on the progress bar (to navigate within the song).
- Also, once this buffering begins, MC will move the files view focus (e.g. in the Artists view) back to where the track change will happen, sometimes more than 5 seconds before it.

[voodoo5_6k]

Thanks for releasing MC 30.0.26!

I have tested again, but everything remains as-is. Logs attached.

I have to make an addition to that. Yes, it works better as before, but still:
- The last few seconds (that would vanish before) are very "jerky", the progress indicator is stuttering forward.
- When listening to several tracks in a row (e.g. an album), after each track change the progress indicator will only start with a small delay like a second (one can still see the waveform of the previous song, but already hear the next one, briefly).
- Once the buffering for the next track starts, MC will ignore clicks on the progress bar (to navigate within the song).
- Also, once this buffering begins, MC will move the files view focus (e.g. in the Artists view) back to where the track change will happen, sometimes more than 5 seconds before it.

Another addition:
- Correlating to the second bullet point above, the track change in the files view area (e.g. in the Artists view) will also happen with a small delay like a second (i.e. after already hearing the next song).

[voodoo5_6k]

Now, with MC 30.0.30 released (Thanks ), I tested again.

Same system, no hardware changes (i.e. Win10 Pro 22H2, playing directly to a connected DAC).

Also, no change in behavior, as noted in previous posts: All issues remain.

[voodoo5_6k]

Thanks for yet another MC release!

After a quick test with MC 30.0.31 on the same hardware: No change. All issues with progress bar/indicator & skip as detailed within this thread remain.

[Matt]

I still can't reproduce any erratic playback skipping.

I have my previous button set to "Previous track always" which you said you also used.

If I play a local album and Ctrl+N / Ctrl+L, it just always skips to the next track and previous.  It loops from the first to the last track of my playlist no problem.

Disable any plugins you have running.  You might even try re-installing.

Your reports about using the physical seek bar right at the end of playback might just be the way it is.  The program switches tracks internally a little before it shows, so you won't have control with the playback bar for the last few seconds.

[voodoo5_6k]

Thanks Matt!

Well, I've now installed MC 30.0.33, and copied an album to my desktop, created a new test library, imported those files, and retested (logs attached).

After import & analyze, I started playback (track "x"), and clicked on the progress bar (towards the end). The progress bar is stuttering at the end (jumping forward, definitely noticeable), and ignores other commands. You explained it, and I guess it is what it is, although that's not really good, never saw any other player do that.

Anyhow, the next track starts ("x+1"). I click skip backward, and playback starts not with the previous track ("x"), but one track before that ("x-1"). Skip forward and I'm back at "x+1". Skip backward: "x-2", skip forward: "x+1", skip backward: "x-3", skip forward: "x+1", skip backward: "x-4", skip forward: "x+1". Once skip backward reaches the first track of the album, and I skip forward (again, "x+1"), skip backward will no longer work at all (as there is no track in front of the first track of the album).

So, still the same with MC 30.0.33, and even with local files.

[HPBEME]

Anyhow, the next track starts ("x+1"). I click skip backward, and playback starts not with the previous track ("x"), but one track before that ("x-1"). Skip forward and I'm back at "x+1". Skip backward: "x-2", skip forward: "x+1", skip backward: "x-3", skip forward: "x+1", skip backward: "x-4", skip forward: "x+1". Once skip backward reaches the first track of the album, and I skip forward (again, "x+1"), skip backward will no longer work at all (as there is no track in front of the first track of the album).

That sucks you're still having to deal with this.  I was hoping by now somebody else who has the same issue would post… But so far only you.  I'm sure you have done this already but… Have you tried uninstalling MC completely, and then reinstalling (versus just reinstalling over the existing install)?  Assuming the answer to that is yes...

I wonder it's related to some small/random OS corruption. If you've never run the whole DISM cycle, you might want to try that. https://www.windowscentral.com/how-use-dism-command-line-utility-repair-windows-10-image   From the link:
On Windows 10, the DISM command tool includes three options to repair an image, including "CheckHealth," "ScanHealth," and "RestoreHealth," which you want to use in order. Also, depending on the issue, you can use the "RestoreHealth" option to fix the locally available image using different source files.

If you'd rather read about the DISM tool directly from MS: https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/dism-image-management-command-line-options-s14?view=windows-11

It doesn't take that long - half-hour to an hour to run all three options.  It will repair any corrupt OS installation files, and re-create missing installation files or registry entries that may have been removed by a registry cleaner.  It is certainly a much better alternative than reinstalling your entire OS, and it has saved my butt in that regard on a couple of occasions (though not related to MC).

[HPBEME]

As for the end of track skipping/jerkiness of the progress bar, I found a couple of settings where it's nonexistent to minimal. 

Enable the checkbox for Do not play silence (leading and trailing) and set Standard (gapped) or Gapped Fade track change setting to <= 0.3. For me at least, the progress bar track change is essentially seamless. The exceptions seem to be when the track has a very long natural fade and/or a long end silence.  But even in those cases, the staccato behavior is at least "less".  And just to be clear, using straight-up gapless for the track change setting does not produce the same seamless switching that the above settings do.

That said, if your preference is to "play" the track trailing silence (i.e., you do not enable the Do not play silence checkbox), I'm afraid you're out of luck from my experimenting. The track end silence is where the progress bar tends to go haywire.

MC offers an insane number of track change options: gapless, gapped standard, gapped fade, cross fade aggressive, cross fade smooth, S-curve, S-curve aggressive.  And for each of those there are 25 different time intervals you can specify. When you include the three checkboxes in the track change options group, I'm sure the permutations are in the many millions.  Maybe getting the progress bar to behave consistently has been so difficult to remedy is a direct consequence of all these possible combinations?  I wonder if all these different options are even used - seems like they could be paired down considerably without much backlash (he said right before there was a massive backlash )

I don't think the jerky progress bar has anything to do with your other issue of multiple track backward skips for a single press, though. That one is just plain weird.

[voodoo5_6k]

Hey, thanks HPBEME

Yeah, I saw this issue in MC29 already (don't remember about older versions). So, when installing MC30 I counted this as a new install. But I now have uninstalled MC, rebooted, let DISM do its thing (although the entire install is only a few months old anyhow), no issues, and reinstalled MC. Unfortunately, this doesn't affect the issues I'm seeing.

Thanks for sharing your settings for the track changes! I've dialed these in now and will look at how these will work out on my end.

Maybe getting the progress bar to behave consistently has been so difficult to remedy is a direct consequence of all these possible combinations?  I wonder if all these different options are even used - seems like they could be paired down considerably without much backlash (he said right before there was a massive backlash )

Hahaha, yeah, maybe you're right about that

[Matt]

We have to switch from a high precision position that allows smooth progress to a lower precision at the end of the track.

This is because the high precision has already switched to the next track internally.

The position won't be as smooth for the last few seconds and could jump to a slightly different position because of this.

[HPBEME]

We have to switch from a high precision position that allows smooth progress to a lower precision at the end of the track.

This is because the high precision has already switched to the next track internally.

The position won't be as smooth for the last few seconds and could jump to a slightly different position because of this.

That is interesting and helpful additional information… thanks Matt.  I doubt I can offer anything MC Code Master Matt does not already know or hasn't already tried, but what the heck, I will anyway .

At the high/low precision switch point, instead of recalculating a new low precision "pixel distance traveled per given time increment" (i.e. velocity), could the progress bar be coded to go on "autopilot", and simply use the previously determined high precision "velocity"? That way, a "static" velocity is used instead of recalculating in real-time a lower precision value for the final few seconds. That last bit, the time increment is larger and thus the distance traveled will be inherently less accurate.

Or maybe simpler would be to just "hold" the progress bar travel at the hi-lo switch point, and then return to the start position when the next track begins. Not ideal, but still maybe better than the current erratic movement that differs for every song.

I am certainly not a coder, so I apologize in advance if what I suggested above is impossible or something already considered/tried.

[voodoo5_6k]

Interesting idea. Also, the total time of each track is known before even starting playback. So one could basically determine the distance (in pixels for the progress indicator) per time increment (let's say 0.5s), and use this the entire time. High precision etc. sounds nice, and it most likely is, but what I see as the end result is a jerky progress bar, that also misses each track change by roughly 1s... Maybe there's a way to reduce precision but in the end have a nevertheless better working progress indicator?

[HPBEME]

the total time of each track is known before even starting playback. So one could basically determine the distance (in pixels for the progress indicator) per time increment (let's say 0.5s), and use this the entire time.

I think this is where MC's insane number of track change combinations makes this problematic. 

The code would have to account for gaps = 0.1 to 16 seconds, a myriad of gapped/cross-fade options, and somehow determine what the constant progress rate (velocity) should be.  I am not sure if the 2 buffers MC offers (in the device options and the MC options) would play into it as well.  It seems like is should be possible, but, I just don't know.

Perhaps something in these posts will trigger an idea for the developers to pursue.

[voodoo5_6k]

Maybe the track changes should be accounted for separately? Like on older CD players (haven't used one in decades). Track the track normally, i.e. with a constant progress indicator, but once the track change kicks in, in whatever form its configured, blank the progress bar and track information entirely and display something tbd and exactly(!) when the next track starts (not half a second later like it is oftentimes currently) track its progress.

All my old CD players switched from tracking the track's progress to tracking the transition's progress (e.g. when there's only silence left).

Perhaps something in these posts will trigger an idea for the developers to pursue.

That would be cool!

[voodoo5_6k]

Here we are again... First, thanks for releasing MC 30.0.40

Just installed it and tested (with the same hardware as before), but unfortunately everything's still the same.

[voodoo5_6k]

Still the same issues with both 30.0.41 and 30.0.48 (on the same hardware, no changes there), but thanks for releasing these

[voodoo5_6k]

Thanks for releasing three new builds :-)

MC 30.0.59: No changes, issues persist.
MC 30.0.63: No changes, issues persist.
MC 30.0.65: No changes, issues persist.

[Matt]

voodoo5_6k, can you reproduce your problems with just a couple small test files?  If so, could you send me a library backup and the files along with instructions?

I'm matt at jriver.

We haven't been able to reproduce what you're seeing.  Thanks.

[JimH]

Are you running this on VMWare?  With the same USB connected DAC?

[voodoo5_6k]

voodoo5_6k, can you reproduce your problems with just a couple small test files?  If so, could you send me a library backup and the files along with instructions?

I'm matt at jriver.

We haven't been able to reproduce what you're seeing.  Thanks.

Thanks for looking into this, Matt! I'll try to set up a new library with just one album and try to reproduce. I had done this last year, but no longer have the library. Once this is done, I'll send you the files and library backup plus instructions. Thanks again!

Are you running this on VMWare?  With the same USB connected DAC?

No, "bare metal" (i.e. Win10Pro 22H2 64-bit). Yes, the same USB connected DAC.

[voodoo5_6k]

E-Mail sent. Thanks for looking into this.

[Matt]

Thanks to voodoo5_6k for his library.

It showed the problem: removing played files was selected in Options > General.

This can be intended in some cases, but obviously it makes skipping around skip past removed files.

Glad we got to the bottom of it

[voodoo5_6k]

Oh yeah, this is a happy day Thanks again Matt