problem with the foo_input_std.dll!, it make playing mp3 not good! Options

[jako]

it will make me wait when drag the bar forward!!

but when i replace the file foo_input_std.dll in 0.7.7a with the file in 0.7.7,it works fine!!!!!!!

[Peter]

Please stop posting BS bug reports... you apparently have foo_nero configured to takeover MP3 and replacing foo_input_std changed dll loading order, so it took MP3 format back.
If you start flooding useless posts once again, you WILL be banned, this is your final warning.

[jako]

Please stop posting BS bug reports... you apparently have foo_nero configured to takeover MP3 and replacing foo_input_std changed dll loading order, so it took MP3 format back.
If you start flooding useless posts once again, you WILL be banned, this is your final warning.

what????

i don't have foo_nero at all!!!!

i am not a fool!!!

why post a useless report????

if you don't want to accept my report ,i'll never report!!!!

i just like foobar2000,and i hope it perfect.

i really don't like the tone of you talking to me!!!

[Peter]

1. You started two threads about the same subject, instead of replying to old one (which I removed after your new post). You already have plenty of warnings for similar activities, I could have just pushed the b-button and moved over. Please don't make me regret not doing so.
2. Your bug report doesn't provide any useful info about components you run, or about your system. Since you are the only person to experience this problem, some kind of user error is to be assumed.

[jako]

winXp Pro Sp1

p4, soundcard on board(ct5880,creative)

foobar2000 0.7.7a(minimum install)

it will have no problem if replace the foo_input_std.dll with the file in 0.7.7.

[/\/irana]

I also have this problem in 0.7.7a and 0.7.7b.Seeking very slowly with mp3(only mp3)
When I dragged the seekbar,cpu usage jumpped to 100%,playback stopped,system became very lag,seemed to be locked;several seconds later,playback resumed,cpu usage decrease to 0%
The mp3 files aren't very long,just about 4~5 minutes
changing output method didn't affect this problem
Everything works fine in 0.7.7

0.7.7a(0.7.7b) clean install(minimum)
P4-M 1.6G
SiS 7012 Audio driver
winxp pro sp1

[Peter]

See if the problem persists on files that have only lower ASCII characters in their path. Yes I know this sounds stupid but seektable manager identifies files by stricmp_utf8, only 0.7.7=>0.7.7a change was in the way towlower() is called, so it appears that what you get is caused by towlower() returning different values when called twice when same input (input being chineese characters).
If you get different sticmp on strings that are strcmp-identical, I don't want to know what else doesn't work for you.

[/\/irana]

Tested
You are right.It works fine on files that have only ASCII characters(including both lower and upper) in their path.But if there are some Chinese characters in the path,seeking speed become very very slow.
I don't know why towlower() didn't work for Chinese characters.Hmm...Chinese characters even haven't the concept of lower or upper case
Could you please fix it?It's very annoying.
Thanks advance

[Peter]

Fix - absolutely yes, I've put several different hackfixes for it in current internal build, you're free to use 0.7.7 foo_input_std.dll or to remove setlocale() from char_lower/char_upper in pfc/utf8.cpp in 0.7.7a SDK then compile, or I'll put a "fixed" DLL when I have time (components made with current internal SDK won't load in 0.7.*, I'd have to pull old source from archive again to compile). I'm trying to understand what the heck causes it, because if it's towlower() fault, you probably have worse problems than slow mp3 seeking.

[/\/irana]

I see,thanks for clarifying it.

[Peter]

Temporary fix here.

[bluenet]

Replace the foo_input_std.dll,but the problem seem not fix.
I test in Chinese directory,and the foo_input_std.dll in 0.7.7 is fine.

[Peter]

Get 0.7.7c. This will work for sure, no setup available at the moment (Case is away).