Give a tip


  • Posts

  • Joined

  • Last visited

MikeSafe's Achievements


Freshman (1/10)



  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% :@