[SOLVED] RPi out of memory

[Sunfish]

I'm using an mpdignore file with 64bit and it's fine.  My mpdignore just contains a single wildcard to exclude everything in the directory though.  Is yours more complex?

My mpdignore contains only an *.

[Tim Curtis]

Are u running a local display?

[Sunfish]

Are u running a local display?

I'm running a very basic version of MoOde, no renderers, no local display, no wifi, no filtering (Camilla etc).
Only thing actively running is samba, so I can add music to the usb HD attached to the rpi.
I connect to the rpi SSH with Moxterm.
Listening radio and playing music via the MoOde UI.

[TheOldPresbyope]

Several years ago when large libraries were a point of contention, I started to build a test to quantity the problem. I put the work aside when we downsized to move. Seems like I should resurrect it when we finish the trip we’re on. 

Clearly, a simple track-count measure is inadequate because the size of the mpd “database” and the moOde-generated views depends on the amount of track metadata. I’ve outlined a test which would systematically grow a library with synthetic tracks fully populated with metadata and coverart.

Be home this coming weekend.

Regards,
Kent

[Sunfish]

I will try to make a HD with about 1.5GB music later this week. Will update you on this.
In the meantime I found out that .mpdignore, which is working properly in the legacy version of MoOde, is omitted in the 64bit version. Maybe this is related. The section with .mpdignore contains files with unusual long entries in performer, artist etc. 
Will try to sort that out, time permitting.
regards

For your information.
I did copy 1.48Gb of music to a separate HD, I made sure no directories of the .mpdignore section were present. Burned a fresh copy of MoOde 8.3.3
Did update the library several times also regeneration of the library.
In all instances MoOde was working properly. Also after rebooting (with restart and hard reboot) it continues working.
Next step is to increase the library to about 2.5GB. If that continues working I will include files from the mpdignore section to see if that will cause the system to stop
Regards

[EarsOfAnEagle]

If your 4TB drive is acutally using 3.82TB, perhaps it's the hard drive that is in fact out of storage capacity (depending on formatted capacity), not out of "memory".  Moode would then be unable to write any system/cache/temp files to the drive (not that I know that it does).

Just a fleeting thought.

[Sunfish]

If your 4TB drive is acutally using 3.82TB, perhaps it's the hard drive that is in fact out of storage capacity (depending on formatted capacity), not out of "memory".  Moode would then be unable to write any system/cache/temp files to the drive (not that I know that it does).

Just a fleeting thought.

Thanks for the suggestion. I know for 100% that nothing is written to the drive. But I have to admit that I was entirely wrong on the size of my harddrive. The size actually is 8TB, so near 50% capacity used.

[Sunfish]

I did several tests with libraries up to 3.6TB. 
1st test was with known good files, result was that the library was build properly and MoOde was working as expected. No extreme usage of memory noted.
2nd test was introducing an .mpdignore file in an already indexed folder. Again everything was working as expected. The memory usage on the other hand was jumping to about 85% of the available 0.98Gb, jumping back to less than 25% quickly.
Taking into account my first observation on files with long filenames, metadata etc, my conclusion is that the combination of long metadata fields in the audiofiles (FLAC) is causing mpdignore to choke. Recovery after this event has happened is, as far as I can tell, not possible because as soon as the MoOde Ui is opened the same event is triggered again. So the only question remaining which file is causing the problem this particular case, 
"php-fpm7.4" "mpdignore", or both.



For now I removed the files causing the problems to a different location so I can enjoy listening to MoOde 64bits.

[Tim Curtis]

I did several tests with libraries up to 3.6TB. 
1st test was with known good files, result was that the library was build properly and MoOde was working as expected. No extreme usage of memory noted.
2nd test was introducing an .mpdignore file in an already indexed folder. Again everything was working as expected. The memory usage on the other hand was jumping to about 85% of the available 0.98Gb, jumping back to less than 25% quickly.
Taking into account my first observation on files with long filenames, metadata etc, my conclusion is that the combination of long metadata fields in the audiofiles (FLAC) is causing mpdignore to choke. Recovery after this event has happened is, as far as I can tell, not possible because as soon as the MoOde Ui is opened the same event is triggered again. So the only question remaining which file is causing the problem this particular case, 
"php-fpm7.4" "mpdignore", or both.



For now I removed the files causing the problems to a different location so I can enjoy listening to MoOde 64bits.

How were you able to determine which files were triggering the issue?

[TheOldPresbyope]

I confess I overlooked your early remark about files with long metadata field entries but in any case it was made in the context of .mpdignore.

It seems to me we haven’t unraveled this combination of large number of files/directories, use of .mpdignore, and files with large metadata field entries.

Have you tried using a (presumably smaller) library containing only the files you suspect and without any .mpdignore file?

Note that using a .mpdignore file requires mpd to do pattern matching on all file and directory names in and below the directory containing it. I don’t know my way around the relevant mpd code and don’t know how efficient it is. 

Regards,
Kent