mpd: problem starting

[TaoTePuh]

Thanks for the sudo correction. I start mpd as root (bootlocal.sh) but with "user    tc" in mpd.conf.

[SamK]

...didn't try it yet with less than 512 MB though...

I'm not sure whether this help or hinders your discussion but offer my recent experience with TC3.1+MPD.  

During a testing phase over the last few days, MPD ran on a machine with 128MB RAM of which 16MB was reserved for the video graphics, leaving 112MB available for use by apps.  The music directory was an NTFS partition on an external USB HD accessed via ntfs-3g.  It contained many hundreds of directories holding many thousands of files.

MPD was started from /opt/bootsync.sh and all the configuration files were located in /opt/mpd.

Relevant contents of /opt/mpd/SamK/mpd.conf

Code: [Select]

music_directory "/mnt/sdb1"
playlist_directory "/opt/mpd/SamK/playlists"
db_file "/opt/mpd/database"
pid_file "/opt/mpd/SamK/pid"
bind_to_address "any"
port "6600"


Failed to load database: Unexpected end of file
database: db file "/home/tc/.mpd/database" is not a regular file

This looks suspicious.  Is the problem in some way related to the way in which the database file was created and whether it was successfully created?  It might be helpful to check what type of file it is, can you do the following and post the output?

Code: [Select]

ls -l /home/tc/.mpd/database  

[TaoTePuh]

Failed to load database: Unexpected end of file
database: db file "/home/tc/.mpd/database" is not a regular file

This looks suspicious.  Is the problem in some way related to the way in which the database file was created and whether it was successfully created?  It might be helpful to check what type of file it is, can you do the following and post the output?

I have reproduced this message. It occurs when the file "database" is created manually (eg. "touch /home/tc/.mpd/database") before starting mpd. And so gavs did.

But otherwise mpd starts completely normal, begins indexing, overwrite the "wrong file" and works without restarting.

[gavs]

Thank you all for your perseverance. The discussion has helped me better understand how to use mpd (e.g. as sudo vs daemonized as tc). Your comments also helped me realize what I was doing wrong. I apologize for my carelessness. I had read the note about creating necessary directories and after reading 'playlist directory' in mpdconf.example, I just assumed the log, database, pid and state lines were also for directories (though it clearly writes 'log file', 'database file', etc. My mistake was to not onlyexecute mkdir -p ~/.mpd/playlists, but to also execute mkdir -p ~/.mpd/log, etc. Things work as expected when I do not create these directories.

Regarding the issue of ram, thank you to SamK for the suggestion about /opt/bootsync.sh. I am not familiar with bootsync.sh (I have used bootlocal.sh), but I will look into this and see if I can make it work on the 256mb ram computer.

Thank you all for your assistance and advice to get mpd working on the 512mb ram computer.

[gutmensch]

FWIW I tested mpd tomorrow morning with 128 MB of RAM, after loading and executing mpd there were still about 60 MB free!
You're welcome, gavs
Best regards,
Robert

[gavs]

Both Robert and SamK reported success starting mpd with low RAM. I tried again on the 256mb computer and was unsuccessful. So, I considered trying to reproduce the behaviour of libvpx on the 512mb computer.

First I booted TC3.1 from iso with option noswap. Then I executed sudo swapoff /dev/ramzswap0 to eliminate confusion with RAM swapping. I then downloaded and loaded extensions until I brought the free memory on the 512mb computer to less than what was available on the 256mb computer. After executing sudo cache-clear the results of free indicated 0 for all swap entries and identical entries for mem and total with total=514212, used=323632, free=190580, shared=0 and buffers=12. When I tried to start mpd I obtained the libvpx memory error message.

This surprised me as I had seen some web postings indicating that the memory useage had been fixed in version libvpx-0.9.1-2.fc12 (though this was for redhat??). I think the version in TC is more recent?

In conclusion, I was able to reproduce the libvpx memory error on the 512mb computer by 'using up' sufficient memory. I wonder if Robert and SamK could check if they were using swapfiles and ramswap0 (I think the TC3.1 default is to set ramswap0 to 25% of available RAM)

Hope this experiment sheds some insight.

[gutmensch]

I checked again, strace still reports libvpx is trying to map over 512 MB of memory, so with "real" 128 MB and no swap (sorry for that) it's not working. Right now I'm trying to build "stable" 0.9.2 (without git rev) and see if it changes anything 

[gutmensch]

according to the git tree it seems that --enable-psnr is causing this memory adressing issue, atm trying to build without it ;-)

[edit]
this seems to fix the issue, new version is submitted
[/edit]

[SamK]

...I wonder if Robert and SamK could check if they were using swapfiles....

I went back and inspected the test machine.  It has 128MB physical RAM + access to a 512MB swapfile.

Good catch.
 

[gavs]

I was successful loading alsa+mpd+gmpc to TC3.1 on the 128mb ram computer and playing music (using ntfs-3g to access music on external usb NTFS drive).

Thanks to everyone for their advice and assistance, to the TC team for making all this possible and particular thanks to Robert for revising libvpx.