HydrogenAudio

Hosted Forums => foobar2000 => Support - (fb2k) => Topic started by: AndreaT on 2017-02-28 12:03:22

Title: Files could not be written (bad allocation) ERRORs
Post by: AndreaT on 2017-02-28 12:03:22
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
Title: Re: Files could not be written (bad allocation) ERRORs
Post by: Daeron on 2017-02-28 12:28:39
Have you checked the SMART values of your HDD? I wouldn't be surprised if the drive is dying.
Title: Re: Files could not be written (bad allocation) ERRORs
Post by: Case on 2017-02-28 21:46:27
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.
Title: Re: Files could not be written (bad allocation) ERRORs
Post by: AndreaT on 2017-03-01 17:28:50
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
Title: Re: Files could not be written (bad allocation) ERRORs
Post by: Case on 2017-03-01 19:27:53
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.
Title: Re: Files could not be written (bad allocation) ERRORs
Post by: AndreaT on 2017-03-04 11:42:03
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
Title: Re: Files could not be written (bad allocation) ERRORs
Post by: AndreaT on 2017-03-04 11:44:35
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
Title: Re: Files could not be written (bad allocation) ERRORs
Post by: AndreaT on 2017-03-04 12:14:30
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
Title: Re: Files could not be written (bad allocation) ERRORs
Post by: Rollin on 2017-03-04 12:50:17
How many files you have in library?
Title: Re: Files could not be written (bad allocation) ERRORs
Post by: Daeron on 2017-03-04 14:25:11
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.
Title: Re: Files could not be written (bad allocation) ERRORs
Post by: Case on 2017-03-05 10:32:43
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
Title: Re: Files could not be written (bad allocation) ERRORs
Post by: AndreaT on 2017-03-08 19:23:35
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
Title: Re: Files could not be written (bad allocation) ERRORs
Post by: Peter on 2017-03-09 06:50:58
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.
Title: Re: Files could not be written (bad allocation) ERRORs
Post by: AndreaT on 2017-03-09 20:08:07
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
Title: Re: Files could not be written (bad allocation) ERRORs
Post by: AndreaT on 2017-04-19 21:24:56
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
Title: Re: Files could not be written (bad allocation) ERRORs
Post by: AndreaT on 2017-08-11 06:53:17
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
Title: Re: Files could not be written (bad allocation) ERRORs
Post by: pwye on 2017-08-30 12:59:19
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.
Title: Re: Files could not be written (bad allocation) ERRORs
Post by: davideleo on 2018-06-23 17:28:59
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?


Title: Re: Files could not be written (bad allocation) ERRORs
Post by: davideleo on 2018-06-23 18:07:42
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?
Title: Re: Files could not be written (bad allocation) ERRORs
Post by: Case on 2018-06-24 08:39:17
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.
Title: Re: Files could not be written (bad allocation) ERRORs
Post by: davideleo on 2018-06-25 16:42:26
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.
Title: Re: Files could not be written (bad allocation) ERRORs
Post by: davideleo on 2018-06-27 15:48:41
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 (https://hydrogenaud.io/index.php/topic,116139.0.html) 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...