Just to be clear, you were not playing a video when the problem you described occurred? It was most likely caused by Auto Importing or Thumbnailing. These are the two things that could use DirectShow in the background.
Did you actually revert back to build 456 and verify that the problem only occurs in the new build? I ask this because there is a possibility that you had no problem in the earlier build simply because the background tasks that were causing the problem were not happening.
When Haali Media Splitter is loaded in the background, it tends to have issues like you describe when it cannot find a decoder filter that works well. Therefore the problem may well be the lack of FFDShow on your computer. Installing CCCP has helped solve a lot of problems similar to this one.
Hi Yaobing,
Thanks - yes, I did revert back. For the last few builds, I have tried the new one, found a lack of success, and then gone back to 456.
I did some more testing, and I think I found the problem... Not a solution yet, but perhaps this will help you advise me what to try next? I enabled logging, and searched the log for what may be happening. This is an example of what is appearing many times:
0085797: 2644: Playback: FileCanPlayInDShow: Testing: M:\mydirectory\myfile.m4a
0085797: 2644: Playback: CDShowFileRenderer::RenderFile: Start
0085797: 2644: Playback: CDShowFileRenderer::LoadSourceFilter: Start
0085797: 2644: Playback: CDShowFileRenderer::LoadSourceFilter: Finish (0 ms)
0085797: 2644: Playback: CDShowFileRenderer::RenderFile: LoadSourceFilter returned 0x80004005
0085797: 2644: Playback: CDShowFileRenderer::LoadTransformFilters: Start
0085797: 2644: Playback: CDShowFileRenderer::LoadTransformFilters: Finish (0 ms)
0085797: 2644: Playback: CDShowFileRenderer::RenderFile: LoadTransformFilters returned 0x1
0085797: 2644: Playback: CDShowFileRenderer::LoadSourceFilter(2): Start
0085797: 2644: Playback: CDShowFileRenderer::LoadSourceFilter(2): Finish (0 ms)
0085797: 2644: Playback: CDShowFileRenderer::LoadSourceFilter(2): Start
0085797: 2644: Playback: CDShowFileRenderer::LoadSourceFilter(2): Added the filter to graph
0085797: 2644: Playback: CDShowFileRenderer::LoadFileUsingSourceFilter: Start
0085797: 2028: Playback: CDirectShowPlaybackTester::GetCanPlayInDirectShow: Event code: 0x1e Params: 0, 0
0085797: 2644: Playback: CDShowFileRenderer::LoadFileUsingSourceFilter: Load returned 0x0
0085797: 2644: Playback: CDShowFileRenderer::LoadFileUsingSourceFilter: Finish (0 ms)
0085797: 2644: Playback: CDShowFileRenderer::LoadSourceFilter(2): Finish (0 ms)
0085890: 2644: Playback: CDShowFileRenderer::RenderFile: RenderOutputPins returned 0x0
0085890: 2644: Playback: CDShowFileRenderer::RenderFile: Finish (93 ms)
0085906: 2644: Playback: FileCanPlayInDShow: Can play: 1, Audio: 1
So it seems it's going through and testing many many (I think all) of my m4a files to see if they play in directshow. I did not have dshow playback enabled for m4a (i.e. if I play such a file in MC then Haali doesn't load). I tried enabling Dshow playback for m4a, just to test it, and the playback is fine.
So I think what is actually happening here is that MC is testing all those files, each of them is a 'success', it just keeps on going. And going. So Haali is being loaded again and again. I actually tried leaving it alone, and 5 minutes later it had finished and all was back to normal. Not that I want to leave MC for 5 mins each time to start up, but it's a workaround of sorts!
I tested with build 456, and those 'tests' are simply absent from the log.
So my question is - why is MC running those 'can I play in Dshow' tests on ALL my m4a files? Not even sure why it wants to test one of them, since I don't have .m4a set up for Dshow playback, but if it WAS just one it wouldn't matter!