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: Files could not be written (bad allocation) ERRORs (Read 5963 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Files could not be written (bad allocation) ERRORs

Hello, I am running Windows 7 32bit (full updated, any patch installed and so on) and Foobar 1.3.14.
Since a lot of weeks I have these two errors:
1)
Error writing library files.
Library files could not be written (bad allocation)

2)
Error writing playlist files.
Playlist files could not be written (bad allocation)

These two errors are blocking because Foobar crashes just a few seconds after or crashed without displaying anything.

I tried to fix the problem myself, running chkdsk, fsc, and reinstalling Foobar from scratch, as well reinstalling VC++ libraries and others, but NO WAY to have foobar working anymore as before.

I need help.
Thanks and regards
Andrea

Re: Files could not be written (bad allocation) ERRORs

Reply #1
Have you checked the SMART values of your HDD? I wouldn't be surprised if the drive is dying.

Re: Files could not be written (bad allocation) ERRORs

Reply #2
That can happen if you have super huge library and foobar runs out of memory. On a 32-bit operating system the player can't use more than 2 GB of memory by default. Remember that pretty much all tag info is kept in memory so the more tracks you have the more memory is required.

Re: Files could not be written (bad allocation) ERRORs

Reply #3
Hello, the drives are awaken, I think it is the problem of run out of memory...
I try by removing one HD out of the library.

In the case it is confirmed, any workaround for that?
I mean, if I buy a 64 bit new PC, is it guaranteed to fix the problem?
Regards
Andrea

Re: Files could not be written (bad allocation) ERRORs

Reply #4
Unfortunately not. 64-bit OS allows foobar2000 to use up-to 4GB of memory but if you exceed that amount things will crash.

Are you using your own foobar2000 installation or are the settings copied from someone else? I ask because foobar v1.3 introduced a feature that allows keeping extra large tag fields away from memory exactly to lower the memory usage. Its configuration is in LargeFieldsConfig.txt file and a custom version could disable the feature.

What you can do even without buying a new computer is to enable OS feature that allows programs to use up-to 3GB of memory. You can do that by opening administrative command prompt and entering the following command there: bcdedit /set IncreaseUserVa 3072.
It takes effect after a reboot.

Another option is to check what kind of tag fields your files have and alter the LargeFieldsConfig.txt file to better suit your case.

 

Re: Files could not be written (bad allocation) ERRORs

Reply #5
Dear Case, the Foobar installation I am using is coming from an old 1.x of 2012 then updated over the time.
I will try what you suggest and I will update all here.
Thanks and regards
Andrea

Re: Files could not be written (bad allocation) ERRORs

Reply #6
Dear Case, the file "LargeFieldsConfig.txt" is in the proper directory and this is its content:

# Any changes in this file will take effect on next foobar2000 startup.
# Note, size limit values are in UTF-8 bytes, not characters!
# Size limit for meta fields that appear in the basic fields list
basicMetaMax=1000
# Size limit for meta fields that do not appear in either list
defaultMetaMax=300
# Size limit for tech info fields
infoMax=200

# List of basic meta fields - essential info such as artist & title
fieldBasic=album
fieldBasic=album artist
fieldBasic=artist
fieldBasic=composer
fieldBasic=conductor
fieldBasic=date
fieldBasic=discnumber
fieldBasic=genre
fieldBasic=keywords
fieldBasic=performer
fieldBasic=producer
fieldBasic=style
fieldBasic=title
fieldBasic=totaldiscs
fieldBasic=totaltracks
fieldBasic=tracknumber

# List of spam meta fields - rarely useful stuff that *never* gets cached
fieldSpam=accurate rip
fieldSpam=aucdtect
fieldSpam=biography
fieldSpam=cuesheet
fieldSpam=eac logfile
fieldSpam=itunes_cddb_1
fieldSpam=itunmovi
fieldSpam=log
fieldSpam=logfile
fieldSpam=lyrics
fieldSpam=unsynced lyrics

Re: Files could not be written (bad allocation) ERRORs

Reply #7
Dear Case, even with your tip applied, 3GB memory to app, Foobar2000 crashes with that errors.

Before to close the app, I checked the used memory and it was 2.445.772 KB.

Any further help for me?

Many thanks and kind regards,
Andrea

Re: Files could not be written (bad allocation) ERRORs

Reply #8
How many files you have in library?

Re: Files could not be written (bad allocation) ERRORs

Reply #9
Have you tried what happens on a fresh (portable) install? I have a sizable library with a good variety of random components and I have never seen it above ~400mb ram usage. Getting anywhere close to 2-3GB sounds crazy to me unless you really do have a massive library. In what fashion does it climb to that ram usage? Is it linked to any specific action like setting up your media library? Have you tried pointing it to a random folder with just couple of files in it, and see how much RAM is used then? Then feed it increasingly bigger folders to see how quickly your RAM usage climbs.

Re: Files could not be written (bad allocation) ERRORs

Reply #10
Would be curious indeed to know how many files you have in the library.
Others asked if you have tried without any third party components. Some components can increase memory usage needlessly.
How much memory does foobar2000 use while it's running normally before you try to close it?

Note that you can't have paging file disabled or too small. If foobar2000 tries to allocate 3 GB it will need other programs to be able to use the hard drive as temporary memory.

If you have a huge number of files I suggest trying to lower the numbers in the LargeFieldsConfig.txt file. You could try for example
basicMetaMax=256
defaultMetaMax=128
infoMax=64

Re: Files could not be written (bad allocation) ERRORs

Reply #11
Dear All, I do live recording and I don't know how many files I have (never counted).
Probably are over 500'000. I can tell you that I have about 12TB of audio files and about 6000 authors catalogued (manually divided in 6019 folders).
Foobar2000 became instable when passing the 6010 authors or so.
Now it is crashing with 6019 authors/folders indexed.

Now I am away for work (recording) and I will be back in 6 weeks. I will then try to make a new installation in a fresh new Windows machine. On the same machine, I remove all, purged any related directory and reinstalled all at least 2 times yet.

Any option to get ride of the "nasty" old Foobar2000 dBase and use an external SQL dBase?

Regards
Andrea

Re: Files could not be written (bad allocation) ERRORs

Reply #12
I'm sorry to disappoint you but foobar2000's library is not designed to handle this amount of files and will inevitably give you trouble.

The subject has already been thoroughly researched by me and cannot be just fixed without breaking plug-in compatibility, which is something we do not wish to do at this point of time.

I can only recommend that you try another player if you absolutely require your player to index that many files.

Alternatively, disable foobar2000's media library and use Windows Explorer or another external app to navigate your music library content send music to foobar2000 from there.
Microsoft Windows: We can't script here, this is bat country.

Re: Files could not be written (bad allocation) ERRORs

Reply #13
Dear Peter, thanks for your clear reply.

If I can ask here, would be so nice to notify me about a good player that could be able to correctly manage my large library and having VST host capability like foobar?

Many thanks and kind regards
Andrea

Re: Files could not be written (bad allocation) ERRORs

Reply #14
Dear Case, your proposed solution works for me.

I currently set as follows:
basicMetaMax=100
defaultMetaMax=50
infoMax=50

Doing so, Foobar occupies only 1.8 GB and runs perfectly.
Many thanks for your help.
Regards
Andrea

Re: Files could not be written (bad allocation) ERRORs

Reply #15
Dear All, the new version 1.3.16 is not working anymore exceeding the 2.2 GB size.
It looks like the new 1.3.16 doesn't read/use the LargeFieldsConfig.txt
Can you help me?
Many thanks and kind regards
Andrea

Re: Files could not be written (bad allocation) ERRORs

Reply #16
Hi All,
I had this problem with v1.3.16 as well.  Foobar was consuming large amounts of RAM but I fixed the problem by performing a fresh install, going into Preferences --> Media Library --> Reset All.  Then apply your theme/skin if you have one.

Re: Files could not be written (bad allocation) ERRORs

Reply #17
I'm seeing the same warning often, since I installed beta version 17, a few days ago. My library is much smaller than Andrea's, though: 2TB and 220.000 tracks, and memory usage is within the usual values (5-600 MB) when this happens.



I'm sorry to disappoint you but foobar2000's library is not designed to handle this amount of files and will inevitably give you trouble.

Peter, what is the maximum library size foobar2000 can handle comfortably?


I'm late

Re: Files could not be written (bad allocation) ERRORs

Reply #18
If you have a huge number of files I suggest trying to lower the numbers in the LargeFieldsConfig.txt file. You could try for example
basicMetaMax=256
defaultMetaMax=128
infoMax=64

I tried halving all the values in the LargeFieldsConfig.txt file and now foobar2000 is using over 3000 MB of memory (5 times more than usual). Does that make sense?
I'm late

Re: Files could not be written (bad allocation) ERRORs

Reply #19
Peter, what is the maximum library size foobar2000 can handle comfortably?
I'm not Peter but I don't think that can be answered. It depends so much on tag contents.

I tried halving all the values in the LargeFieldsConfig.txt file and now foobar2000 is using over 3000 MB of memory (5 times more than usual). Does that make sense?
No it doesn't. Perhaps you made a typo somewhere and disabled some spam fields for example. Unless that's just some one-time issue and restart of player solves that. Or it's a new bug. Please keep experimenting.

Re: Files could not be written (bad allocation) ERRORs

Reply #20
I tried halving all the values in the LargeFieldsConfig.txt file and now foobar2000 is using over 3000 MB of memory (5 times more than usual). Does that make sense?
No it doesn't. Perhaps you made a typo somewhere and disabled some spam fields for example. Unless that's just some one-time issue and restart of player solves that. Or it's a new bug. Please keep experimenting.

It was probably a one-time issue as you said. It took about half an hour to slowly, but constantly reduce memory usage to 8-900 MB, and never rise again. I'm pretty sure my memory usage issues are enhanced by the foo_customdb plugin, but they got a lot worse since I updated from beta 15 to beta 17. I'll experiment with both versions for a while and trace the differences.

P.S: After seeing several bad allocation warning as mentioned by the OP, I found out some of my playlists's content is actually lost.
I'm late

Re: Files could not be written (bad allocation) ERRORs

Reply #21
I've been on a 2-days honeymoon with beta version 15, but it's over. Since a few minutes the bad allocation warnings are back, triggered by the attempt to close the application or save the configuration.
I didn't just downgrade from beta 17, I rebuilt the whole configuration from scratch to make sure everything was as clean as possible. Therefore I did not save my previous edits to the LargeFieldsConfig, which was restored to default settings. At the time the warnings show up, though, memory usage is well within average values, around 5-600 MB. So, according to the task manager foobar2000 is not running out of memory, but I have other symptoms of memory shortage. Right before the warnings appear, the thumbs in the EsPlaylist panels and some Panel Stack Splitter images start disappearing randomly (see attached picture). When this happens I know the player will become unresponsive and I won't be able to shut it down without crashing. Overall, since some beta versions ago (I can't recall exactly which one), every action that involves a massive metadatabase change, such as adding music to the library or editing tags, is likely to make foobar2000 freeze or even crash and I also happened to see this other kind of bad allocation warning which I never saw before.
I know that my setup is burdened by the foo_customdb plugin, but I've been using it for over 2 years and I never had these warnings before, nor those PSS rendering flaws. For the record, besides upgrading to the beta version, the only other major changes that occurred previous to these issues are the upgrade of the Jscript panel to version 2 and decompressing the main library drive, after moving part of the files to a new one. My library is presently about 2TB and 220.000 tracks.

BTW, how are we supposed to react to that writing files error warning? We're given two options: cancel and loose all changes (I actually lost some entire playlists by doing this, not only the unsaved changes) or retry, which triggers a new error warning...
I'm late