×

Give a tip

MikeSafe

Newcomers
  • Posts

    30
  • Joined

  • Last visited

 Content Type 

Profiles

Forums

Release Notes

Bug Tracker

Help page

Help page-CN

Release Note5

Rules and recruitment

Release Note6

Everything posted by MikeSafe

  1. OK, we're back in the game. Installed new cooler yesterday and the temperatures are massively down. I left HWMonitor on for about 5 hours and the max temp recorded was 39 C, but it spent most time around 33 C. So what about the big test, I hear you scream. And I say, whoa, easy. You're deafening me here. It's appreciably better. No doubt. I actually managed to watch videos, fullscreen, in 720p without stutter. But... in general, stutter still occurs whilst downloading. And even when it's downloaded into cache and playing without stutter, CPU is still anywhere between 60-80% with the odd spike reaching upto 100%. I have still yet to test in IE and FF, mind, but I think we've overcome the major choke point. So thanks for holding my hand throughout this journey my friend; I actually quite enjoyed it and learned some stuff, too. I would probably never have gotten here without your guidance and patience. I will conduct further tests and see if I can upgrade Flash to the latest again. If there is significant improvements or degradation I'll report back but in the meantime, I think I need to be satisfied with the results and return to normal life again. Thanks again.
  2. You've prompted me to inspect all fans inside the case. To my horror, I discovered two of the legs that hold the fan and heatsink (on top of the CPU) to the mobo had snapped. Worse still, the glue fixing the heatsink to the CPU had failed, so only two legs were essentially holding the entire fan and heatsink in place! :'( So looks like I'm shopping for glue and a fan. Grrreat!
  3. A couple of other observations made last night. Maxthon in F:\ drive I booted into F:\ as you asked and downloaded MX4 as an exercise (I didn't install). I recorded 4% CPU usage. I should add that I don't have a firewall on this install. VLC standalone I want to make an additional observation regarding VLC standalone which I didn't pay attention to in my initial comments; and that is resolution. In those comments I tested relatively low-resolution vids (probably around 480p). I played a couple of HD vids the other night. They were both Flash with one at 720p and the other close, but not quite, 1080p. The CPU on 720p was ~70-90% (but played without stutter); the CPU on 1080p was high 90s to 100% and stuttered badly. In contrast to last night when I watched a downloaded .MKV movie (H.264) in 720p and it used ~20% Which would point to a Flash thing. Although let's not forget, just to confuse matters more, I've rolled-back Flash to a 2012 version when the problem didn't exist! I know.
  4. 2nd screenshot showing state of affairs playing video (720p). Again, whilst the CPU reading (circled) in this grab isn't constant, it spends more time down here than in the first grab. Also note in HWMonitor (in both grabs), the MIN value in the following row: -Intel Pentium E2180 -- Core #0 ... which reads -41 C I watched this fluctuate periodically in the VALUE column from ~52 C to -41 C. It stopped after a while.
  5. Oh brilliant, thanks 7twenty; that's a massive help Here are some screenshots of the CPU-Z and HWMonitor in action. Whilst I might stab a guess, I don't really know what is supposed to be normal. I'll post a second grab in the next post. This grab shows the state of affairs when NOT playing video. You can see from the circled area that the CPU reads ~1999, and the multiplier x10. Whilst this does not represent a constant reading (it periodically dips to a reading close to the next screenshot), it spends more time here in this state. (Ignore the low-res of images)
  6. MX is clearly not as optimised as other players or it's a HWA issue. I definitely believe it's not as optimised as IE(8), by about 10%; which I now know runs a different version of Flash. Firefox is probably about equal to MX4, though, if not marginally worse - at least on my XP system; and they both utilise the same version of Flash (PPAPI). Even on my desktop system Maxthon uses 5-10% more than Chrome which hovers ~5% Is that using Flash? I've noticed that MX4 uses the same ffmpegsumo.dll as Chrome for playing HTML5. Are you sure the CPU is running at full speed and not being artificially restricted somehow, or being throttled down due to heat issues? Use HWMonitor to check your temps and CPU-Z to check CPU speeds. Thanks for that. I've asked myself the same question so I'll play with those and report back. On your F:\ drive install, did you try downloading with MX and check it's cpu usage? Can't remember. Will try. I think going back and doing this test might be best: 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.. Hmph, yeah I know. I'm trying to avoid that 'cos, apart from being time-consuming, I've never done it before and I don't know how aggressive to be in disabling stuff - there's a lot of stuff. I bought a new monitor (1080p) yesterday (nothing to do with this) and last night I viewed YT vids recreationally in 720p (ie, not faffing about testing and changing and rebooting etc) and it's clear that, overall, there's little improvement to where things stood at the beginning. Playing 720p in fullscreen, even when playing from cache, still pushes the CPU into the 90-100% range.
  7. Alreety alrighty, welcome to today's exciting digest. So I dragged a movie onto Maxthon, both before and after upgrading to the latest version, and saw little improvement over playing a YT movie from cache. However, over a period of around 2-3mins, the CPU steadily climbed to 90-100%. I didn't uninstall Flash for this exercise, but then Maxthon utilised HTML5 to play in this way anyway. What I can't remember this morning, though, is whether the CPU climbing phenomenon happened before upgrading Maxthon (too many experiments over the last week or so is mushing me noggin), but it is now anyway. I also updated ZoneAlarm and downloaded a movie using MX Downloader. With ZA uninstalled: ~35% With upgraded ZA: ~39% I thought that was an improvement, but that was from notes taken at the time. Later, when downloading other stuff, I noticed that the higher the download speed, the higher the CPU usage; nudging once again into the 60s at times. MX Downloader accounted for around 14-20% IIRC - so ZA is seemingly being aggressive with Downloader.
  8. Thanks 7twenty. Do you mean drag a movie file onto Maxthon before installing Flash? I managed to install Flash last night anyway (2 versions up from the working install), with slightly better performance witnessed (around 10%), but still above satisfactory at around 50-60% load. I also downloaded a movie using MX Downloader to the HDD and can confirm that ZA dominated CPU usage kicking it to around 70-80%; MX Downloader was only about 15% of that IIRC. I haven't had chance to try the portable version yet.
  9. Thanks SnowLeopard. The problem is determining which of the downloads listed have both Windows and NPAPI versions within - not all of them do. However, I believe I have found one that's close to the version I need. I'll find out later.
  10. You need to install the NPAPI (for firefox) version (not sure if the wording is the same for older versions). If it installs correctly and is the right one, and the file in the Maxthon folder is renamed/deleted then MX will use the installed NPAPI version on the system. Oh great! I can see this is going to be fun; trying to find an archive with the requisite files needed! The download that matches the exact version number of my working install is missing a Windows installer (Mac only), hence I had to download a couple of newer zip files before finding something I could use... which obviously isn't NPAPI! Thanks 7twenty, I will look into it later.
  11. 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.
  12. 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.
  13. 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.
  14. 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.
  15. 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% :@
  16. 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.
  17. 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.
  18. 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
  19. 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
  20. 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
  21. 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.
  22. 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.
  23. 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.
  24. 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.
  25. 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.