Using temp files and playlist files means there will have to be a shareable path between users. Two options:

1. Make the install directory be static, in a location such as /opt/share/ which all linux users have

2. Maintain a relative directory on a per user basis, referencing it whenever an internal file must be read/written

Specifically the creation/destruction of the 2d item array

The branch "boilerplateMPD" has a stub that sucessfully opens an MPD connection. The next step is to figure out how to send music files down to the server.

Program throws several screenfuls of errors when user selects "Select a song" as their first action. Does not occur when another screen is viewed first.

The location /usr/share/lemonade directory was chosen to have a constant location all distros would have. Because it is a root level directory, it must obtain permissions for the program to write a file to the location.

To do this:
sudo mkdir /usr/share/lemonade // can skip if it exists already
sudo chmod 777 /usr/share/lemonade

The system() function in C is supposedly synchronous, however the screen command to instantiate a new screen must spin off at least one independent child process, which makes the creation of a new screen not synchronous. This results in the command to play a song/playlist execute before the screen to play the song/playlist is even created.

This is only an issue if the song/playlist command is sent within less than a second of the screen being created, which shouldn't be an issue in actual use cases (user has to navigate to songs, press play, etc). It will be noticed maybe 1 in 10 times if the debug backend flags are used (such as -s, -l).

Without the use of multiprocessing this isn't a trivial issue unless we want to build and deploy our own version of the screen package with lemonade which is way out of scope for the project.