Print

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

[wer]

After the last update to MC17, it has developed an annoying behavior.

Every time I jump/ff/rew in a movie (vob or mpg on disk) the video playback will go to slow motion for a few seconds.  I press skip forward, the picture instantly moves to the appropriate time, and the video playback immediately resumes but at about 5fps for two or three seconds.  Audio playback is perfect during this period.  This happens in both the forward and backward directions.

Is this new behvior as designed, or is it a problem?  It happes with both RO-Std and RO-HQ.   MC16 on the same machine works perfectly.

Thanks...

[wer]

Matt said on the 16th in another thread:

Try reducing your audio buffering in Options > Audio > Output mode settings...

Please start a new thread to discuss it more if that doesn't solve it.

Thanks.

I've reduced audio buffering all the way down to 0.1s and it has had no effect.

Currently running MC 17.0.68, WASAPI for audio out.

MC16 (final version) running with same settings has no problem.

[Matt]

Does turning VideoClock on or off make a difference?

[wer]

No it doesn't.  Tried both ways.

[wer]

Just tried again with .75, and it still exhibits the same behavior...

 ? ? ?

[glynor]

I get this too.

Don't know if it matters, but I see it primarily on my HTPC which bitstreams.

Also, less often (but seemingly related), I get audio and video WAY out of sync occasionally instead of the slow-mo.  Just like OP, seeking again once or twice fixes it.

[fitbrit]

I get this too.

Don't know if it matters, but I see it primarily on my HTPC which bitstreams.

Also, less often (but seemingly related), I get audio and video WAY out of sync occasionally instead of the slow-mo.  Just like OP, seeking again once or twice fixes it.

Exactly the same for me on the system that I have automatic refresh rates set up for. On my other system, with identical hardware, but a fixed 60 Hz TV, this doesn't happen any more.

[glynor]

Exactly the same for me on the system that I have automatic refresh rates set up for. On my other system, with identical hardware, but a fixed 60 Hz TV, this doesn't happen any more.

I'm not using any of the automatic refresh rate changing (yet, been too lazy).

My TV supports it, but I haven't bothered.

[wer]

Latest version .091 still has this problem...  (I won't bother posting about other problems/crashes I've seen in .091 since I can not move forward with MC17 until this is fixed.)  I'm not using refresh rate changing either.  Can't turn off bitstreaming since it's the only way AC3 and DTS are going to get into my receiver.

If it is suspected that this might be an LAV issue, how about, just as a test, a private build that couples MC17 with the version of LAV from MC16?  Then we could at least isolate further.

Is Matt still looking at this issue?  I am desperate for a fix.   

[glynor]

They're working on it, but they're having trouble reproducing it.

It does seem much, much, much better on my end with the latest builds of LAV and MC.

[Matt]

If you turn off bitstreaming, what happens (as a test, not as a solution)?

Thanks.

[glynor]

I did a whole bunch of testing on this for Matt in another thread.

Turning Bitstreaming ON/OFF didn't make any difference for me.  Nor did a bunch of other things.  It is funny though, because I can see that it isn't always easy to reproduce.  I'm not having the issue on my server machine at all.  I need to pull out my laptop and test, but I think I'm done for tonight.  But I can easily reproduce it on my HTPC if I try.

[wer]

Turning off bitstreaming has no effect for me.  No problems reproducing; it happens 100% of the time with MC17.  It never happens with MC16.

Thank you Matt for continuing to look at this.

[pcstockton]

Good day thread followers,

I am getting an even more extreme experience when I seek through a video.  I dont get slow motion, I get fully frozen motion.  The only thing that fixes it is a double click to return to standard view.  The video then starts playing again correctly in the little "Display" at the bottom left. 

Sometimes it continues in the Display frame and only a stop then play fixes it.

My PC is a POS but I haven't had (m)any problems with video playback until I upgraded to MC17.

Everything has always worked seamlessly in VLC for video.  At the suggestions of some here I am trying to import video into MC then use MC for playback, rather than playing from folder level with a right-click "Play in VLC".  I was playing with this is MC16 and actually digging it, until now.  Back to VLC for video.

-patrick

[Matt]

Next build:
Fixed: WASAPI output mode could lose lip-sync when seeking in video.

Also, if WASAPI Event Style works, we recommend switching to it:
http://wiki.jriver.com/index.php/Audio_Output_Modes
http://wiki.jriver.com/index.php/WASAPI

[wer]

So you found the bug, Matt?  That's fantastic!

MC says my sound card doesn't support WASAPI event style, but I will try the fix you refer to when it's released.

Thanks!

[glynor]

This is totally fixed for me in tonight's beta.

[wer]

I just updated to .098, and still have the problem.  No change.  

If someone can give me a link where I can get .094, I will try that and see if the problem was at least fixed in that version.

[wer]

What are you seeing, glynor?

[glynor]

Well, it was fixed when I tested it last.  I tested it very extensively using "vanilla" WASAPI after that build (when I posted before).  But I've subsequently switched over to WASAPI-Event Style (which had previously not worked for me, but it is working now), and I'm seeing no problems at all with it set that way.  I know you can't do that with your DAC, but that's why I can't directly comment anymore.

I can't test it again tonight to make sure the fix to "vanilla" WASAPI didn't regress, but I can try to do it later this week.

[raym]

I see the slowmo thing after seeking too. Have for ages and pretty sure it started when videoclock was introduced. It happens between comskip edit points too. I'm kinda used to it now but occasionally it will run slowmo for several seconds so it becomes fairly noticeable.

[Hendrik]

If its because of VideoClock, it should go away when you turn it off. Well, does it?

[raym]

If its because of VideoClock, it should go away when you turn it off. Well, does it?

Yes, it's significantly less pronounced with videoclock turned off for me.

Like I said, I can live with it. :-)

[wer]

For me, as I said above in January, Videoclock has no effect either way.

[jb5200]

I don't get the slow-mo when jumping I get it every 20 seconds while watching a movie.  The audio is fine but the video slows down every 20 sec. which makes it unwatchable. 

If you recommend changing any of the settings you will need to tell where and how to do it b/c I apparently can't figure this program out on my own.  If you read my other posts about iso's you'll see I have spent many hours just getting that simple task accomplished. 

[glynor]

I don't get the slow-mo when jumping I get it every 20 seconds while watching a movie.  The audio is fine but the video slows down every 20 sec. which makes it unwatchable.  

That sounds like disk access problems or the CPU is getting overwhelmed.

Can you describe the details of your setup?  I want to know about:

1. Hardware
2. MC settings under Options -> Audio, the DSP, and Options -> Video
3. Where the files live (network drive, external drive, etc).
4. Anti-virus.
5. Windows details (version, etc)
6. Any other resident applications or plugins running in MC or Windows?

[glynor]

I just updated to .098, and still have the problem.  No change.  

Can you describe the problem a bit more.

When I seek, I do now still see "slow-mo" for a split second before it "catches" and then is right.  But, unlike before this change, when it catches, it catches perfectly in sync.  And, the "slow-mo" period does not seem to vary.  It is always around one second long, no matter what the file is like or how much I've seeked around.

Also, what kind of hardware are you running on?  What is the JRMark score for the machine?

[jb5200]

OK so I dug up a bunch of info on my rig - Before I list everything this is a makeshift HTPC and it's only function is Audio/Video so I don't have it loaded with antivirus, software, etc. that would detract from music or movie performance and I only use JRiver as the player.  Here it goes:

HP(don't remember the model but it was top of the line 2 yrs. ago) w/Intel Core i7 920 @2.67Ghz with 9GB of DDR3 Ram/ Windows 7 64 bit Professional
Video Card - AMD Radeon HD 6670 1GB
Mediasonic HF2-SU3S2 box with 10 TB of storage (All of my movies are stored on here) connected eSATA, still having USB 3.0 issues so leaving it eSATA for now

MC17 settings:
Video Mode - Red October HQ
Hardware Accelerate Video Decode when Possible is CHECKED
Bitstream: YES
Videoclock: NOT CHECKED
Normalize Volume: CHECKED
A/V Synch correction milliseconds: 0
A/V Synch correction milliseconds: 0
Aspect Ratio Correction: NO CORRECTION
Aspect Ration Mode: NO CORRECTION

I think that's all of the settings that I would think would make a difference.  I didn't check any of the settings under Audio b/c like I said the audio was always fine but the video is what kept slowing down.  Just for tickles and giggles I watched another movie and it kept doing the same thing - slowing down every 20-30 sec but audio was fine, with the occasional sputter but veeeerrrrrrryyy occasional.

Please tell me it's my settings!

Thanks

[wer]

After waiting a while, I checked back in...

I must confess to being more than a little disappointed to find that MC17 development has now been concluded, and this issue was never fixed.  I bought MC17 as part of the "early adopter" program to upgrade from MC16, but I was never able to use it because of this issue.  I'm still using MC16, so my money was thrown away basically.

Yes glynor, my symptoms are still essentially the same as you describe.  I've posted specs (7x64, Core i5 4GB, Radeon HD4600) and JRMarks (3137) before; it's a fast machine and is dedicated to JRiver, no other software essentially except for DBpoweramp for ripping.  So speed isn't the issue.  This is a problem that appeared, as I said, midway through MC17 development.  Early MC17 versions were fine, as is MC16.  I now have tested MC17.0.183, Catalyst 12.6.  These latest versions have the same problem I have reported all along.

MC16 still works fine.  Somewhere along the way, the video output routines in MC17 developed a problem, and it has never been fixed.  It's that simple.

Not sure if there's any reason to believe it will be worked on in MC18.

This is very frustrating for me.  I would like to get what I paid for.  I would like to be able to support further development of JRiver MC18, and enjoy the new features that MC17 and MC18 will provide.  I love the software, and I think the company is a great one.

But I need the software to work properly for core functionality.  I will not through good money after bad.

If this issue is resolved, I would gladly purchase an another upgrade.

[JimH]

It's hard to "fix" a problem we don't see.

Did you try Red October Standard?

Turn off hardware acceleration if it's on.

[wer]

Yes, Jim.  As I said in the first post:  "It happes with both RO-Std and RO-HQ.   MC16 on the same machine works perfectly."

At Matt and Glynor's suggestions, I've tried with and without hardware acceleration, and with/without Video Reclock.

None of those settings make any difference.

My normal operating mode is to use RO-Std.

Unfortunately I don't have a log of exactly what dates I did upgrades to MC17 (I didn't anticipate it would be needed.)   But I can tell you the initial releases of MC17 did not have this problem (just as MC16 does not have it.)  Right before I posted on Jan 9th, this problem cropped up in the then-latest build of MC17, and it's been there ever since.  Only MC16 and MC17 version before then don't exhibit the problem.

Somewhere in the A/V  decoding/rendering changes that were introduced in MC17 at that time lies the answer.

Thanks...

[raym]

@wer - for what it's worth, I still see the exact same behaviour as described in your first post. I admit it's annoying but I'm kinda used to it. Where it's really annoying though is when I'm watching a television (.ts) recording (where I'm doing lots of jump seeks).

I know you've tried everything but in my case, I do get some improvement when I drop the audio buffer time way down. It doesn't completely solve the issue though and it tends to make the audio stutter a bit when I'm doing other things with the PC. So, not a great solution.

I started looking at this issue again recently and was surprised to see switching VideoClock off does not solve the issue either. Something else in the chain must be the cause. I'm using RO standard.