Author: mhegi

• This week I first helped make our final presentation slides. I am the one who presented this week and wanted to give the best presentation possible, so I also spent a bunch of time studying the slides and practicing both by myself and in front of others.  For project work: I first helped Thomas set up and figure out how to use the new lights we ordered. Once we were confident in our ability to control them I set up the communication between the raspberry Pi and the lights. Since the lights need to operate on a while true, receiving communication from the first pi makes the light commands slower, so we split up the listening ports between the song recommendations and the lights so the lights will only get sent a message about once every three minutes. We will be running these programs concurrently on the second raspberry pi. I next wanted to fix the user keep alive. I am not really sure what I was thinking last week in my solution. Having a user that switches off the screen automatically deemed inactive is not very smart. I scrapped all of my old solutions and made this one: The server will set a time once it starts running and on every user connection they will receive this time. Also the backend will check every 30 minutes (could be changed) for all the users that are inactive. The way to tell the server that you are active is if you have had a screen interaction within the 30 minute server block. I do this by checking (on every user action) if the last action is earlier than the last inactive check by the server. If so then I send a message to the server saying that the user is inactive. Every 30 minutes the server sets everyone to inactive after removing the likes for all the new inactive users from the last 30 minutes. I then ran the concurrent user tests which I will talk about in the testing section
• Testing:
  Queue and reccomendation latency. 102 ms (20 trials) for Queue and 6.2 seconds (20 trials) for reccomendation
  Queue capactity of 100 songs: Still had memory left over and latency was fine
  User stress test: I made a javaScript test to make 200 users (without songs) and it had memory over and latency was fine
  Concurrent user stress test: This one was an issue. This is combining a lot of users, song queuing and concurrency. I ran out of memory fairly quickly which was a shock (a little over 20 users).  I am still trying to understand exactly what is the big deal with the memory, I think its between the dataStructures kept locally and passing the whole queue into the socket to send to every single user. I plan on now storing the data in a database and retesting.

  Sunday edit: Concurrent user stress test works.

• I did not anticipate this memory issue (for the Concurrent user stress test) and thought I would be done with this part of the project by now so I am behind schedule.  I plan to get back on schedule by finishing the remaining parts of the project as soon as possible.
• Next week I plan on fixing this memory issue as well as any other issue that pops up in our system, do all of the final reports, and then have a great demo and be done with the semester [and cmu 🙂 ].

• I started by making tests for heavy user load. I made it using chrome recordings which you can then download into a JavaScript file. I think I will run a few of those scripts at the same time to simulate concurrency. I plan on actually running the test next week. I also made much needed front end changes. I made it so that the app is responsive to different sized screens, does not have the weird zoom in that it used to have, made sure each song element is the same size, and also added a feature that scrolls through the text if it is overflowing (video included). I also ran into some issues with the user timeout, it was working fine on chrome and I knew safari would have some differences but I did not account for when users leave the page that the javaScript code would stop completely. Fortunately there are events that handle those cases so I added those to the code. The rest of my week was thinking about solutions to the problem of: if users refresh the page it will make them log back in as a new user. My biggest issue was differentiating a refresh and a page close on purpose, there is no 100% reliable way (to my knowledge/research) to do this since the browser treats them very similarly. I then just decided to have users stay logged in all the time. After having a few issues with reconnecting the sockets I finally got it to work, but then after some light testing, the app crashed, I think I was sending too many requests to the server but I will look into it more in the future. It could be a different thing implemented recently. Right now I think I have an acceptable solution. There is no reason for users to refresh the page since the WebSockets make it so the screen refreshes after every single change, but I realize people will do it anyways. When this happens on some browsers (like chrome) it will display a warning that they will have to re-login but on others (like safari) it will not display anything (I will also look into this a little more). If the user then clicks they want to refresh it will log them out and they will have to log back in and I will discard their old user votes as if the user was gone for an extended period of time. While thinking about this issue I also worked with Luke and Thomas to integrate our system together.

  Link to frontend:  https://share.icloud.com/photos/0182jqTvykRs-CBnIoQ5J29qQ
  I think the buttons are slow to load since I’m on a bad network right now. I did not notice this on other networks but I will double check when I get back to campus.

 

• I am on schedule. I achieved what I wanted to do the past two weeks.
• Next week I plan on helping integrate the lights to our system aswell as testing the app and thinking of that refresh problem more, maybe asking friends for their opinion.

 

• New tools or knowledge:

There have been a lot of new technologies and knowledge I have learned to do this project. Websockets, everything Raspberry Pi related, Maven projects, Github commands, Testing methods, and probably more I can’t think of right now.

The first thing I always looked for if I was doing something I never did before was documentation / examples of other people doing it (a video is a plus). After struggling with getting websockets to work from java to JavaScript and debugging to no success I found a video of someone using springboot to do it along with their repo. So I was able to learn enough about the process by following along the video and then just messing around with the code by myself to see what happens when I change certain things.  I also was lucky enough to find a video for getting a program to run on raspberry pi from the start but then when I tried it myself it did not work. So then I went to online forums like stack overflow and tried a lot of things until my solution worked. It is safe to say that one of the most important things I needed for these new tasks was patience and persistence. Github commands are very easy to lookup, aswell as Maven commands to run certain files and to solve errors. It is also very helpful to talk with teammates when struggling with a problem as they can provide a different view / a solution you were not thinking of. Our team is good at helping each other come to solutions to their problems.

• This week I started off by adding the functionality to send the updated queue after a song recommendation is sent from the recommender pi.  It first sends the updated queue with just a request added to the queue then when the queue is updated, the backend sends that to all clients. I added the keep-alive functionality for users to be active at least once for 15 minutes. If the timer runs out or if the user closes the page then all of their votes will not be counted towards the likes/dislikes of the songs. The user’s likes and dislikes are still saved so when they do make another action on the page then their votes will be restored to the songs still available. I was also playing around with what should log users out. The old version had it so if they refreshed then it would log them out. Now I have the app save the data so refreshing will not make a new user. I also made some UI fixes. There is now a designated dj color and all the songs recommended by the dj say it was queued by the dj. Also when song recommendations are pending there is no option to like or dislike. 
• Testing:  I have only run very basic tests with Luke and Thomas so far where we all queue a bunch of songs and verify if it is what we want. To test the app/Pis further I want to make a script to simulate 100-150 users making requests at random times and monitor the app for correctness and to see how it handles the load. Also for the latency we can either input timing code for the simulated users, or I can just run a user of my own while the app is under a heavy load and see if there is a noticeable difference. 
• I’m on schedule. I did all of the things I said I wanted to do last week. 
• Next week I plan to make tests like the ones described above and also help out in other areas of the project. The most important thing is having the backend know what song is playing when so that is probably where I’ll go first.

• This week was focused on system integration to get ready for the demo. So first I wanted to make sure that the Pis would be able to talk to each other for every song request made. It worked with one user as I was showing this past two weeks but for some reason it did not work when an extra user was making song requests. To fix this I tried to make the queue client class have async functions, and tried to research and take advantage of async Springboot decorators, and I tried to actually make a whole new queue client class for every message—none of those worked. I then tried a different approach which did not even have a separate queue client class. This works all the time for multiple users and is the simplest approach actually with the smallest amount of code. Second Luke, Thomas, and I integrated all of our parts over three different meeting sessions so that we could host the app on the first pi, get user requests with the second pi, and then actually do the computation on the second pi and send back the recommended song to the first pi and update the queue in the backend (I don’t think it actually pushes changes to the front end until there is another song queued/requested so that will be the next step). There were multiple bugs associated with this integration because of name changes and just finding bugs through testing which we worked as a team to fix. Finally, I implemented functionality for changing colors when users like and dislike as well as the app saving what songs each user likes and dislikes. The saving functionality just mentioned is important so that when users request new songs, it won’t reset their likes for other songs which it used to do. We do this by having a dictionary for each song object which maps user id to whether they liked, disliked, or felt neutral about a song. When the whole song queue gets sent to the javascript the dictionary is checked to see what color each song button should be. While I did not implement the actual user keep alive this week like I said I wanted to, I did implement parts that are important for it. I made a new class that maps users to each song they have a vote for and am adding to it appropriately. This is the object that will be referred to when removing user votes because of inactivity.
• I’d say my progress is on schedule still. I did not do what I said I wanted to do last week but still got a lot of needed work done so it was a good week. 
• Next week I want to have the app update the queue when a song recommendation is completed, not display like and dislike buttons for song recommendations, and then implement the user keep alive so that users who are not active will not be able to vote.

• This week Thomas and I worked together on both trying to figure out the lights and adding features to our app.  The parts I took the lead on were the vetoing functionality and adding options to queue a song that the DJ recommends. There are two options: 1. a song like the one inputted and 2. a song like the ones previously played in the session. The vetoing allows users to like and dislike songs. and when there are more likes than dislikes (for now, may be changed later) the song will be removed from the queue and concurrently displayed to all users through the WebSocket connections. I also integrated the lights with our Raspberry Pi and connected it to the rest of our system. We are having issues with controlling the lights currently. It worked at first but now every time we send a signal to the lights then it just turns them off. So as proof of concept here is a video of a user requesting a song on a computer from the app hosted on Pi1 which then invokes a message to be sent to pi2 and when pi2 receives the message it sends it to the lights which turns the lights off.  Video
  
• My progress is on schedule
• For next week I first want to try and figure out what is going on with the lights and how to fix it. I also want to try and implement the user keep alive so that users who are not active will not be able to vote.

• This week Thomas and I added functionality to our web socket app. I was involved in merging our queue class with the front end so that when the users request a song, it will be added to our queue and be the same for all users. The same queue is also now displayed on the front end for all users  (pictures are shown on Thomas’s status report). I also was able to set up our second pi and set up communication between the two Pis. Shown in the link below: a user is requesting the song from their computer then through the web socket our first Pi receives the request then it forwards the song to the next Pi. https://share.icloud.com/photos/01b9O72-v7Uqz9KqOgRQfZ09g  Communication between our Pis is important so this is good to see.
• My progress is on schedule
• Next week I hope to have a simple vetoing system so users can vote against a song and all the votes will be stored in the server. Also, we will try to integrate our backend on the app with the work Luke has been doing.