Print

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

[Vocalpoint]

I am noticing an extreme slowdown in converting FLAC to MP3 in Build 45. (Actually the same as in .41 - which was my first install)

I just ripped the new Mazzy Star CD to FLAC and then proceeded to convert from FLAC to MP3

The album contains 10 files - in v18 (Build 212) - the conversion takes 38.2 seconds

In v19 (build 45) - it takes 3:00 minutes exactly.

I am converted 4 files at a time from FLAC to MP3 using the Lame VBR Extreme preset.

Appreciate any comments on this.

Cheers,

VP

[Matt]

I am noticing an extreme slowdown in converting FLAC to MP3 in Build 45. (Actually the same as in .41 - which was my first install)

It's really fast for me.

Double-check your settings (DSP, etc.).

Also, remember that a second conversion might be much faster than the first due to OS-level disk caching.  Take this into account when comparing versions.

[Vocalpoint]

It's really fast for me. Double-check your settings (DSP, etc.).

What else is there to check? I have no DSP on during conversion.

Also, remember that a second conversion might be much faster than the first due to OS-level disk caching.  Take this into account when comparing versions.

I did the conversion 3 times on both versions - with a reboot in between each conversion.

v19 (45) takes anywhere from 1:55 to 3:00 mins to convert the same 10 files. If I watch the conversion in v19 via Task Manager - the Media Center 19.exe *32 process takes (and holds) between 76-100% CPU while the 4 Lame.exe processes - seemed to be getting choked out and only received processor time every few seconds - these four would drift from 0% and then back to 5 or 6% and then back to zero...until finally the conversion completed.

Actually - MC took so much CPU  that it took me a while to finish typing this thread - the keyboard was unresponsive during various keystrokes ....

Here is a screen cap of the TM window during conversion in v19....MC is grabbing 91% CPU here...



By contrast - using v18 (212) in Task Manager - the Media Center 18.exe *32 process sits comfy between 15-18% CPU on average and allows the 4 Lame.exe processes to get plenty of CPU (15-22% on average) to complete their tasks...and the conversion flies.

Not sure what is going on here....the extremely high CPU is totally repeatable in v19 no matter when I fire it up or where I convert from...either local or network source.

VP

[Matt]

Not sure what is going on here....the extremely high CPU is totally repeatable in v19 no matter when I fire it up or where I convert from...either local or network source.

What's your CPU?  Security software?

Can anyone else reproduce this?

There are no high priority threads used during conversion, so I wouldn't expect anything to choke off another program.

[Vocalpoint]

What's your CPU?  Security software? Can anyone else reproduce this? There are no high priority threads used during conversion, so I wouldn't expect anything to choke off another program.

Intel Quad Core Q9550, 8GB of RAM, Windows 7 x64 Pro. ESET AV 4.2.71.2

Just did another conversion and MC is averaging 96% CPU...LAME is getting almost none and ESET (ekrn.exe *32) is sitting at 0% CPU thruout the conversion

This one took 2:50secs to convert 10 FLAC files to 10 MP3. Local drives for both source and destination.

VP

[JimH]

Anti virus.

[Vocalpoint]

Anti virus.

Set my AV to totally ignore the entire JRiver 19 file path. No change. This conversion took 2:52.

Plus - AV has no bearing on the extremely high CPU reading within the v19 executable coming from Task Manager. As mentioned the v18 exe never exceeds 15% CPU at any point during the same conversion. And my v18 path is not excluded in my AV....

VP

[MrC]

I show just slightly faster here.  18 files FLAC -> MP3, no DSP.  Win 7, x64, source=target 2Tb WD HD, i7-3770K @ 3.5Ghz:

18.0.212
2 encodes: 1:30
4 encodes: 0:50

19.0.45
2 encodes: 1:14
4 encodes: 0:47
5 encodes: 0:56 (hit virtual core limit)
6 encodes: 1:03
7 encodes: 1:07
8 encodes: 1:17 (CPU bound)

[MrC]

It is often insufficient to only exclude the media file paths.  You need to configure your AV to also exclude the program binaries themselves from real-time scanning.

I'm with JimH - A/V needs to be entirely disabled to test.

[Vocalpoint]

I show just slightly faster here.  18 files FLAC -> MP3, no DSP:

18.0.212
2 encodes: 1:30
4 encodes: 0:50

19.0.45
2 encodes: 1:14
4 encodes: 0:47

OS? Hard disk type (Source/Destination?)

My numbers are off the charts...

18.0.212

2 encodes: 0:53secs
4 Encodes: 0:28secs

19.0.45

2 encodes: 0:37secs (this works great - way better than 212!)
4 Encodes: 2:28secs (this totally blows)

MC CPU usage goes crazy on my machine when changing from 2 concurrent encodes to 4....is it something with my CPU or what?

VP

[Vocalpoint]

I'm with JimH - A/V needs to be entirely disabled to test.

Will turn it right off and see if we get anything better - but as you can see from my other post - my 2 concurrent encodes in v19 (45) are faster than the same via v18 (212) whereas the 4 concurrent slow it to a crawl.

This has nothing to do with AV - or I would see a problem with the 2 encode test. But I will try it now with NO AV on at all.

Update:

Rebooted. Shut down AV completely. Made sure that MC v19 was the only app running:

19.0.45

2 encodes: 0:38secs (CPU average for Media Center v19.exe *32 = 51%)
4 Encodes: 2:19secs (CPU average for Media Center v19.exe *32 = 92%)

Compared to a CPU average for Media Center v18.exe *32 = 15% regardless of number of concurrent encoders....

Basically - no change.

VP

[JimH]

Turning Antivirus programs off (disabling) is sometimes not enough.  It may require an uninstall if that is the problem.

[Vocalpoint]

Turning Antivirus programs off (disabling) is sometimes not enough.  It may require an uninstall if that is the problem.

Sorry Jim - but I won't be uninstalling my AV since we do not know where the problem lies. A problem - which as of this moment - points directly to the MC exe. (and my CPU - in some weird way)

It's clear that even with AV full on  - v19 works fine when using only 2 concurrent encodes. Any more than that (4) and the v19 exe (Your executable) goes crazy and chews up all available CPU on my system.

I cannot see how this very clear indicator via Task Manager - has the least bit to do with my AV - which BTW - I am also watching in real time (while MC is converting and encoding) and it could care less about Media Center or the actual MC exe file. It's not scanning any of your files while this excessive CPU is happening.

I have been using this specific version (4.2.71.2) of ESET for over three and half years now - and I have never asked the AV to exclude MC over 5 past versions - can't see why it would suddenly be an issue now. Plus V18 works perfectly with the AV full on.

Update: I installed v19 (45) onto a complete different machine with a completely different AV (MSE) - featuring a much more powerful CPU i7 3770 and did the same test - this time the CPU average was around 60% but I could hear the CPU fans kick into very high gear (first time I have ever heard the fans ever come on like this) when I started the conversion.

Using 4 concurrent encodes - this machine was able to complete the job in about a minute.

Conversely - with v18 (212) on the same machine - converting the same files - used 7% of the CPU (average) and completed in 32 seconds - with 4 concurrent encodes. Nice.

VP

[MrC]

There are so many times when users are certain that their AV software isn't the problem.  And they are often mistaken, because AV software is highly complex, and the metrics you see in simplistic tools like Task Manager are not accurate enough to portray what is really going on in an operating system.  There's a Heisenberg principle here, and "charges" for various services that work on behalf of a process are often charged to the process itself (so MC gets the blame when AV code is being run).

See marko's intereting AV problem with images, which turned out to be AV:

   http://yabb.jriver.com/interact/index.php?topic=65921.msg442797#msg442797

and JimH's signature link to the Weird and Wonderful problems wiki page has shown many such occurrences.

Everyone feels your pain, but this is the nature of this type of intrusive software; folks have been dealing with these problems since the advent of (anti-)virus and other (anti-)malware software.  And since these nasty problems do occur, often removing the anti-X software is the only way to eliminate with certainty that it isn't the cause (this time).

[Vocalpoint]

Everyone feels your pain, but this is the nature of this type of intrusive software; folks have been dealing with these problems since the advent of (anti-)virus and other (anti-)malware software.  And since this nasty problems do occur, often removing the anti-X software is the only way to eliminate with certainty that it isn't the cause (this time).

Mr. C

Appreciate the comments - but no one is really "feeling my pain" right now - nor did I ask them to. I am just sharing my experiences with Build 45.

Also - I just posted that I installed this build on another machine and essentially see the same results. Am I supposed to uninstall ALL AV from every computer network wide - just to accommodate some beta build of Media Center? Is that what you are saying?

Apologies - but I don't have the time (or inclination) to start dealing with security issues arising from machines hitting the internet with no AV For now - when I need to convert something - I will stick to 2 concurrent encodes with v19. That seems to work fine - with the AV full on scanning everything in real time.

Or I can just use v18 - since it seems to have no issues with any number of encodes or ANY AV on any PC in the house. Funny how that one seems to work with no issues whatsoever....

VP

[Hendrik]

No one is asking to keep it uninstalled for ever, but it wouldn't hurt to uninstall it and test again, just to make 100% sure thats not it. Thats not really all that much effort.
Especially with weird issues like this, its more common then you think. AVs are extremely intrusive software, they invade your system worse then most virus' would, except that they hopefully do nothing bad.

[Vocalpoint]

No one is asking to keep it uninstalled for ever, but it wouldn't hurt to uninstall it and test again, just to make 100% sure thats not it. Thats not really all that much effort.

I realize that. But on this specific machine - that's not possible due to many factors that do not involve MC.

That said - I am still having a hard time justifying any AV changes - whether on this machine or any others - when I already know that v18 works perfectly with AV fully engaged and v19 does not. Or why v19 burns through conversion successfully with just 2 encoders (again - WITH AV fully engaged) but chokes using 4.

Our HTPC has no AV (I think) - I could install v19 there and see what transpires.

VP

[Matt]

Is CPU usage 0% before you start?

[mojave]

Are both 18 and 19 set to convert audio to the same file path? Originally I had mine set for different hard drives but changed them to the same file path for testing.

18.0.212
4 Encodes of 12 files - 16 bit, 44.1 kHz - FLAC to MP3: 0:30 secs
8 Encodes of 12 files - 16 bit, 44.1 kHz - FLAC to MP3: 0:17 secs

4 Encodes of 10 files - 24 bit, 192 kHz - FLAC to APE:  1:50 secs

19.0.45
4 Encodes of 12 files - 16 bit, 44.1 kHz - FLAC to MP3: 0:26 secs
6 Encodes of 12 files - 16 bit, 44.1 kHz - FLAC to MP3: 0:41 secs
8 Encodes of 12 files - 16 bit, 44.1 kHz - FLAC to MP3: 0:59 secs (CPU at 100%, system unusable)

4 Encodes of 10 files - 24 bit, 192 kHz - FLAC to APE:  2:26 secs  

One main difference between MC18 and MC19 is that MC18 is using much more memory - especially with the increase in encodes. MC19 always seems to use the same amount and much less than MC18. Also, in MC19 whether "play files from memory" is checked seems to affect stability.

CPU use is at 0% before I start.

[Vocalpoint]

Is CPU usage 0% before you start?

Yes. When I start MC - as of this second...I have 0% CPU and approx 25MB of RAM in the private working set. When I fire up the conversion - the CPU immediately ramps to 90+% and stays there. The 4 LAME.exe processes limp along getting whatever they can (usually 3-5%) while all this is going on.

Even better is watching this via the Convertor Queue in MC...you can actually see which conversions are getting some love...all four conversions start up and then three immediately bog down while one grind it out to completion...then another will get some juice and roll while the others lag behind. This trade off continues over the 2:30 time span until all files are done.

Cheers,

VP

[Vocalpoint]

Are both 18 and 19 set to convert audio to the same file path? Originally I had mine set for different hard drives but changed them to the same file path for testing.

I am sending the converted files to the same exact path in each version.

Also, in MC19 whether "play files from memory" is checked seems to affect stability.

Will check this out....

Are you guys also converting the VBR Extreme?

VP

[mojave]

I realized my MP3 settings were different with MC18 and MC19. MC18 was VBR Normal and MC19 was CBR 320.

Here it is with VBR Extreme:

18.0.212
8 Encodes of 12 files - 16 bit, 44.1 kHz - FLAC to MP3: 0:17 secs

19.0.45
8 Encodes of 12 files - 16 bit, 44.1 kHz - FLAC to MP3: 0:51 secs

[MrC]

I used VBR extreme only on some later tests with fewer than 8 encodes.

So I reran some tests using it.  Two results:

2:35 and 4:45 (vs. 1:17 from above)

There is definitely some stalling that occurs.  MC hogs the CPU, leaving nothing for the lame.exe processes, which go idle.  So the results vary widely.

[Matt]

Could you try changing input and/or output formats?

My guess is that there's some busy loop in the player core, but it would be good to rule out a FLAC input or MP3 output issue.

It must also require some tipping point for something that only sometimes engages (like a prebuffering loop or something) that I haven't yet been able to hit in the debugger.

[MrC]

Flac -> MP3 (extreme): 2:35
Flac -> MP3 (extreme): 4:45
---
Flac -> APE (ext high):  1:06.  (PF delta 10000+)
APE -> MP3 (extreme):  1:43   (PF delta ~1200-2500)
APE -> MP3 (extreme):  2:37
APE -> MP3 (extreme):  1:46
WAV -> MP3 (extreme):  1:50
MP3 -> OGG (high):       3:00   (PF delta ~700)
APE -> WAV:                0:39
FLAC -> WAV:                0:20

[MrC]

It seems mp3 might be the common factor.

[MrC]

I ran 8 command line versions (keeping the command pipeline full at 8) against the same files:

$ time seq 18 | parallel 'flac -s -d -c {}.flac | lame -S -V 0 -vbr-new  - - > {}.mp3'

38.44 seconds
32.39 seconds
32.53 seconds

MC is sucking eggs in this task.  :-)

[Vocalpoint]

MC hogs the CPU, leaving nothing for the lame.exe processes, which go idle.

Yes - this is exactly what I am seeing....

Thanks guys for your input on this one.

Cheers,

VP

[Matt]

Next build:
Fixed: During conversion or audio analysis, the process could slow down unexpectedly if the input thread was running much faster than the output thread.

Thanks for everyone's help tracking it down.

[Vocalpoint]

Next build:
Fixed: During conversion or audio analysis, the process could slow down unexpectedly if the input thread was running much faster than the output thread.

Thanks for everyone's help tracking it down.

Wow! You guys rock as usual.

Many thanks.

Cheers,

VP

[MrC]

The new build:

Flac -> MP3 (extreme):  0:31

Nice.

[Vocalpoint]

The new build:

Flac -> MP3 (extreme):  0:31

Nice.

Sweet!

VP

[mojave]

Analyze audio is a lot faster, too. Thanks.