YouTube video, MX downloader & 100% CPU


MikeSafe

Recommended Posts

Hi, I know there have been various reports on these symptoms over the months but despite updating to the latest version (4.4.2.2000), the problems persists (on Win XP, dual core, 32bit, 3,500 GB RAM).

YouTube: the higher the resolution - or when in fullscreen - the more jittery the playback. The CPU will reach 100% and stay there until resolution is reduced. Even on relatively low resolution videos (360px), when there is fast movement (for example, a comedian running across a stage) the video stutters and goes out of sync with audio when in fullscreen.

Note: when I say high resolution, I don't necessarily mean within YT's settings (240/360/480 etc). I can be in 480px mode with few problems if the video is recorded in low quality but if the video is a modern, high quality recording, the CPU goes up and the problems begin. Forget 720px - not happening.

Action taken

I've tried various user agent settings, updated flash player, deselected graphics hardware acceleration, forced flash-player playback, and switched between Ultra and Retro modes, with very little, if any improvement.

Download manager: when in use, the CPU increases and the browser becomes generally slow when switching tabs. I cannot watch a video whilst downloading (unless it's low resolution).

If I watch a video in a standalone application (for example, in VLC), there is no problem.

Overall, the problems have persisted for most of this year now.

All drivers have recently been updated. No other major changes to the computer.

I hope the above description is useful and wonder if anyone can advise if Maxthon is still working on this, given up or offer a solution I have overlooked?

Many thanks.

Link to comment
Share on other sites

To me Maxthon's video playback has always been a little sketchy in that it can jump frames, especially if a page is loading in the background. It seems to be related to the way network throughput and rendering is threaded. This was mostly fixed a while back when the multi process releases started, but has since seemed to have crept it's way back ever so slightly.

Firstly can you provide a link to a video/videos that consistently cause the issue. Even if it's on all, it's nice to test with the same. Have you tried with other browsers and do they show the same issues?

if the video is recorded in low quality but if the video is a modern, high quality recording,This should have no bearing on your problems. It doesn't matter when or what quality the video was recorded at as it gets re-encoded by youtube. Youtube uses different file formats and encoding depending on what level it's playing at. It could just be that your PC uses HW acceleration for some and not others causing the high CPU load.

If possible can you grab a screenshot of your CPU usage while running a video in VLC and also in Maxthon, preferably the same one. You can use http://en.savefrom.net/#url=XXX to download the file from youtube or elsewhere. Replace the XXX with the URL to the video. Link the video so I can have look and do a comparison.

Regarding download manager, i'm thinking it's somewhat related. But we'll work on the video first and see what happens.

Link to comment
Share on other sites

Apologies for the late reply.

Here is a link you requested to a YT video that always exhibits the problem; although, like you say, they all do eventually.

Scrrenshot

Here is the screenshot you requested. The video is not from YouTube but the problem is exactly the same regardless:

10470

The link to the video is: http://www.cloudy.ec/v/ad667d7f402df

Notes:

- although the screenshot captures a black screen in VLC, it is playing the video.

- there is not much movement in this video of either the comedian or camera. It would have been very difficult to capture otherwise.

- I had only one tab open in Maxthon to minimise CPU usage.

I hope this is useful and thanks again for looking into it.

post-30674227-14315122206211_thumb.png

Link to comment
Share on other sites

Videos seemed to play fine for me.

You say you are using (or have at least tried) the latest version of MX4, but the image is showing MX3 if i'm not mistaken. Unless you are using an MX3 style skin.

Firstly try the most recent version (available here), and if you are using MX4 with a skin, try using the default one in case the skin is causing some of the problems.

What's the memory use when playing the video? And do you for some reason have a lot of HDD activity when this happens? And your results of testing with other browsers on the same videos.

Link to comment
Share on other sites

Hi 7twenty, thank you for your help and patience.

You say you are using (or have at least tried) the latest version of MX4, but the image is showing MX3 if i'm not mistaken. Unless you are using an MX3 style skin.

Yes, it was using the MX3 skin. I've now updated to the most recent version (4.4.3.1000), with default skin with no improvement.

What's the memory use when playing the video? And do you for some reason have a lot of HDD activity when this happens?

Memory use is "normal", I would say. You can see in the above image that there's plenty of virtual and physical memory available.

HDD activity is also "normal"; nothing out of the ordinary.

And your results of testing with other browsers on the same videos.

Yes, ahem, it now appears that playing in IE exhibits the same issue. Damn. I had already tested this some months ago without issue but, damn. What to do now?

Link to comment
Share on other sites

Yes, ahem, it now appears that playing in IE exhibits the same issue. Damn. I had already tested this some months ago without issue but, damn. What to do now?So if it's now happening with other programs you'd need to start looking outside of MX. It could be a recent Flash player update has caused the issue.

Test with using HTML5 instead of Flash player. Use the Youtube Centre extension to quickly enable and test with it.

Also check for malware/viruses, disk scan in case of HDD errors. Is the CPU running at full speed and not throttled down for some reason?

Link to comment
Share on other sites

A couple of months ago I completely uninstalled Flash and reinstalled an older version with no improvement. Since then I've updated to the most recent couple of versions.

I noticed the very latest version of MX enabled my YouTube Centre (YTC) upon installation, which was weird. Anyway, YTC slows MX down further (page rendering) so I can't have it running for normal use. I did what you asked, however (aggressive Flash), no improvement.

HTML5 is slightly worse than Flash.

I've noticed lately I cannot right-click in YT's video screen and call up the Flash settings dialog box, nor YTs settings either (Copy URL etc). In HTML5 I see YTs dialog box.

No malware or viruses to report. No reason to believe there are HDD errors but will have to check.

The CPU tends to vary according to movement in video: high movement = max CPU; and conversely it will decrease when there is little movement (720px).

There are clicks in the sound at its worse, and the picture will "stutter" and occasionally jump forward, as though trying to remain in sync with the audio. Additionally, when clicking pause, the audio will stop but the picture will continue for several seconds, as though it is "catching up" to where the audio terminated.

The more I think about it, the more I think it's related to YouTube's full implementation of HTML5 as the issues emerged around about the time is rolled out sitewide earlier this year. I experimented with YT's HTML5 last year, when it was in its test lab, but switched it off as it didn't run well.

I notice that YT streams lots of small video files now (around 280kb each, according to MX's Resource Sniffer), rather than a large single one as it used to, and I wonder if this is linked to the problem; ie, constantly downloading, processing and stitching together lots of small videos whilst keeping audio and video in sync. I don't know.

It's got to be browser-related, I know that; Flash and other movie files play fine in VLC standalone.

Link to comment
Share on other sites

I've noticed lately I cannot right-click in YT's video screen and call up the Flash settings dialog box, nor YTs settings either (Copy URL etc). In HTML5 I see YTs dialog box.

Unfortunately that's a known long standing issue.

I notice that YT streams lots of small video files now (around 280kb each, according to MX's Resource Sniffer), rather than a large single one as it used to, and I wonder if this is linked to the problem; ie, constantly downloading, processing and stitching together lots of small videos whilst keeping audio and video in sync.

Interesting pickup. You can disable this with Youtube Centre by unchecking the DASH Playback option in the External Players section. Will be interesting to see what happens.

Link to comment
Share on other sites

Thanks 7twenty.

I unchecked DASH in the Player section (External Players was already unchecked) and at 720px there is a small perceivable difference, particularly if one waits for the whole video to load.

CPU usage still spikes at 100%, though, but seemingly less often. It probably averages between 80-90% - still high.

Link to comment
Share on other sites

There are clicks in the sound at its worse, and the picture will "stutter" and occasionally jump forward, as though trying to remain in sync with the audio. Additionally, when clicking pause, the audio will stop but the picture will continue for several seconds, as though it is "catching up" to where the audio terminated.Clear case of not enough CPU grunt for the application. The question is why. I'm still thinking it's a flash issue.

When you check task manager is it only the Maxthon process that is at 100%?

The CPU tends to vary according to movement in video: high movement = max CPU; and conversely it will decrease when there is little movement (720px).That makes sense due to the way videos are decoded. If there is little on screen there isn't much for the decoder to do.

I really don't know what more to offer. Apart from running in safe mode in case something is causing the issue, all i'd be doing is requesting more info on what is happening with CPU/GPU usage. You can download Process Explorer and have a look at the GPU/mem usage in case there is something going on there. It's much more in-depth than the basic programs in Windows. Click on the graphs in the top right to open up a larger window to see GPU usage etc.

Link to comment
Share on other sites

When you check task manager is it only the Maxthon process that is at 100%?

It is, yes.

You can download Process Explorer and have a look at the GPU/mem usage in case there is something going on there. It's much more in-depth than the basic programs in Windows. Click on the graphs in the top right to open up a larger window to see GPU usage etc.

Believe it or not, I have already tried PE (and viewed the author's video for guidance) but it is like looking for a needle in a haystack; I see a recurrent error but trying to trace what it actually means ground to a halt via Google and on PE's forums. I don't even know if the error is relevant to the issue - it's that non-descript.

If I get chance later I'll paste what I found if it's of any interest.

Link to comment
Share on other sites

Sorry 7twenty, only just seen your comment. I will try to grab screenshots over the weekend, although I have new information which I wouldn't have noticed without disabling DASH, as above, so I think this may be pertinent.

Last night on YouTube I was listening to a recorded radio show which had finished downloading into cache. CPU was nominal (probably around 20% IIRC) and there was no motion in video as it was just a radio show. Great.

Whilst listening, I opened another video in a new tab and paused it. I wanted to download it into cache first and watch it after the radio show finished.

Result

CPU shot up to around 80-90 percent whilst the second video was downloading. Once finished, CPU returned to nominal again. I continued playing the radio video throughout.

Conclusion

It would appear that the process of downloading, rather than perhaps playing, is the main drain on CPU resources.

As mentioned, having DASH enabled means downloading is almost constant throughout the video so this would not necessarily have been spotted had I not disabled.

Hope this provides more food for thought.

Link to comment
Share on other sites

Hmmmm, interesting.

A couple of tests if you don't mind. Do these with Process Explorer or Resource Monitor running and keep an eye on the CPU, disk IO & ethernet graphs watching for any direct correlation between them.

Download a program with Maxthon (eg. Maxthon installer).

Download a program with IE or another browser.

Copy a file on your HDD to another folder and/or drive.

Copy a file on your HDD to a networked device (other computer/tablet etc)

I'm thinking HDD/storage/Ethernet drivers are having an issue with something. Are you sure they're updated to the latest and not using some generic MS ones?

Definitely no warnings/errors in device manager?

Also have a look in the event logs (from windows search type in event, then select view event logs. Windows Logs > System). Look for any warnings/errors relating to disk/network/ethernet.

I vaguely recall having a similar issue where my mouse would stutter horribly when downloading stuff. Updating the ethernet drivers fixed it.

Could well be that we started looking at this from the wrong end?!

Link to comment
Share on other sites

I moved the Temporary Internet Files folder to another HDD last night, to discount or prove a slow drive or read/write situation: no difference.

In furtherance of my last post on YT, with DASH disabled, I paused

whilst waiting for it to download before playing in 720px. Once done I hit play and the problems were back. He is quite animated and so the CPU soars to 90-100% with all the probs that incurs, and at around 6m27s he switches to a screenshot recording and the CPU drops to around 70-80%.

Which brings back the playback issue into the equation; ie, it's not solely a download issue, although downloading does significantly increase CPU.

I downloaded the Maxthon installer and CPU surged to around 60%.

I also updated Flash. It was a slow download with the occasional pause (network congestion). The CPU idled around 6% during pauses and surged to around 50-60% for the short period when downloading resumed; even though the speed was only registering around 19KB/s.

OK, I've only just logged back on and seen your message so I'll conduct the rest of your tests and get back later.

Link to comment
Share on other sites

OK I'll split this post into 2 for clarity.

Here are the results of your tests. Note: I don't have networked computers so cannot test that request.

(Monitored in Process Explorer)

Download Maxthon installer

(In Maxthon)

CPU: 50-60%

I/O: up to ~10MB

Disk: up to ~24MB

Network: ~1.4MB

(In Internet Explorer)

CPU: 50-60%

I/O: up to ~14MB

Disk: up to ~20MB

Network: ~1.9MB

(Not much difference essentially)

--

Copy file to another HDD

C:\ -> F:\

File: 250MB

Time taken: ~2mins

CPU: 50%

I/O: ~5.3MB

Disk: ~5.3MB

--

Same file, other way

Time taken: ~2mins

F:\ -> C:\

CPU: ~50%

I/O: ~5MB

Disk: ~2.5MB

--

Ethernet driver is up-to-date.

Event Logs: no errors/warnings

Device drivers: no warnings/errors

Link to comment
Share on other sites

Here are some screenshots of PE in action whilst playing the same https://www.youtube.com/watch?v=tIWqN6Ux9XA.

Note the highlighted "Recurrent process". This is not the best screenshot as it is a frequent process that crops up.

Here is the info copied from the Stack of that process:

ntkrnlpa.exe!KiUnexpectedInterrupt+0x121

ntkrnlpa.exe!ZwYieldExecution+0x1c90

ntkrnlpa.exe!ZwYieldExecution+0x2572

ntkrnlpa.exe!NtWaitForSingleObject+0x381

ntkrnlpa.exe!KeReleaseInStackQueuedSpinLockFromDpcLevel+0xb74

ntdll.dll!KiFastSystemCallRet

USER32.dll!GetLastInputInfo+0x105

MxWebkit.dll!DestroyAdRuleService+0x9fa74

MxWebkit.dll!DestroyAdRuleService+0x9fd3b

MxWebkit.dll!DestroyAdRuleService+0x9fb0e

MxWebkit.dll!DestroyAdRuleService+0x78d5d

MxWebkit.dll!DestroyAdRuleService+0x771c6

MxWebkit.dll!DestroyAdRuleService+0x8344b

MxWebkit.dll!DestroyAdRuleService+0x8352c

MxWebkit.dll!DestroyAdRuleService+0x82028

kernel32.dll!GetModuleFileNameA+0x1ba

post-30674227-14315122301024_thumb.gif

Link to comment
Share on other sites

Another screenshot highlighting the thread (Flash) using the most CPU, with its Stack. This is whilst playing the video from cache.

Note the unexpected interrupt(s) which again is seemingly a frequent occurrence (don't know if it's normal behaviour or not).

HTH (or not!)

Right, that's most of my day gone - going to slap my bass now :D

post-30674227-14315122301834_thumb.gif

Link to comment
Share on other sites

I'm not familiar with the Kernel commands, but i'm pretty sure that anything with Unexpected interrupts generally isn't good.

The fact that the tests you did all show ~50+% CPU usage and the only common factor I can point to is the HDD was in use in all situations, leads me to believe it's somehow related to that. It's almost 100% not related to Maxthon and doesn't seem network device related.

Did you try running in safe mode and trying the same tests? And what other programs do you have running?

Can you download this, just extract and run the latmon.exe file. Press the play button in the top left while running maxthon with video for a little, then press stop. Go to the drivers section and sort by ISR or DPC count and see what the driver is that is causing high counts. If you can provide that and any other info you think might be useful.

For reference the highest counts on my system is the USBPORT.SYS driver ~1200 IPC and ~7300 DPC. My system runs fine as far as i'm aware.

This is really a head scratcher?!

Link to comment
Share on other sites

I tried safe mode yesterday - no difference.

No other programs running.

The Latmon program doesn't work in XP.

It really is a head-scratcher. I've searched elsewhere on the net and there are plenty of reports describing the same symptoms but I can't find solutions. Something changed earlier this year (late last year) as that's when the concentration of reports are dated. I've sat on it most of this year believing it was a Maxthon issue and thinking it would be sorted eventually. Really weird.

I agree it's not a Maxthon problem exclusively; if it is a browser-related problem, it's all of them. I tried in Firefox on Saturday and the same thing happened.

Thank you for your indulgence on this, you've been more than patient. Unless you have other ideas I will continue scratching around and update if I find a solution.

Link to comment
Share on other sites

No problem, I enjoy these sort of troubleshooting scenario's - keeps the brain active :-D.

if it is a browser-related problem, it's all of them. I tried in Firefox on Saturday and the same thing happened.I don't think it's anything to do with browsers. 50% usage to copy a file I think is excessive, even on an older system.

Given that it happens in safe mode, and there are no other programs running the only thing left is windows/drivers/hardware. It could have something to do with an update that may have changed something for the worse. If you had a backup image that you were willing to test with from before an update and it started happening you could almost certainly narrow it down to it being that.

Without that, i'm putting it down to hardware/conflict/configuration change or error.

I've got 3 more options that just came to me (in order of easiest to hardest). After that i'll be struggling to find more.

1. Follow this guide and ensure that DMA mode is available and enabled on your drives. If DMA mode isn't on it can detrimentally affect HDD performance. Although you should have noticed it more often rather than just file copies.

2. Go to Device Manager, disable all devices that aren't required (so anything apart from display, graphics card, main HDD, keyboard, mouse etc) Disable everything else (right-click, disable) restart and do the copy tests again. If the problem doesn't happen after disabling everything, then we know it's a device/driver issue. From then you enable one device at a time and test. Keep doing this until it starts happening again.

3. If you have another spare drive, you can do a clean install of Windows and see if it occurs with that. If yes, then it's a hardware issue. If not, then we're back to the start, where it's probably driver/software related.

Link to comment
Share on other sites

50% usage to copy a file I think is excessive, even on an older system.

Yes, of course; I forgot.

DMA is enabled; I checked that over the weekend.

I will try disabling devices when I get time but I just tried something I perhaps should've done earlier...

I just booted from the F:\ drive (the drive I copied files to in the above test). I use it as additional storage really so very rarely boot from it and it hasn't been updated since god knows when. (It's just downloaded 44 updates so that gives you an idea.)

It is running Maxthon 3.4.5.2000, and Flash 11.3.300.271

I played the Fast & Furious 7 trailer on YT (has lots of movement): ~27% CPU

I copied a file (~250MB) to the drive I normally use: CPU: ~2% and it took less than 10secs

Now I'm going to let it install all the updates (including IE8!) and see what happens.

Added: sorry, IE8 already on; it's installing security updates.

Link to comment
Share on other sites

Wow. OK the updates went fine so I rebooted into the usual C:\ to try a few things...

So I looked back at the DMA settings on the HDD, with a view to uninstalling the driver and letting Win reinstall it, and although "DMA if available" was selected, as witnessed, I did not pay attention to what was actually being used. Yep, one of the devices was operating in PIO mode.

So to save time and cover as many bases as possible, I downloaded the file in this article to reset it back to DMA, and rebooted.

Wow, I forgot how slow the system had gotten: it zips along now. Incredible difference.

Copied the same file as earlier to the F:\ drive:

CPU barely flickered.

Took much less than 10secs

So we can discount that now - sorted. Can't believe I missed it yesterday.

But... YT videos still hitting 100% :@

Link to comment
Share on other sites

Well at least we fixed up something :D

But... YT videos still hitting 100% With other browsers as well? You still need to isolate it to Maxthon before you can say it's an MX issue. Test with IE and if it still happens with that, then we're back to flash more than likely being the culprit.

Also as requested earlier, process explorer screenshots of GPU usage and GPU mem usage when running the video.

You can also try removing your current flash and installing the version that was working above. It could just be the newer versions aren't as efficient on older OS/systems?

Link to comment
Share on other sites

Yeah, I will test in other browsers later.

I did run DPC Latency Checker last night whilst playing videos but saw nothing unusual.

PE doesn't report GPU-usage on XP systems (not to be confused with this laptop I'm using to write these posts - hence why the forum detects Win7).

Now I have a benchmark version of Flash that seemingly works on the other drive, I have a fallback position to try. So yeah, will give that a go too.

Link to comment
Share on other sites

Something I forgot to mention which I traced over the weekend is that my ZoneAlarm firewall will intermittently and frequently consume around 20% CPU whilst a video is downloading from YT (as reported in PE).

Once video is in cache, ZA is quiet (obviously). So I believe that explains the download burden witnessed earlier.

Link to comment
Share on other sites

ARGHHH! (Just lost post) :@

Start again.

Tested IE8. It performed ~10% better than MX, on average.

Interestingly, IE was still instantiating Flash version 14.x (see attached). Updated to v15.x - maybe a smidgen more CPU as a result.

Notes

Maxthon v IE

In Maxthon the video was downloaded fully before playback, in contrast to IE which chunks video using DASH. Yet IE still performed better than MX on average. Interestingly, ZoneAlarm is less aggressive when downloading in IE.

However, I'm still not convinced the problem is MX alone; although MX does seemingly process video differently which may explain the additional CPU load...

I fired up Process Monitor to see if I could dig a little deeper. I discovered that MX either makes a copy of the source video from the cache folder into a temp folder (see below) and reads it from there, or downloads the source video directly into the following folder:

C:\Documents and Settings\(Username)\Local Settings\Temp

The file is prefixed fla. For example: fla21.tmp

It's slightly bigger in size than the .mp4 source and is deleted when the tab is closed.

Which leads me to wonder if a conversion process is undertaken in addition to Flash?

The file is read constantly during playback with each read referencing where it left off using a length and an offset size. Most read lengths are 16.384 with the odd one measuring in the 40s (presumably in KBs judging by the volume of entries - loads and loads).

During download there are many more additional write entries to the file (as you'd expect), interspersed with the above read processes if playback is simultaneous.

Every so often a ReadFile instruction is processed with the path given as "C:\$ConvertToNonresident"

No such processes are evident when monitoring IE.

One other observation: if I move the cursor forward in the video's timeline in Maxthon, CPU load would increase and remain higher. Doing the same in IE (despite DASH being enabled) wouldn't exhibit the same behaviour.

I only all the above notes as a matter of interest - not sure it helps address the issue at hand.

Note the areas highlighted in the attached images.

post-30674227-14315122309654_thumb.gif

post-30674227-1431512231049_thumb.gif

Link to comment
Share on other sites

PE doesn't report GPU-usage on XP systemsGood to know. I won't harp on about it then :)

I did run DPC Latency Checker last night whilst playing videos but saw nothing unusual.I linked the other one as it actually gave info on the drivers that are causing the high latency. The one you tested with is good for checking if there is an issue, but you then need to start looking deeper to find the root cause. But if it's all green, then I guess we can scratch that off the list as well.

Something I forgot to mention which I traced over the weekend is that my ZoneAlarm firewall will intermittently and frequently consume around 20% CPU whilst a video is downloading from YT (as reported in PE).So when you replied "No other programs running", that was no other programs apart from ZA or nothing at all, as in only Windows services and critical components running?

It could also be something related to Maxthon's limited HW acceleration options. According to the about:gpu page, all of MX's video decode is done in software, which could explain why it's more than IE (although i'm not sure if IE8 had HWA).

The fact that the same system with a different install as you noted in post #23 seems to run things fine, means it's not related to the hardware not be up to the task. This still keeps leads me back to it being a device/driver issue which hasn't been installed on the other install you tested on.

I'd try getting Flash 11.3 on the system and test. Then MX 3.4.5.2000 and test. And lastly do option #2 in post #22 and see how you get on.

If it's related to a windows update then things are getting very complicated. Might be just easier doing a reinstall.

Link to comment
Share on other sites

So when you replied "No other programs running", that was no other programs apart from ZA or nothing at all, as in only Windows services and critical components running?

TBH, I can't remember if ZA was launched on startup in safe mode; I certainly didn't launch it.

However, I did close it down during one of my tests and all that happened was the load exerted on the CPU by the process was instead just utilised by the browser in the main - there was no overall decrease.

According to the about:gpu page, all of MX's video decode is done in software, which could explain why it's more than IE

I don't think I can get the about:gpu page on XP (I'm typing on the lappy ATM) but I wonder if the decode process is connected with the read file requests to the temp file I mentioned earlier (fla21.tmp)? Not that it helps resolve the issue but it might help confirm that I need to rollback MX to v3.

This still keeps leads me back to it being a device/driver issue which hasn't been installed on the other install you tested on.

We can't discount that, of course, but I'm really struggling to remember what drivers have been added/updated prior to the issue raising its head. I only updated all the drivers in the last 4-6 weeks as I was growing weary of waiting and thinking I need to do some self-help.

My current line of thinking is that something tripped DMA mode to PIO earlier this year which caused a system slowdown. I mistakenly attributed the slowdown to a pretty full HDD together with other theories regarding HTML5 and YT. After clearing space on the HDD, and seeing no improvement, I eventually submitted to upgrading to MX4 and months on, here we are.

That being the case, and having fixed the DMA issue, I may not have needed to upgrade to MX4 and that is something I will have to (reluctantly, as I have settings to preserve) test by rolling back. And I say that because of what I hit last night...

I uninstalled Flash. Only, after rebooting and firing-up Maxthon, Flash v14.x was still installed. It had seemingly rolled-back, but IE was clear.

Anyway, I eventually renamed the flash .dll in Maxthon's folders which had contained same flash version number in the filename (NSPW_flash_version_number.dll or something like that).

Uninstalled.

But, installing the closest flash version to the one on my other working setup isn't picked-up in Maxthon; it is in IE. In other words, the .dll is obviously needed in Maxthon's folder.

Any suggestions? Maybe re-install Maxthon4?

That's about where I'm at. I'm thinking if rolling-back flash fails, I will have to seriously consider rolling-back Maxthon too.

Sorry about these long posts.

Link to comment
Share on other sites