Print

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

[rpalmer68]

In recent builds I've noticed that after starting MC it is almost totally unusable for about 7 minutes after running for about 1 or 2 minutes.

I can't navigate around in theater view as it's so slow and video playback/TV playback is choppy.

Upon investigation JWorker.exe sits around 50 to 70% cpu in task manager during this time and looking at the logs it seems to be while thumbnails are build biult after the first auto import.   (Which currently imports about 25 video files)


If I turn off the option to build thumbnails on auto import, that improves things but as soon as I start navigating around in Theater View and browse to my views with my Video recordings (that are imported with auto import) MC grinds to a halt while the thumbnails build.

I'm running XP SP3 on a Quad Core Intel processor @ 2.66Ghz so really don't expect to see this level of slow down from MC.

Have update DirectX to latest version and the latest ATI drivers for my 4850 GPU.

I thought thumbnails were being done in their own core now on multi-core processors?

Richard

[fitbrit]

I do notice a slow thumbnail building too. I considered that this may be due to the cover art being stored on an unraid server, and that the disks may need to be spun up. However, it's still pretty slow even factoring those details.

[raym]

I do notice a slow thumbnail building too.

Thought it was just me.. Pretty sure it's thumbnail related in my case too. Sometimes I'll start MC at it'll be unresponsive for 5-20 seconds. Havn't seen this kind of problem in MC for ages.

I'm using a shared (networked) db so that may have something to do with it. I can't say I've seen this issue with a local instance.

[rpalmer68]

Thought it was just me.. Pretty sure it's thumbnail related in my case too. Sometimes I'll start MC at it'll be unresponsive for 5-20 seconds. Havn't seen this kind of problem in MC for ages.

I'm using a shared (networked) db so that may have something to do with it. I can't say I've seen this issue with a local instance.

I can have MC unresponsive for 5 to 10  seconds on load too, but this issue is for like 7 minutes, MC still responds but VERY slowly making navigation/use hopeless until it finished building thumbnails for the newly imported files.

The files being imported are on a local drive, but the library is on a NAS although opened read only.

R

[Matt]

What file types are being thumbnailed?  Does it need to use some fancy filters to render a little bit of the movie?  How does thumbnailing in Windows Explorer compare?

Since thumbnails happen in a low priority thread that runs a low priority process for videos, it seems like it should never interfere with the main program.

[leezer3]

This may or may not be related, but I've posted in the past about removing files from the Recently Imported view.
More often than not, these are videos with the thumnailing in process, and it quite regularly causes 10- 20second hangs.

The database is local, but pretty much any file getting newly imported is on a network server.
Am I seeing a pattern whereby one part or the other is located on a network drive?

-Leezer-

[rpalmer68]

What file types are being thumbnailed?  Does it need to use some fancy filters to render a little bit of the movie?  How does thumbnailing in Windows Explorer compare?

Since thumbnails happen in a low priority thread that runs a low priority process for videos, it seems like it should never interfere with the main program.

They are MPEG (.mpg) files.

Even with MC otherwise idle, Media Center14.exe and JWorker take the CPU to over 88% while the  thumbnails are generated.

Here is a log from MC being launched until things settle down. 

During these several minutes my total CPU ranged from 31% to 100% with Media Center 14.exe peaking at about 25% and up to three JWorker.exe processes each taking up to 25% as well!

No wonder the system grinds to a halt!

I've only recently started to notice it being this bad, and in fact in the last week or so I've noticed a noticable increase in the number of times video will stutter (I think from high CPU spikes) during playback even after the system has settled down.

Richard

[Matt]

During these several minutes my total CPU ranged from 31% to 100% with Media Center 14.exe peaking at about 25% and up to three JWorker.exe processes each taking up to 25% as well!

Normally if you start a low priority thread and work like crazy in it, it won't be noticeable because the system only gives the thread cycles when there's nothing else to do.

So it should be alright for a background process to use even 100% of the CPU.

However, it seems like the priority part of the thumbnailing isn't right.  We set the process priority of JRWorker.exe to the lowest, but DirectShow sets its own thread priorities when rendering the file, and perhaps this is the problem?  It's also possible that hardware acceleration is getting invoked or video memory allocated which could cause a weird slowdown?

[rpalmer68]

Normally if you start a low priority thread and work like crazy in it, it won't be noticeable because the system only gives the thread cycles when there's nothing else to do.

So it should be alright for a background process to use even 100% of the CPU.

However, it seems like the priority part of the thumbnailing isn't right.  We set the process priority of JRWorker.exe to the lowest, but DirectShow sets its own thread priorities when rendering the file, and perhaps this is the problem?  It's also possible that hardware acceleration is getting invoked or video memory allocated which could cause a weird slowdown?

The strange thing is I'd don't ever remember seeing this issue in the past (like a month ago) ... I'll have to go back and try MC13 with the same set of files, but I'm sure it didn't do this.

Cheers
Richard

[glynor]

Just a note... I used to have all KINDS of problems with this when it was building video thumbnails on my system.  Even a quite powerful PC (Q9550 @ 3.6GHz with 4GB RAM) was brought to it's knees when MC would try to thumbnail a folder full of new 720p x264 MKVs.  The issue has been present for a long, long time with multiple versions of MC.  I pleaded for help on this repeatedly, asking that all thumbnailing activities be suspended at least while full-screen playback is active (to not interfere with smooth playback while you are obviously busy watching something in the foreground).  But, no action was ever taken on this request...

However, I was able to solve it completely with a simple, cheap, purchase that has been really helpful in a number of other ways: CoreAVC.  I think FFDSHOW just doesn't respect priorities well, and doesn't react well to generating multiple thumbnails of HD content the way MC wants to do it.  With CoreAVC installed and selected as the default MPEG-4 decoder on the system, my issues vanished completely.

[rpalmer68]

 I pleaded for help on this repeatedly, asking that all thumbnailing activities be suspended at least while full-screen playback is active (to not interfere with smooth playback while you are obviously busy watching something in the foreground).  But, no action was ever taken on this request...

I'd second this request.

[raym]

I'd just prefer performance of the thumbnailing is restored to how it used to be. As you've mentioned already, this has only been an issue recently.

[rpalmer68]

I'd just prefer performance of the thumbnailing is restored to how it used to be. As you've mentioned already, this has only been an issue recently.

I think the issue is that several jworker.exe processes are now being used to generate the thumbnails, so it's done a lot quicker but at the expense of system performance.   I'd like to see thumbnailing go back to just one process, but also think stopping thumbnailing in the background during video playback would fix the last of the playback stutters I get from time to time.

Richard

[raym]

but also think stopping thumbnailing in the background during video playback would fix the last of the playback stutters I get from time to time.

I guess the point I'm trying to make is I'd prefer background thumbnailing to stay but the associated performance degradation to be resolved because unless it is resolved, we're likely to just experience related issues when trying to navigate around in Theater View (for example). Preventing thumbnailing during fullscreen playback will avoid some of your video stuttering issues (possibly) but it's not a real solution to the problem IMO.

Cheers.

[glynor]

I guess the point I'm trying to make is I'd prefer background thumbnailing to stay but the associated performance degradation to be resolved because unless it is resolved, we're likely to just experience related issues when trying to navigate around in Theater View (for example). Preventing thumbnailing during fullscreen playback will avoid some of your video stuttering issues (possibly) but it's not a real solution to the problem IMO.

I agree.  Unfortunately, I doubt that there is much they can do about the performance of a third-party decoder like FFDSHOW, which is really the root of this issue.

Some things you can do to help reduce (but probably not eliminate) the issue:
1. Turn off any and all Video postprocessing (deinterlacing, post, sharpen, filtering, etc) done in FFDSHOW by default.  If you want these to be done on-demand when watching files, add them to a non-default profile, and activate it on-the-fly when needed.
2. Change FFSHOW Video decoder "multiple instances" control to "No Limitations".  This is in the FFDSHOW Video Decoder Configuration utility, under DirectShow Control.
3. Try enabling Queue support in FFDSHOW.  This enables some more intelligent queuing of decode jobs, but isn't widely supported by some hardware configurations.  I don't know if it will work with MC well, but it seemed to with my limited testing.  NOTE: This will have the largest impact if you have a dual-core or better CPU that has multiple thread hardware support.  To enable Queuing support, follow these steps:
3a. In the FFDSHOW Video Decoder configuration utility, go to the Queue and Misc "tab" (from the tree on the left-side).
3b. Check the Queue output samples box.
3c. UN-check the Use queue only in: box (or add MC to the list)
3d. Enable queue in VMR9-YV12 (this may cause problems with Intel integrated graphics hardware)
4. Make sure all SMID instructions support is enabled (under Info & CPU in the FFDSHOW Video Decoder configuration utility).

Again, if you want to really SOLVE the problem once and for all, simply buy CoreAVC, which is available for only $15 US.  For me, after testing out the trial, the $15 spent on CoreAVC was WELL WORTH my time and effort spent trying to solve this and other performance problems with HD MPEG-4 ASP and AVC playback.  It also solved a problem I'd been having with BeyondTV completely, and I really feel that the quality is much better as well.

It has far fewer Post-Processing capabilities, but you could always route through FFDSHOW for post-processing if you wanted on-demand.  I, personally, haven't seen the need as quality has been very good out-of-the-box.

[rpalmer68]

I'm not using FFDSHOW  for .mpg files, plus they are not HD recordings so coreAVC won't actually decode them anyway will it?

If MC limited thumbnail building to just one jworker.exe process that would also help I would think.

R

[glynor]

Wow... You're seeing issues with vanilla MPEG-1 files?  What kind of ancient machine are you running it on?  If it isn't ancient, you probably have other issues, or aren't seeing the same issue that I am.

EDIT: Sorry, hadn't read every single post above very well, and skimmed most of it.  I don't think you should see issues like this with MPEG playback, unless something else is going on.

[rpalmer68]

Wow... You're seeing issues with vanilla MPEG-1 files?  What kind of ancient machine are you running it on?  If it isn't ancient, you probably have other issues, or aren't seeing the same issue that I am.

EDIT: Sorry, hadn't read every single post above very well, and skimmed most of it.  I don't think you should see issues like this with MPEG playback, unless something else is going on.

LOL, it's the machine you helped me overclock.... and she's going great thanks!

Some of my files are HD some SD so maybe it's the HD ones slowing things down. But it was never a problem with MC13.

I think becuase multiple jworker threads are being started in MC14 now they are pulling too much CPU, sure it could alsobe  filter related but if we just had one thumbnailing thread I'm sur my quad core could cope!  Let's face it MC as to cope with lots of flter combinations we can't say "hey if you want MC to be usable while it's building thumbnails you have to buy a special filter"

I got the frame rate display up in theater view during this slowness at it drops down to 8 FSP (from 60 when everything is normal).

Richard

[glynor]

If they're HD MPEG files, they can't be "typical" MPEG-1 files.  While officially the MPEG-1 standard can encode up to 4095x4095@60fps, typical "MPEG-1" files used are actually of the MPEG-1 CPB subtype (Constrained Parameters Bitstream), which is limited to the MPEG-1 SIF (Source Input Format) which is 352x240@30fps (NTSC) or 352x288@25fps (PAL).  Going any higher than that on a MPEG-1 stream is really a huge waste of resolution because the MPEG-1 compression will turn it into a blocky mess no matter what resolution you feed in and out of the codec.

I've actually NEVER seen an MPEG-1 encoded stream at higher resolution than SIF.  Ever.  It just isn't done, and the encoder software apps don't support it.

It is far more likely that they are actually MPEG-2 video streams in a MPG wrapper.  HD MPEG-2 streams are far more simple to decode than, say, H264 or VC1 streams, but still require an external decoder (probably FFDSHOW) and loading multiple instances of FFDSHOW is almost certainly your problem.  That, or they're actually mislabeled MPEG-2 TS containers with even H264 (MPEG-4 AVC) content inside.  Open one of them with MediaInfo and see what the actual stream is inside of the file.

Did you try any of the FFDSHOW tweaks I mentioned above?

That said, I agree fully that the Thumbnailing in MC is far too aggressive by default.  I think perhaps you should be able to "turn it up" if you have a machine and filters that can handle it, but by default it should be much slower and more careful about system resources.

[rpalmer68]

Did you try any of the FFDSHOW tweaks I mentioned above?

Are you suggesting that FFDSHOW is being used to thumbnail even though I'm using The Cyberlink Video Decoder... must go back and check the logs...?

I don't know what the mpeg files really are to be honest, MC reports them as 1920x1080 and a 2 hour show is about 13GB.

The thing is this had gotten worse in recent times using the same codecs for some reason, in fact I was watching a recorded show tonight and got a couple of major "stutters" during the 1 hour show. Both around the time other recordings would have been finishing. 

I'll have to try different codecs I guess, but I've domne a LOT of testing to get the almost perfect smooth playback I now have and know different codecs won't give me the best result.

Cheers
Richard

[glynor]

Are you suggesting that FFDSHOW is being used to thumbnail even though I'm using The Cyberlink Video Decoder... must go back and check the logs...?

Naah.  Made a bad assumption.  I've had problems in the past with the Cyberlink decoders (but that was long, long ago).  It is likely that they just aren't playing nice with multiple instances being loaded.  I'd be almost certain that they're MPEG-2 streams in there, assuming they are actually MPG containers and not misnamed.

Either way, there are many, many many filters that don't play well with multiple instances running simultaneously.  Yet one more reason that we need the background auto-thumbnailing routine to suspend while full-screen playback is active.

[rpalmer68]

Either way, there are many, many many filters that don't play well with multiple instances running simultaneously.  Yet one more reason that we need the background auto-thumbnailing routine to suspend while full-screen playback is active.

Even disabling while video is playing doesn't help general usability when running theater view, I can't use MC at all for about 7 minutes after it loads due to all the jworker threads taking over.

Maybe we could have two thumbnailing options  
1) Build Thubmnails + # of processes (So a dropdown list No, Yes - 1 process, Yes - 2 processes etc)
2) Suspend thumbnailing when playing fullscreen video


Matt - could/would this be possible please?

Richard

[rpalmer68]

 It isn't only thumbnailing, other background processes are spawing multiple jworker.exe threads slowing the system down.  I assume it's probably auto-import as this also loads the video files to confirm what type they are I think.  But while these multiple jworker.exe threads are hogging 60 or 70% cpu navigating Theater view is basically impossible.


Richard

[MrHaugen]

Just a note... I used to have all KINDS of problems with this when it was building video thumbnails on my system.  Even a quite powerful PC (Q9550 @ 3.6GHz with 4GB RAM) was brought to it's knees when MC would try to thumbnail a folder full of new 720p x264 MKVs.  The issue has been present for a long, long time with multiple versions of MC.  I pleaded for help on this repeatedly, asking that all thumbnailing activities be suspended at least while full-screen playback is active (to not interfere with smooth playback while you are obviously busy watching something in the foreground).

I've had the same problem with HD content as well. I think that even before I had any HD content (and the version was 13 and 12), the Full Screen playback would skip at times. I've messed up some times when moving movies into the right directories before I'm watching a movie. I'd vote for a "no thumb building when video watched". Would sort out some problems. I think my problems have ben less since I've started using CoreAVC my self though.

[rpalmer68]

Matt - Any thoughts further on this please?

Tonight while watching a TV recording twice my playback stuttered badly for about 5 seconds both times, and both times were when a background recording would have recently finished.

Both the recordings were SD TV recordings so no HD content issues here.

MC13 used to have very minor stutters but the MC14 ones are really bad.  I've tried different codecs/filters and  I haven't seen any real improvement.

Could we PLEASE have a way of limiting the number of JWORKER.exe threads or halt thumbnailing during full screen playaback???

Thanks
Richard

[rpalmer68]

Sorry to go on like a broken record, but this is still an issue for me......

To further try to narrow this down I have setup my two PCs as close to the same as I can.

I'm running the same Cyberlink video/audio decoder and VMR7 on both. (YES I have tried different decoders)

HTPC1 is an Intel quad core running at 2.66Mhz and 4GB RAM
HTPC2 is an old P4 3.2Ghz with 2GB RAM

Both machines are auto-importing from the same shared folder (T:\) and have build thumbnails turned ON.

Both machines open the library read ony, so the files to be autoimported are NOT in the library being opened.

There are 57 .mpg TV recordimngs in T: most are SD with a few being HD (but still .mpg files so no idea what they really are, but they are a LOT larger then the SD files!)

If I load MC on both machines here is what I find;

• HTPC2 stays usable throughout, but auto-import takes a lot longer to import and thumbnail the video files.
  
• HTPC1 imports and thumbnails the videos a lot faster, BUT during this time (several minutes) I cannot use the PC at all, it can take 20 seconds just to bring up the "tools" menu in standard view

In general daily use, when playing back a video HTPC2 will have a VERY slight stutter (maybe a couple of frames) when a new file is imported, while HTPC1 will have a major stutter lasting a couple of seconds or more when it imports the same file during playback.

Would somebody else running a multi-core processor be able to test this for me please?
1) Setup a new folder for auto-import to monitor and ensure Build thumbails is enabled in the import options.
2) Close MC
3) Dump 50 .mpg files into the new folder
4) Launch MC and try to navigate around for a few minutes, you should find MC becomes totally unusable during this process (I hope)

Many thanks
Richard

[JimH]

I'm running the same Cyberlink video/audio decoder and VMR7 on both. (YES I have tried different decoders)

I had a problem a few days ago (sorry I don't remember the details) that was solved by moving to MS filters.

Shared folder on a network drive?

[rpalmer68]

I had a problem a few days ago (sorry I don't remember the details) that was solved by moving to MS filters.

Shared folder on a network drive?

Was it the same symptoms or a different problem? 

T: is actually a local drive on HTPC1 shared so HTPC2 can access it.

[raldo]

Matt,

Adding a System.Thread.Sleep(10) (or whichever equivalent you're using) in the thumbnailing loop may improve the situation. I don't think this'll make thumbnailing significantly slower.

I've done this a few times without really knowing why I had to do it.

And yes I know, this kind of defies the whole point of thread priority, but if it works, it works...

[rpalmer68]

This is STILL a big problem here.

Last night I was watching a movie with my wife, and duruing this time three TV recordings finished, so three times the movie stuttered for a few seconds and we had to rewind to hear what was said.

This is not happening anywhere near as badly on my older Pentium4 PC or for that matter with MC13 on my multi-processor system.  In fact I'd be confident in saying it started to stutter this badly when the mult-core changes were made for auto-import a while back.

Richard

[JimH]

rpalmer,
Do you have cyberlink filters installed?

Jim

[rpalmer68]

rpalmer,
Do you have cyberlink filters installed?

Jim

Jim, if you read my previous posts you'd know the answer to this.   

Yes, I use the cyberlink filters as they produce the best visual results on my system.  I have also pointed out that different filters do the ame thing.

Cheers
Richard

[JimH]

Jim, if you read my previous posts you'd know the answer to this.   

I don't read the entire thread each time I answer.  Sorry.

I have had stuttering problems for about a month.  It's about the same period of time that I've had some CyberLink software installed.  I installed it when I added a Blu-Ray player to my PC.  It may not be relevant.

[rpalmer68]

I have had stuttering problems for about a month.  It's about the same period of time that I've had some CyberLink software installed.  I installed it when I added a Blu-Ray player to my PC.  It may not be relevant.

It may be related to having the Cyberlink decoders installed, but I somehow doubt it.

I have done further testing with the latest build, and I can confirm that it makes no difference if I have the Cyberlink, Dscaler or ffdshow filters selected for .mpg playback the slowness while my recordings are being imported is exactly the same.

And I don't just mean stuttering during video playback, it can take several seconds to change a view in Theater View or even get a menu up in standard view... the CPU is basically maxing out during the import!

Richard

[JimH]

It may be related to having the Cyberlink decoders installed, but I somehow doubt it.

I have done further testing with the latest build, and I can confirm that it makes no difference if I have the Cyberlink, Dscaler or ffdshow filters selected for .mpg playback the slowness while my recordings are being imported is exactly the same.

And I don't just mean stuttering during video playback, it can take several seconds to change a view in Theater View or even get a menu up in standard view... the CPU is basically maxing out during the import!

It may be our problem, but I don't see how.  Even for you, it works on other machines, right?

Look again at what else is running in the background.

[rpalmer68]

It may be our problem, but I don't see how.  Even for you, it works on other machines, right?

Look again at what else is running in the background.

Nothing else is running in the background, it can't! JWorker.exe is taking over all the CPU cycles.  I can have up to four of them (jworker.exe) running all taking at least 20% CPU.

Yes correct it is all working fine on the other machine, but as pointed out the machine having problems is the ONLY machine I have with quad cores, the other machine is single core, and this problem only started when MC was changed to use multiple cores for auto import etc.  

There has always been a  slight stutter when auto-import/thumbnails were built previously and I agree with others posts that thumbnailing should be suspended during full screen video playback, but the stutter is minor compared to what is happening now.

So I still think there is an issue with the multi-core background processing somewhere. Sure it might be a directshow issue not folowing the priority setting rather than a direct MC issue, but MC needs to cope with this as we all have to run directshow so it's not going to just go away on it's own.

I have deatiled how to test this, so until somebody else can tell me they have done the same as I'm doing and it all works fine, I'm going to have to still believe it's a MC issue rather than a machine specific issue with my machine.


Cheers
Richard

[JimH]

If it is a DirectShow filter causing the problem, I don't think there is anything that MC can do.

Without reading the entire thread again ... have you tried to see if you can narrow down the problem to a single filetype?

[rpalmer68]

If it is a DirectShow filter causing the problem, I don't think there is anything that MC can do.

Yes there is, go back to the way it USED to work without the multi-core support, it was MUCH better! )Sure auto-import is much fatser... but at what real cost in terms of the user experience?)

Or at least let us select how many cores MC will take over and disable thumbnailing during full screen video playback.

Richard

[JimH]

Yes there is, go back to the way it USED to work without the multi-core support, it was MUCH better!

Or at least let us select how many cores MC will take over!

Richard

Richard,
I really think you're barking up the wrong tree.   See my previous post (edited).

Jim

[rpalmer68]

Richard,
I really think you're barking up the wrong tree.   See my previous post (edited).

Jim

All my recordings are .mpg files and I can't change this, so it's a bit hard to test importing 30 files of a different file type.

Also remember that just browsing theater view or using the PC in general  is VERY SLOW while the import is happening so it's not just during video playback.

Also note that the SAME files using the SAME filters on the SAME machine under Mc13 DO NOT have the same problem, it's ONLY MC14 with builds after multi-core support for auto-import was added.

I can go and try to convert all my recordings to another format I guess and try that, but would really lile to hear Matt's opinions on all of this before I spend lots of time converting files.

Cheers
Richard

[JimH]

All my recordings are .mpg files and I can't change this, so it's a bit hard to test importing 30 files of a different file type.

Also remember that just browsing theater view or using the PC in general  is VERY SLOW while the import is happening so it's not just during video playback.

Also note that the SAME files using the SAME filters on the SAME machine under Mc13 DO NOT have the same problem, it's ONLY MC14 with builds after multi-core support for auto-import was added.

I can go and try to convert all my recordings to another format I guess and try that, but would really lile to hear Matt's opinions on all of this before I spend lots of time converting files.

Cheers
Richard

Try thumbnailing another type of video or try changing the filters for mpg.

[rpalmer68]

Try thumbnailing another type of video or try changing the filters for mpg.

This is going nowhere, as I have already answered both of these in previous posts.

[JimH]

I'll let you work on this a while.   Everything you say points to problems with the filters.

[rpalmer68]

I'll let you work on this a while.   Everything you say points to problems with the filters.

OK Jim you do that.

But before I spend more of my time testing and trying to debug your software for free, please explain the following;
1) why MC13 does NOT have the same problem with the SAME files, SAME filters on the SAME machine?  If it was a filter problem MC13 would also have this problem would it not?
2) Why do ALL filters I have tried, Dscaler, NVIDIA, FFDSHOW, Cyberlink ALL do the same thing?   IF ALL filters have the same problem, then  it's something MC is going to have to deal with a little better than it currently does.



Richard

[JimH]

Richard,
If I could explain what happens on computers, I would be drinking a beer and fishing on a beach in Australia instead of trying to help you with this problem.

Jim

[rpalmer68]

Richard,
If I could explain what happens on computers, I would be drinking a beer and fishing on a beach in Australia instead of trying to help you with this problem.

Jim

Very true, but I don't know what else I can test/change that will show you it's not somethig I believe I can fix at this end, MC is starting too many threads during an import and it's bringing the machine to it's knees.  Sure it might be the way directshow filters work, but directshow isn;t going away ay time soon so MC is going to have to work with the issue somehow (like going back to not using multiple treads for importing).

It's like a car, it's not the car's fault people drive into trees and other cars, but they had to introduce seat belts to try to help minimise the "impact" of it happening.

I'll spend the day converting all my files to .avi files and testig with them, but I honestly don't think it will prove anything new.

Regards
Richard

[JimH]

avi is a container format and won't prove anything.  Find some files on the Internet to test.

[rpalmer68]

avi is a container format and won't prove anything.  Find some files on the Internet to test.

I have a lot of files from the internet, (TV series etc) but they are all .avi files, what format would you suggest then?

[Daydream]

Can we stay a second more with your MPG files? What's the source for them? DVD rips, broadcasts, home made, something else? What are the filters used when you play one of these files? I'm aiming not only for the Cyberlink Video decoder but also what is the splitter filter used. If you use a mixed combination certain filters may work together but not very well, resulting in unnecessary long time to parse the files and decode them properly.

I have tried to replicate your described behavior but couldn't really. Maybe there is a penalty when files are indexed/thumbnails are created but that's only if I lock an arrow key and force the program to scroll at max speed for no good use. It's light years away from the slowness you describe. Something's not OK. I have seen this behavior with MC struggling to create thumbnails for certain files (with CPU % shot to hell) but that was only when the DirectShow decoding chain wasn't the best. That's why I'd like to know what are all filters used on your side for MPG.

As a rule of thumb I'd use filters from the same source - all Microsoft, all Cyberlink (and unrelated to your problem I have zero confidence in these ones) or, my fav choice, the filters from MPC-Home Cinema (all of them, file source, splitters, decoders, etc). But that's just me.

[raym]

Richard, I know we have similar setups but my htpcs are dual cores only. I too see what you describe but very rarely and no where near as severe as you describe.

As a work-around, you could disable auto import and script a job to import files only when mc is idle.  I have some ideas on this if you're interested.