Print

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

[imcardle]

I'm having some trouble with fast forward and rewind in HD recorded TV programmes.  It works fine for SD programmes, but with HD if I press >> on my remote MC tries to fast forward at x5 speed but the actual observed speed is about the same (or slower) than normal playback (x1 speed)!

Any ideas why it is so slow?  See my profile info for system specs.

[RoderickGI]

Using my HTPC with the specs below, with only the built in HD4000 iGPU, and MC set to RO Std I can Fast Forward and Backward/Rewind at 5x, 20x, and 100x successfully when playing a 1440x1080i recorded program . . . but by fast forward I really mean that I see a slide show of frames even at 5x speed.

If you are using the Intel® HD Graphics 3000 iGPU in your Core i7-2700K, then it may struggle with fast forwarding, particularly if the source file is interlaced.

Check out the MC Benchmark thread for comparable machines, and see if you can work out if yours should be doing better. Also search around here for comments on the HD3000 iGPU performance. I know some people use them for RO Std like me, and get decent video, but I can't comment about Fast Forwarding with one.

Of course if you just want to move quickly through a program, use the left and right arrows instead, to jump forward and backward rather than Fast Forward and Backward. Hold the left or right arrow buttons to race through the file. The size of the jump can be specified in Options/Video/Advanced/Jump Behavior. You can also jump to any point in a file using the Slider in the Media Controls that show at the top of the screen when you move your mouse up there, and you can use the keyboard left and right buttons when the OSD slider is displayed at the bottom of the screen.

[imcardle]

Thanks for your reply RoderickGI, but I am not (yet) convinced that it is the built in graphics causing this issue.  I have previously been using Windows Media Center on the same hardware and that would FFWD and REW through an HD recording quite smoothly.  I tried using a tool called GPU-Z to monitor my GPU usage while an HD recording was being FFWD'ed - and the GPU usage dropped to zero!  There is no "slide show" effect like you described, it eventually jumps to a location further ahead in the recording - but it takes longer to get there than if I was playing the recording at normal (x1) playback speed.

My gut feeling is that something else is causing this issue - but I can't quite put my finger on it.  Any further suggestions would be much appreciated.

[RoderickGI]

I think this is one for the developers. I would like to see an improvement in FF and REW quality myself.

Maybe if you captured a log of trying FF and REW, someone would take a look at it. There may be some indication in there what is happening.

[imcardle]

Thanks again for your support RoderickGI.  I've captured a log file where I tried to play the HD recording of a programme called "Cuffs", hit the skip forward button a couple of times (it took about 6 seconds to move 30 seconds forward in the recording) and then I pressed FFWD and waited for it to step forward a couple of times (it took about 11 seconds to move forward 1 second in the recording).  Hopefully the developers will see this thread and check the log file - unless there's some other way to bring it to their attention?

[RoderickGI]

Usually the developers only want users to send or post a log if they ask. So best to just leave it here for a bit and see if you get a response.

Your post will definitely be seen by JRiver personnel. They read them all, but can't respond to every one. Let's see how we go here.

[Yaobing]

I will download and read that log on Monday.

[imcardle]

Hi Yaobing,

Did you find any clues in that log file?  If you need any further information please let me know.

[Yaobing]

Sorry, I was not able to get to it.  Next Monday perhaps.

[Yaobing]

I think I found something.

Please try this patch: https://www.dropbox.com/s/an7xmwbscf9n3ct/MJTSFileReader.ax?dl=0

Download it, and copy to [MC21 installation folder]\TV\ Subfolder.

[hoyt]

I recently noticed this too, but it was only with one TV program and thought I'd check to see if I could replicate it after recording another one of the same type (1080i).  Is the referenced patch file ok to use on another system, or is that just for debug for the original post?  Thanks!

[Yaobing]

I recently noticed this too, but it was only with one TV program and thought I'd check to see if I could replicate it after recording another one of the same type (1080i).  Is the referenced patch file ok to use on another system, or is that just for debug for the original post?  Thanks!

It can be used on any Windows system with MC21.0.23 or 24.

[imcardle]

Hi Yaobing,

The patch works for me.  At first I thought it didn't work - but it looks as though the patch is only loaded after a reboot.  Before the reboot I guess MC just uses whatever version of that file is loaded in memory?

I look forward to seeing this fix in a future build.

Thanks very much for your support!

[Yaobing]

The patch works for me.  At first I thought it didn't work - but it looks as though the patch is only loaded after a reboot.  Before the reboot I guess MC just uses whatever version of that file is loaded in memory?

Not sure why it did not work initially. If MC was running at the time when you tried to copy the file, you would not be able to copy.

Anyway, I am glad it is working now.

I look forward to seeing this fix in a future build.

Look for this in history for MC21.0.25 which hopefully will be available soon:

3. Fixed: When TV time-shifting reader filter performed seeking, it could try to wait for more data to be buffered than the buffering reader was set to buffer, resulting in unnecessarily long wait.

[imcardle]

Might the reason that it did not work initially be because I renamed the old file before copying the new one into the same folder?

[RoderickGI]

I installed this new Direct Show Filter to see if it improved my Fast Forwarding as well. It didn't. I still get a slideshow of frame grabs. A reboot made no difference either. But that's okay, as I didn't expect it to help. My PC doesn't have the power to do better.

I can share though that I also renamed the original file in place, and copied the new file into the directory, all while MC21.0.24 was running. I was expecting to be prevented from doing that, as it is a registered Direct Show Filter, but no, I was allowed to do that, and I could immediately play and Fast Forward a TV show.

I checked and there are no other copies of the filter on my system, in Windows/System32 or anywhere. I guess that makes sense as MC manages and uses its own set of Direct Show Filters, rather than installing them generically on the PC. At least, I think that's what MC does.

[Yaobing]

I installed this new Direct Show Filter to see if it improved my Fast Forwarding as well. It didn't. I still get a slideshow of frame grabs. A reboot made no difference either. But that's okay, as I didn't expect it to help. My PC doesn't have the power to do better.

I forgot to explain.  In MC fast forward is not really playing the video at a fast speed smoothly.  It is skip-and-still-image.

[hoyt]

This patch didn't seem to address the issue I was seeing...  When I monitor my LAN on normal playback of this football game, MC is taking ~20mbps.  When I fast-forward (using the jump-30 seconds ahead), and I hit the forward key 4 times (2 minutes), my router goes bizerk.  MC then hangs for approximately the same time.  For example, if I fast forward just 30 seconds, it takes about 30 seconds for MC to respond.  After the patch it does the same thing, but also consumes massive LAN bandwidth before starting the playback.  Only did it once, so not sure if that matters, but it did not do that previously.  I would hit play and it almost immediately started playback.

This isn't happening with everything for me, I've only noticed on my two recent recordings of the same program (704x480, 59.94 fps, 17GB ~4 hours).  I just watched something recorded on the same channel, same specs, but it was only 30 minutes long and it had none of the ffwd delay issues.  Perhaps it something that I did, but seeing the bandwidth jump like that made me think it was related to what you had mentioned (unnecessary data buffering).

Thanks!