Print

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

[MarkGrigsby]

I'm having the same problem here I reported in the 481 thread.  There is still an issue / bad interaction with Haali media splitter.  Starting MC12 is fine, but after about a minute the Haali media splitter taskbar icon flashes on and off repeatedly.  If playing, at that time any playback stops.  Build 456 did not have this problem.

I verified this behaviour on 2 PCs, whose general configurations are different (both running Vista), but have a recent Haali (Matroska splitter) installed.

Someone suggested in the other thread for me to update my video codecs - well, I have pretty recent codecs installed, and don't want to mess with those which are working fine elsewhere on my system.  Surely the fact that MC 456 works and the newer builds have this problem indicates it's a MC issue??

[leezer3]

Its codecs-
http://yabb.jriver.com/interact/index.php?topic=40613.0
Explored pretty much in depth here, the cause is a dodgy FFDShow version. Update & you should be good; No idea why particular builds trigger this behaviour, but its 100% not MC

Cheers

-Leezer-

[MarkGrigsby]

Thing is - I don't have FFDshow installed!  Only codecs I have are Cyberlink's for H264 playback.

I'm still not convinced how it's not a MC12 issue - since the older build worked fine, and the new one doesn't.  Okay, so in the case of FFDshow there is a workaround, but surely the root cause must lie in MC12?

It's really bugging me now since all new builds are no-go for me until it's fixed.  Or I uninstall Haali's splitter which would inconvenience in another way...

[JimH]

Try glynor's DirectShow Playback Guide in our wiki.   CCCP usually solves problems.

[MarkGrigsby]

I have NO issues with my directshow playback, and MC 12 worked fine in an earlier build.  The latest ones cause this issue.  I do now want to install the CCCP since I am very happy with the playback I have with my current filters.

[JimH]

Did you read the DirectShow Playback Guide?

There are gotchas with some filters, and I think you've found one.

[MarkGrigsby]

As for the directshow guide - I don't think I do have a directshow problem!  I am not trying to use MC 12 to play such files.  I simply open MC, and playing an MP3 file results in the error.

Since there are 2 builds of MC - one older, one newer - and one works and the other doesn't.  How can this not be a MC bug?  I am happy to try suggestions on how to workaround it, but I do not want to screw up some otherwise impeccable HD playback via MPC by installing other codecs, which I honestly don't think I need.  In case you wonder why I use MPC for such playback - the EVR custom mode gives me a better PQ than I can get from MC, at least the last time I tried!

[leezer3]

Cyberlink are just as bad as a buggy DirectShow version- Full of holes 
Notice that they refuse to support any application other than their own player. See this thread here for an example of the problems it can cause-
http://www.kmplayer.com/forums/showthread.php?t=5315
Plenty more bugs in it out there, you've just found one. Either update the Cyberlink filters or remove them altogether- Just because an application breaks doesn't mean that its the root cause of the problem (Just as an example, a video may use a non-standard way of interfacing with the graphics render. Another set of filters uses the 'standard' way of doing things & a small tweak is made to accomodate them, in the process breaking the non-standard variant- Would you rather have a kludgy fix for the non-standard, or a more reliable overall set of stuff?)

Cheers

-Leezer-

[JimH]

As for the directshow guide - I don't think I do have a directshow problem! 

I was beginning to get that, but I do think it's a DirectShow problem.  So does leezer, who also had a similar problem once.  Give it a try.

[MarkGrigsby]

Okay, will give it a try, though removing the Cyberlink decoders will break my h264 playback.  Not saying it's MC's fault that Cyberlink have buggy decoders, but it's not going to be a good result for me.

I'd still like to understand a couple of things:

1. What is MC doing to even invoke this problem, about 1 minute after loading.  Is it thumbnail generation?

2. What changed a few builds ago to trigger this?

[JimH]

Is it thumbnail generation?

It's possible.

[Yaobing]

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.

[fitbrit]

I just posted this in another thread: http://yabb.jriver.com/interact/index.php?topic=46223.0

Could it be a 'building thumbnails' problem?
Most of my videos use Haali as a media splitter. One 'feature' of this is that every time it's used a little tray icon appears. I've noticed that when MC becomes unresponsive, my system tray is filling up with Haali icons. This is usually indicative of thumbnail building. When this happens, right clicks are not registered, the scroll wheel doesn't work and drop-down menus don't function either. Trying to tag any fields causes them to exit from editing mode. After a minute or so, the system becomes responsive again, but there's no knowing how long (usually a few seconds) one has to complete the task you were trying to do before the freeze/shut out starts again. A simple task such as copying a thumbnail/cover art to clipboard could take three minutes or more while you constantly right click to see if it's done yet, is it done yet, is it bloody well done yet?

I get similar behaviour when I request a thumbnail build, even though it's meant to be done in the background. However, I notice that the little status area in the lower left of standard view doesn't always tell the truth. Once it's said it's done building, it's actually continuing to make more, as judged by the Haali icon in the tray continuing to appear and trying to quit MC results in a notification that thumbnails are being built. If I re-request to build missing thumbnails once it claims to have done them all, there are somehow hundreds or thousands left to build, even though it claimed to have done them all a few minutes before.
I've found that each time I request a thumbnail build there are fewer left to build when the task starts. I'm hoping that once the process is over finally, that the freezing/shut out problem will go away. I disabled all my Symantec anti-virus software last night. I got the feeling that the shut-outs were shorter in duration, but they're still happening for sure.

AoXoMoXoA, does any of this sound like what's happening with you?

[fitbrit]

I'm using CoreAVC with my Haali, so it's not limited to Cyberlink filters. I'd use ffdshow, but it's just not fast enough even with my Opteron 180 (2.4 GHz x2) for most 1080p material.

[leezer3]

Buggy filters all round then 
From my case (Original thread I posted) everything played within MC or otherwise, it was just the thumbnailing causing issues, hence why the issue was not detected for a while.
It was definitely a MC change that triggered the behaviour in question, but FFDShow was the root cause
Anyhows, pull CoreAVC & see what happens- You might be surprised

Your Opteron should more than handle 1080p stuff, no idea why it doesn't  ? (When was the last FFDShow you tried- Things have got much better lately! Also remember you want FFDShow-Tryouts; The original build hasn't been updated particularly recently)

Cheers

-Leezer-

[fitbrit]

Buggy filters all round then 
From my case (Original thread I posted) everything played within MC or otherwise, it was just the thumbnailing causing issues, hence why the issue was not detected for a while.
It was definitely a MC change that triggered the behaviour in question, but FFDShow was the root cause
Anyhows, pull CoreAVC & see what happens- You might be surprised

Your Opteron should more than handle 1080p stuff, no idea why it doesn't  ? (When was the last FFDShow you tried- Things have got much better lately! Also remember you want FFDShow-Tryouts; The original build hasn't been updated particularly recently)

Cheers

-Leezer-

Thanks Leezer. I did download a recent ffdshow tryouts (April 15th, I think). I'll see if I installed it or not after downloading. There are two different guys/groups doing nightly builds, so I'm not sure which one I'm using. I'll check tonight and see. I know I have one of the latest Haalis too. Funnily enough, I didn't get most of these problems until recent builds of MC, so somehow a filter problem was gettign away with its bugginess up till now.

[MarkGrigsby]

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:

Code: [Select]

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: 1So 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!

[leezer3]

Looks to me like Haali/ Directshow are incorrectly identifying your M4A files as video 
MC is therefore trying & failing to thumbnail them-
Update Haali/ codecs & as said before things should be back to normal!

Cheers

-Leezer-

[Yaobing]

I will check the code to make sure we did not mess up something. If you do not check m4a for DirectShow playback, MC should not be testing it for DirectShow. Besides, m4a is audio, and should not be involved in DirectShow thumbnailing.

For users who are having similar troubles with Haali in the Notification Tray, you can try disabling the feature and see if it improves anything. To do this, start "Haali Media Splitter Settings" (depending on how you installed it, you may find it under CCCP, or Haali in Windows' Start menu), on the Options tab, expand "Interface" tree and click "Show tray icon". Change the value at the bottom to "No".

[MarkGrigsby]

Looks to me like Haali/ Directshow are incorrectly identifying your M4A files as video 
MC is therefore trying & failing to thumbnail them-
Update Haali/ codecs & as said before things should be back to normal!

Cheers

-Leezer-

Hi Leezer,

I do appreciate your help and advice, but I still don't see why updating video playback codecs is going to help me here?  I am using the latest Haali, and it doesn't happen in build 456.  Surely if it was a problem with Haali / filters, then the 'mis-identification' of M4A files would happen in both builds?  Anyway, are you sure that what MC is doing here (trying to play those files) is thumbnail related?

I'm not saying that installing new codecs wouldn't mask the problem, but it would be good to know what is the real root cause.

Yaobing - I will try the disable suggestion you made, see if that clears it up - but again, it's more a workaround since I like knowing when Haali is / isn't in use and be able to easily select different audio tracks etc.  I'd really appreciate it if you could check from a code pov too

EDIT - I tried disabling the taskbar icon, but the problem persists.  Except now there's no 'evidence' as MC just seems to stop playback for no reason...

[Yaobing]

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:

Code: [Select]

0085797: 2644: Playback: FileCanPlayInDShow: Testing: M:\mydirectory\myfile.m4a
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!

Testing for DirectShow playability happens only in two places - when trying to play a file (if the file is set to be played in DirectShow) and when analyzing an audio file.

Since you said you unchecked m4a for DirectShow playback, the only possibility is analyzing. Were you actually analyzing a bunch of audio files (m4a files in particular)?

We test m4a in DirectShow because it is the only way they can be analyzed.

[MarkGrigsby]

I wasn't analyzing anything (I don't think I ever analyzed audio, or at least if I did it was a LONG time ago).

I can reproduce my problem by simply opening MC and waiting a minute or so.  Don't need to select anything else.

I tried creating a blank library and importing only 100 m4a files - I then got the same problem!

So - as you can see from the log, although I'm not analyzing audio and not trying to play the file, somehow MC is deciding to 'test' all my m4a files.  I guess the question is, what is the trigger?!  Any idea how I could try to narrow it down some more?  Would it help to send you a complete log file?

[leezer3]

Auto-analysis hasn't got turned on by mistake has it- Tools, Options, Library & Folders; Make sure analyse audio is unchecked.
If it has, then I'd again point the finger firmly at your M4A decoder 

Cheers

-Leezer-

[MarkGrigsby]

Auto-analysis hasn't got turned on by mistake has it- Tools, Options, Library & Folders; Make sure analyse audio is unchecked.
If it has, then I'd again point the finger firmly at your M4A decoder 

Cheers

-Leezer-

I looked at that option, and it IS turned on.  I unchecked it but no change...

Then, I decided to create a new cloned library, and so far I didn't get the same thing.  Not sure if perhaps there was some audio analysis queued up that keeps erroring on the other library and can't be killed?  Was that option there in the older builds?

[leezer3]

It's a relatively new option IIRC, and for that matter I'm not sure about the queueing for analysis process (Don't ask me, ask the devs  )
You still need to update your M4A decoder if at all possible though- All you've done is masked the symptons of the bug 

Cheers

-Leezer-

[MarkGrigsby]

Thanks.  So far so good on the new library.  I'm not sure I completely agree about 'masking' the bug - what it seems has happened here is somehow all my m4a files got forcibly 'tested' (I presume relating to some 'audio analysis'), and no matter what filter was used they wouldn't be tested quickly enough not to interrupt MC.  Since I don't use Dshow for M4A playback, why do I need to update the decoder?!

As a futher test, I did some testing and found that it is a Cyberlink decoder set to play AAC files - I temporarily disabled this, and although MC no longer froze I still get hundreds of entries in the MC log about 'failed' Dshow playback tests.  So I guess that's the real 'root' cause.

Now, whether this is a MC 12 'bug' is admittedly debatable - certainly the newer builds are doing something to my library that is not helping me, but perhaps it's my particular library that is the issue...?

[leezer3]

Sorry, ought to have been a little more specific in my last post
'Analyse Audio' basically calculates the replay gain, BPM and some other little bits of data for each of your tracks.
By M4A decoder, I meant the Cyberlink filters as you've just found; These work through the DirectShow interface, perhaps DirectShow is too broad a term

FWIW, I would say that the 'Analyse Audio' option in the settings was introduced after .256 (It was/ is possible to do the analysis manually, as opposed to the automatic process of this setting), hence why reverting to this build masks the issues.
Using .256 select 40 odd M4A files, right-click, Library Tools, Analyse Audio- I'm (almost) willing to bet this will cause exactly the same issues as you're seeing with the later builds, as this triggers the same process manually.

Cheers

-Leezer-

[MarkGrigsby]

Definitely seems that's the root cause.  Those tracks were somehow 'stuck' in the queue for some analysis.  Not sure why, since I checked those fields you suggested (e.g. BPM) and hardly any of my mp3 library is showing values.  Maybe that's what went wrong - the 'auto analysis' got stuck on my library.

Anyway, I'm happy without any such analysis, so all is good here now.  I'm not even sure the cyberlink aac filter is 'bad', since really it's loading and checking the file pretty quickly each time, and MC's log even shows 'success'.  If I do enable Dshow playback for M4A then the decoder plays it all fine.

May be worth checking the code for the 'auto analysis' part though - since surely even if those files are 'marked' for needing analysis, it shouldn't redo it each and every time MC loads?  Not that it bothers me, just thinking for other folk in the future!

[Yaobing]

I made the following changes:

1. Changed: Audio file types that are played in DirectShow are not analyzed during Auto-import.
2. Changed: Audio file types that are playable in native playback engine only via DirectShow are analyzed (in Audio Analyze tool) only if the user chooses to play the types in DirectShow (for example if you do not choose to play m4a files in DirectShow, they will not be analyzed).

They should appear in a new build soon.

If you ever decide to play your m4a files in DirectShow (there are certain advantages for doing so), I would still recommend installing CCCP. CCCP includes a very stable build of FFDShow, which is proven to be a good choice for decoding aac and many other types. Many filters may be good for playback, but are not good for background tasks such as Auto-importing and thumbnailing (in case of video files). Cyberlink aac decoder may or may not be such filter.

[MarkGrigsby]

Wow - that really is the best 'service' around   Report a 'bug' on Thursday, and by Friday night the developers have worked on it. And it's even debatable if it's a real 'bug', or more some possible 'annoyance' for a small subset of users.  Thank you for taking notice of your users - that's why I continue to recommend MC to my friends, and so far have a perfect 'success rate' of persuading them to buy versus steal your program.

JimH - sorry I was a bit 'short' yesterday, I completely got the wrong end of the stick about you moving my post.  Your point for moving topics needing 'discussion' has shown to be the completely right course of action!

I may try the CCCP install sometime - though I am nervous about adding new filters since everythng is working nicely for my needs, and I had bad experiences in the past with filter changes.  I may take a TrueImage backup and have a play - and if so will report back here to complete the story.

[glynor]

I just thought I'd poke in and say that I've had problems myself with some of the Cyberlink decoders.  It's really too bad since I have a HD 3850 512mb card on my HTPC too, and it'd be nice to be able to accelerate HD MPEG-4 AVC decoding (h264).  Unfortunately, I was just not able to get those decoders to work reliably and well.  To be clear, these problems were NOT all with MC (or even mostly).

There are well documented problems with those decoders, including complete failure to decode perfectly legitimate and standards-compliant encodes.  Dig around a bit over at AVS Forum or Doom9 and you can find all kinds of complaints about them.  It seems mostly like they're concentrating on making sure they work with their own player, and don't care at all if they don't work completely properly as general-purpose DirectShow filters.  CoreAVC is a bit better, but it does seem to choke more often when run in background threads than FFDSHOW.  That probably has something to do with tricks they pull to get it to perform like it does.  BTW... why don't you just overclock that Opteron?  I could get my Opteron 165 and 170 to run at 2.5-2.6 easily and without pushing it hard at all (both would boot to Windows up to 2.9 GHz, but I backed them off to get them stable).  Running a dual-core Opteron in a desktop box at stock is just plain silly.  There's LOTS more performance locked in that chip.  Let her run.

Hopefully eventually the tryouts team will gets us AVC acceleration built into some new future version of FFSHOW.  That'd make my day.

[MarkGrigsby]

As it happens, I get really good h264 playback with those Cyberlink decoders, combined with Haali splitter and EVR custom mode in MPC-HC.  I did run into the occasional troublesome stream, but in those cases CoreAVC has worked for me.  I guess I've been lucky!

Suppose we can't complain so much that Cyberlink focus on their own player vs the filters.  At least in V7 they're usable outside PDVD - in V8 they're locked down...