Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: foo_wave_seekbar (Read 818009 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

foo_wave_seekbar

Reply #750 –
Yes, the latest stable 0.2.12.
The new 0.2.13.1 completely refuses to play with foobar. At startup it says it was not for this version of foobar or something like that (1.1.6), I test on another machine where I have tried 1.1.6 some time ago, I installed 1.1.7, and the installation told me similar things, the component not installed correctly, or not meant for this version of foobar...
Quote
Failed to load DLL: foo_wave_seekbar.dll
Reason: This component is missing a required dependency, or was made for different version of foobar2000.

The stable version at least worked to start.
Anyway, I'm forced to wait for a stable release though. Not bound to alpha versions of any software I use.

(I just saw few pages ago a discussion about the same problem as you mentioned  ). The new alpha version is about 500KB smaller, and since it is not working for me, I'g guess you made many other changes to it (apart from the additional 2 dlls involved). Is there a version where just this bug was fixed?

foo_wave_seekbar

Reply #752 –
As the first page of the thread says, and as the post where the new version is introduced, it now depends on the VC++ 2010 SP1 (x86) runtime, due to it being a build from my work-in-progress sources at the time.
The reason for it is moving out the optional frontends (D3D, D2D) into separate DLLs, necessitating the use of a dynamic runtime to avoid massive restructuring.

And no, there is no bugfix release with just that bugfix, due to some version control accidents.
Stay sane, exile.

foo_wave_seekbar

Reply #753 –
I apologize  .
I tested it on my own system now, and it seems to work. I have VS2010 here in fact and that seems to have helped. Or some other software installed it as part of its installation.
The interesting part is now I see the DX 9.0c frontend and I haven't installed any additional DX redistributables (as I mentioned before).
Hoping it is stable enough not to crash on me on everyday music listening.
Thanks.
Still waiting for a stable release  .

EDIT: Nevermind, it seems under GDI foobar eats less memory, and it seems after the initial memory increase, foobar stabilizes, even with the component.

foo_wave_seekbar

Reply #754 –
Still, after 2 days the player ate another about 20-25MB, I don't know whether waveform seekbar is at fault again. Totalling 60MB. The process is slower this time but still eating memory for some reason.

foo_wave_seekbar

Reply #755 –
Quote from: tedych on
Still, after 2 days the player ate another about 20-25MB, I don't know whether waveform seekbar is at fault again. Totalling 60MB. The process is slower this time but still eating memory for some reason.

Is it really an issue? My foobar instance starts with ~90 MB of ram and stabilises at 130-140MB.

foo_wave_seekbar

Reply #756 –
Yes, it is an issue. Still not sure if this is caused by the seekbar. I'll wait for few days to see at what level it would stabilize.
140MB of RAM is way too much for a simple player as this one. I have 8 gigs of ram, but there are many other things hungry for ram, and also many other small ones (like the player) that are small enough but useful to not geting in the way in any way.
Again, I used winamp with 40 megs so far, and I found foobar to have better playlist management and display. Other than that I don't find any other thing that would have helped with the switch away from Winamp. Only the playlist management and the wider volume control (and this seekbar of course). If this player proves a resource hog (4-5 times more ram than w/amp), I'll sacrifice these things, honestly.
In our local forums here, I pointed out the problem, and many people responded they notice the same thing. It was supposed to be much lighter than other players, namely winamp. Was a nice try though. This time I will try without wave seekbar to see the ram consumption.

foo_wave_seekbar

Reply #757 –
Quote from: tedych on
Yes, it is an issue. Still not sure if this is caused by the seekbar. I'll wait for few days to see at what level it would stabilize.
140MB of RAM is way too much for a simple player as this one. I have 8 gigs of ram, but there are many other things hungry for ram, and also many other small ones (like the player) that are small enough but useful to not geting in the way in any way.
Again, I used winamp with 40 megs so far, and I found foobar to have better playlist management and display. Other than that I don't find any other thing that would have helped with the switch away from Winamp. Only the playlist management and the wider volume control (and this seekbar of course). If this player proves a resource hog (4-5 times more ram than w/amp), I'll sacrifice these things, honestly.
In our local forums here, I pointed out the problem, and many people responded they notice the same thing. It was supposed to be much lighter than other players, namely winamp. Was a nice try though. This time I will try without wave seekbar to see the ram consumption.

Ridiculous. With 8 gigs you worry about foobar taking up 60+ megs, and you even have extra panels...
Anyway. The more stuff you use the more memory is needed especially with visual stuff.

By the way. This is anything but a simple player.

foo_wave_seekbar

Reply #758 –
Leaks should not exist, no matter if you have gobs of memory or not. I wish I had time to comb through the component and clean up ownership issues. In the end, in deployed software, I'd rather err to the side of leaking than to use dangling objects as they tend to be very painful to debug, especially if mutated after their death.

I had a very elusive memory clobber bug a good while ago that only occured in very special configurations, where an ATL window frame suicided (delete this) and modified a member afterwards.

Back to the issue at hand though - address space is a very limited resource, particularly in such a rich client as foobar2000, which is very limited in this regard as it is a 32-bit application. At best we get four gigs of address space on x64 Windows, with chunks eaten up by libraries, graphics APIs, and so on. Every little bit counts, particularly as leaks love to fragment the heaps.
Stay sane, exile.

foo_wave_seekbar

Reply #759 –
Quote from: tedych on
140MB of RAM is way too much for a simple player as this one. I have 8 gigs of ram...

Unused RAM is wasted RAM. With 8 GB you won't notice a difference, unless running some heavy image/video editing processes. And yeah foobar isn't exactly a "simple" player.

foo_wave_seekbar

Reply #760 –
The OS will ensure that it's very rare that physical memory is completely unused. If it's not populated by data pages from working sets, it will use it for assorted caching (including filesystem cache.
What you will end up wasting if you're leaking, assuming that no part of a leaked page is hot, is that your swap file will accumulate dead pages. If you're one of those strange people that disable swap files because "you have enough memory, lol" you're doing your machine a disservice as you will force cold pages to stay resident in physical memory.

Please avoid derailing this thread with the pros and cons of the memory system. Mark Russinovich has some lovely articles if you want to educate yourself.
Stay sane, exile.

foo_wave_seekbar

Reply #761 –
Zao, thanks.
Still, I will leave the player with your component active for few weeks and will watch the memory. If it goes too much up, I'll remove it and test for another week or so.

Yes, the OS is taking care of the free memory as of Vista and 7, effectively. No need to talk about why I have 8GB (which is somewhat not that much already), most of the time I have 120+ processes, and 3.5 to 4+GB actively taken and used. I use virtual machines extensively, easily going up to 7.5 used GBs. The cache itself is beyond 3GB most of the time. Strangely enough I keep 12GB of swap, totalling 20GB virt. memory, but as long as I have HD space, won't decrease it.
Anyway, that was not the point, the point was that every MB counts after a point when such a program passes. Maybe the 100MB limit is the psychological one for me.
Memory leaks are one of few things I'm most afraid of. Not to mention the security implications they might have on the system.

foo_wave_seekbar

Reply #762 –
I'm having a problem. Every time I play a song that hasn't already been scanned by wave seekbar, after 1 second it produces a skip in the music, which corresponds with the seekbar showing up. So that means that the plugin scanning and finally displaying the seekbar produces a skip in the song. I am using 13.1

foo_wave_seekbar

Reply #763 –
Somekind of length limit would be nice. A few days ago I tried playing a DTS file. It appeared to be six hours lon (erroneously though because it was a two hour movie). Anyway foobar ended up maxing the cpu for a long time. After I got fed up I restarted switched to another file restarted again, but I still had max cpu usage. After I deleted the wave cache it was working normally again.

foo_wave_seekbar

Reply #764 –
Such a time limit would backfire on real-world files.
I have several single-file mixes that are well over four hours. They scan in way less than a minute, as the analysis is essentially decoder-bound in speed.

I would recommend not adding non-music files, or wait for the day in the far future when I implement blacklists.
The reason why it restarted the scan when you restarted foobar2000 is because it remembers the jobs it had pending when shutting down and restores them from the database on startup. If you've got some job you don't want, you can open the database and clear out the job table.
Stay sane, exile.

foo_wave_seekbar

Reply #765 –
Quote from: Dexter_prog on
... after 1 second it produces a skip in the music, which corresponds with the seekbar showing up ...

Which frontend are you using? Have you've messed with the buffering amount or priority of foobar's playback?
Even if I'm blocking something, there should be quite enough audio data buffered up to ensure glitchless playback.
The Direct2D backend should do all updating in a background thread, and there shouldn't be anything overly expensive going on in the Direct3D frontend.
The D3D and GDI ones do do things in the main thread (out of necessity for the former, and laziness for the latter).
Stay sane, exile.

foo_wave_seekbar

Reply #766 –
Quote from: Zao on
Such a time limit would backfire on real-world files.
I have several single-file mixes that are well over four hours. They scan in way less than a minute, as the analysis is essentially decoder-bound in speed.

I would recommend not adding non-music files, or wait for the day in the far future when I implement blacklists.
The reason why it restarted the scan when you restarted foobar2000 is because it remembers the jobs it had pending when shutting down and restores them from the database on startup. If you've got some job you don't want, you can open the database and clear out the job table.

Yeah, blacklisting would be nice. Or an easy way to cancel the problematic job.

How do I open the database by the way?

foo_wave_seekbar

Reply #767 –
It's a SQLite3 database file, so you need to download sqlite3.exe and invoke it like sqlite3 D:\apps\foobar2000\wavecache.db without foobar2000 running.
In there, you can DELETE FROM job; to destroy all pending jobs or SELECT * FROM job; to list all the pending jobs.
You can also get rid of particular waveforms by removing entries from the file table.
Stay sane, exile.

foo_wave_seekbar

Reply #768 –
Quote from: Zao on
Quote from: Dexter_prog on
... after 1 second it produces a skip in the music, which corresponds with the seekbar showing up ...

Which frontend are you using? Have you've messed with the buffering amount or priority of foobar's playback?
Even if I'm blocking something, there should be quite enough audio data buffered up to ensure glitchless playback.
The Direct2D backend should do all updating in a background thread, and there shouldn't be anything overly expensive going on in the Direct3D frontend.
The D3D and GDI ones do do things in the main thread (out of necessity for the former, and laziness for the latter).

I am currently seeing if the culprit actually was foo lyrics and not waveforme seekbar. Right now I am pretty sure it was the lyrics or a combination of both (or some fucked up setting in my config).

foo_wave_seekbar

Reply #769 –
Ok, both waveform seek bar and foo_uie_lyrics2 make the CPU go to 100% and that is what produces the crackles in the music. I tried disabling one and then other one and both separately produce cpu spikes, then I removed both and cpu doesn't go over 50% when changing tracks. I tried all renders in Waveform, no change.

foo_wave_seekbar

Reply #770 –
Can't get 0.2.13.1 to work. Win XP SP3. DirectX end-user runtime and Visual Studio 2010 SP1 (x86) runtime are installed.

Message in console: UI Element instantiation failure: boost::filesystem::directory_iterator::construct:

What am I missing?
 

foo_wave_seekbar

Reply #771 –
Do you have your foobar2000 profile in some strange place, with non-ASCII characters in the path perhaps? I see you're russian, so that's probably the case.
Stay sane, exile.

foo_wave_seekbar

Reply #772 –
Quote from: Zao on
Do you have your foobar2000 profile in some strange place, with non-ASCII characters in the path perhaps? I see you're russian, so that's probably the case.


Yeah, I have Russian word in the path. But the older version of this plugin (0.2.12) works perfectly with the same path.

foo_wave_seekbar

Reply #773 –
It's a known bug. I moved out the frontends (d2d, d3d) into separate DLLs. The function that looks for the companion DLLs is broken on most locales if you use non-ASCII codepoints in paths, and on more exotic locales, probably completely broken. It is fixed in my personal builds, but I haven't made any release of it yet.
Stay sane, exile.

foo_wave_seekbar

Reply #774 –
Thanks for help. Just tried Portable Mode with different path and it works.