karlwithak / nowradio Goto Github PK

:radio: Listen to music now. An internet radio player.

License: MIT License

Python 26.09% JavaScript 53.38% CSS 5.07% HTML 15.21% Shell 0.25%

nowradio's Introduction

#NowRadio

NowRadio is an internet radio music player. It allows users to easily navigate between different stations and different genres so they can find something they like.

##SETUP

Tested on Ubuntu 14.04 x64

sudo apt-get update

Install necessary packages

sudo apt-get install -y \
    postgresql-9.3 postgresql-server-dev-9.3 \
    git \
    python-psycopg2 python-dev python-pip \
    build-essential libxml2-dev libxslt-dev

Go to the directory where you want NowRadio to be installed

git clone https://github.com/karlwithak/nowradio.git

cd nowradio

Optional: Set up virtualenv.

pip install virtualenv
virtualenv venv
source venv/bin/activate

Now, Python packages will be installed in a virtual environment and not conflict with other packages on your system. However, you will have to run source venv/bin/activate whenever you run the app.

Install necessary python packages.

pip install -r python_requirements.txt

sudo su postgres

Create new database user

createuser -dP nowradio_user

Enter password: nowradio_pass or whatever you have in serverInfo.py

Create database;

createdb --owner=nowradio_user nowradio_db

Fill up database;

psql nowradio_db < db/station_info_dump.sql

Exit postgres user;

exit

Note that serverInfo.py is never checked in and may contain secret info. If you want to use a different password for the database user, it must also be changed here.

cp nowradio/serverInfo.template.py nowradio/serverInfo.py

Start NowRadio!

./start-dev

You should now be able to view the running app at localhost:5000 or if installed on a server will be running at [server ip]:5000

##CONTRIBUTING

Contributions are always welcome.

Please submit changes for review by [forking and sending a pull request from your topic branch] (https://help.github.com/articles/using-pull-requests). Feel free to submit pull requests for any existing issue that has not already been assigned to someone else. If you want to add a major new feature or improvement that does not have an existing issue please create a new issue explaining it before creating a PR or spending much time working on it. By creating an issue, it gives us a way to discuss the potential change.

nowradio's People

Contributors

Stargazers

Watchers

nowradio's Issues

Enable compression in Nginx

Should be easy to do in Nginx

Change/Improve genre logic

The current genre logic is pretty basic and slow to compute.
We should have a column in the db that has the genre, which will make all related code much simpler.

This issue basically blocks #7 and #6

Use cdn's more and have all fallback for all cdn hosted stuff

See title

Keyboard controls for player

The user should be able to control the player using the keyboard.
For example:

Space to stop/start
Arrow keys to go back forward?
M to mute?

Stop polling for station name while player is paused.

We can probably just check in the polling logic if the player is currently playing and if it is not, skip the name request. We may also want to force a poll right after unpause, but this may be happening already.

Overall design improvements

There is clearly a lot of design that needs to be done. For example:

Adding a favicon
Player button design
Other icon design
Overall design of the app
Font style and sizing
Better visual response on button clicks

Buttons getting 'selected' after clicking

After clicking any of the player control buttons, they become 'selected' at least in Firefox 36. This means that the button background is a different color and there is a grey border on the inside of the button. But more importantly, this causes a space bar press to re-activate this selected button rather than perform the default space bar action.

Related to #19 I guess.

Add Favicon

I was thinking we could have a dynamic favicon of the circled play button that is coloured on a black background.
With a default of grey and black.
Good tutorial here: https://remysharp.com/2010/08/24/dynamic-favicons

Allow users to flag stations

Sometimes users are listening to a station that either:

is not streaming for them
is in the wrong genre
has an advertisement as soon as you start listening
has some other sort of problem that they want to report

In such a situation, they should have an easy way to tell us this.

I am imagining another button in the top right that lets them optionally enter a small amount of text describing the problem (or maybe pre-defined options). On submission, this report would be saved somehow for further review. This initial implementation could rely on human-checking of all of these flagged stations to determine if there is an actual concern and if the station should be blacklisted (#46).

jQuery animations

Certain things may look better with animations.
For example:

the info/settings pannel expanding and contracting
the backgroudn color transitioning (once implemented see #2)

Add station blacklist

There should be some sort of mechanic to blacklist stations. A blacklisted station would still exist in the database but would not ever be offered to users. An easy way to do this would be to add a boolean column to the station_info table.

html5 audio optimization

I feel like we aren't using the built in audio player optimally, we should do more research and implement improvements such as:

smarter buffering
quicker load times for next station (pre-buffering? multiple audio players?)
status checking
un-pausing actually brings you live?
animation after switching station and before station starts to play

Come up with name for website and get domain name

This obviously has to happen at one point, hopefully after we come up with a good name.

Also, once we come up with a name, we should make a favicon.

Info page

Make an info page!

Add theme-color meta tag

by adding this meta tag, we can control the color of the status bar on android 5.* devices, might be worth checking out.

Better handling of rapid station switches

Right now, the user can switch stations as fast as they can click, and the app does not handle it well enough. So we should either better deal with this situation, or disallow the user to go to the next station while the current one is still loading. Or perhaps some hybrid solution where we make them wait a certain amount of time before skipping regardless of the load status.

Note, this applies to both skip buttons and the back button.

Javascript refactoring and commenting

Currently most of the JavaScript is in one big file. It should be split into various files.

There should also be a lot more comments. Preferably one for every closure and non-obvious function.

Eliminate duplicate stations

There are duplicate stations in the database that have differing urls but are playing the same music. These should be removed and we should ensure that new duplicates can't be added.

This can be done by ensuring that station names and ip addresses are unique?

Relates to #8

Handle users that has javascript disabled gracefully

If a use does not have JavaScript enabled, we should let them know they must have it enabled to use the site.

Listen for changes in local storage

Right now if our app is open in multiple tabs or windows on the same computer, favorites on one won't appear on the other and other problems are likely to arise. I think there is a way to listen for changes in localstorage which may help alleviate this potential problem.

Add IceCast stations.

Currently we only deal with ShoutCast stations, but there are other streaming server platforms such as Icecast.

Example station

I don't know how many of these station there are compared to ShoutCast but it should be looked into.

This may be a major change and not worth our time depending on how much of our existing code will work with these servers. For example, they do not have a '/7.html' page.

Ensuring that current station is actually playing music when it should be

Sometimes when a user goes to a new station, there is some sort of problem that results in them not listening to music, this should not happen and/or be gracefully fixed. It can happen for various reasons such as:

They are having internet problems
The station is not up
The station is up but is just not broadcasting
The station is broadcasting but they are broadcasting silence (not sure about this one)
Our app messed up in some way
Solar flare

To help fix this problem, we should do regular checks to see if everything is working. We will probably want to do this check very soon after the switch to each station, but we may also want to do this periodically as well.

The solution should probably involve trying to reload the station, and then to going to the next station in the genre. In the worst case we can force a reload of our app.

At the very least our app should show some awareness (such as through the background color) that a problem has occurred, so the user can act on this info, as opposed to them just waiting until their patience runs out.

Volume Control

I'm not sure if we actually need/want this. But it would be pretty easy to implement. If this ever does happen, remember to implement appropriate keyboard shortcuts.

Same station after skip

Often when cycling through stations you will come to a new station that is playing the exact same song as the last station. There a few ways this can happen:

The station is in multiple genres
The different url/ip point to the same station
Some other bug

Some indication when a faved station is currently playing.

When you are listening to a station that is part of your faves, there should be some indication of that.

Furthermore, if a user tries to play a faved station that is currently playing, this should be handled gracefully.

Resume playing after loss and regain of internet connection

Sometimes while listening on my phone I will go somewhere that causes me to lose internet connection. When I regain internet connection it would be nice if the music started playing again.

At the very least, the app should realize that internet connection has been lost, and the player should be put into the paused state.

Set up proper development process

Right now all development is happening on the production servers. Once we go live, or once there are multiple people make changes this will be a problem.

We should set up new local or remote machines that will be clones of the production server to develop on.

This may involve creating scripts to automatically set up a development environment, so if we ever open source others can easily get a clone of the production server.

Javascript minification and objectification

The code should be re-factored into proper objects and potentially split into separate files.

The js and css should also be minified server-side when running the app in production mode

Keyboard shortcuts for faved stations

It would be nice to be able to go to a faved station via a keyboard short-cut. An obvious one would be the number keys corresponding to the fave in that position of the fave list.

Automatically add new stations to DB

We currently do not have a system to automatically add new stations to the database, the existing file linkGenerator.py could be used/modified/improved to do this.

We are currently using yandex and splitting the results by average listen time seconds, I think that we should instead split by genre. Relates to #20.

Prepare for open sourcing

I think I want to open up with repo. This involves a few changes:

ensuring all passwords are changed
cleaning up file structure
create a system that allows others to easily spin up an instance of the app (database, apps, config files)
Create a readme
Add links to the repo from the app and vice versa
Decide on a license
Create contributing info.

Improve dark-mode logic

Currently, if a user presses the dark mode button twice in quick succession they get into a state where the nav bar and the body is both coloured, this should not be possible.

Also, we should store the brightness state in local storage so a user does not have to go into dark mode manually every time they visit the site.

After pausing, station name does not match stream.

Because the station-name pulling is real time, if the user pauses the stream for a while, the song name will be ahead of the player.

One simple fix is that pausing and un-pausing always brings you live rather than buffering the stream.

Stop station streaming while player is paused.

Right now the station source is reloaded on player restart. What would be better is if the audio streaming stopped on station pause and reloaded on re-start. In theory this should have no impact on UX.

Increase ShoutCast station count

We currently have around 7K ShoutCast stations, but I believe there are many more.
Note there are a few tools in this repo that must be used to 'vet' urls before submission into the db.

Nginx caching

We should implement some Nginx caching for static resources(?) and for calls to gunicorn, especially for the initial station load.

I am trying to wait until the last possible time to do this because it will likely make development a bit trickier, so I guess this is related to #11 .

Keep track of user faves in the db

We should add a new column to the station_info table that keeps track of how many faves that station has.
We can keep track of this by sending a 'fave added' or 'fave removed' message to the server every time a user adds or removes a fave.
We can hopefully use this data in the future to change the order of stations played, and potentially detect stations that no-one likes or are in the wrong catagory.
All in all, it will give us information about our user-base.

Landing page and start-up logic overhaul

There are improvements that could be made to the landing page and the initial start-up of the player such as:

Playback does not start on some mobile devices from landing page and from station refresh.
Music can be played from landing screen by pressing 'm' key
We should start playing at a random genre, or maybe their first fave
Maybe show the faves on this screen?
Maybe add the header and footer bar to this screen?

Remove bootstrap/glyphicon dependencies

Bootstrap.min.css and the related glyphicon library/font is by far the largest resource that our page needs to load (145KB vs 82KB) and we are only using a tiny part of it. We should write our own css and create/obtain our own images to replace both of these, thereby speeding up page load times.

Places where we use these resources:

all buttons
all images/graphics/icons
css for header and footer
other places I have forgotten about

Blacklist stations that play advertisements immediately

Some stations (including ones at the top of their genre) play advertisements immediately upon station load. I feel like this is an extreme deterrent to further usage of the app and should be prevented at all costs.

This is blocked by #46 and would be be a lot easier to do once #47 is finished.

Background colors implementation

Each genre (and maybe station) should have it's own colour that the background (or foreground?) changes to when it is currently playing. This will hopefully allow users to get a sense of the type of music they are listening to and might help them find similar music in the future. It is also a good way to add some colour to the site.

This could also be extended to give the user a colour palette and allow them to pick stations based on colour.

Note, I think if we want to give specific stations a colour we should base it on the stations url/ip as this is the only thing that is guaranteed not to change in the future.

Create content for settings panel

I have temporarily disabled (commented out) the settings panel as there is currently no features that it provides.
Some things that could be in there:

Dark mode
No colours mode
Obscure mode
Colour selection palette

Streamline station adding process/update relevant scripts

We now have a lot of scripts that can/must be used to add new stations to the db. But there is no document or better yet, a program that encapsulates this process.

Also many changes has been made to the database so these existing scripts may need to be updated.

Relates to #4

Analytics

It will soon be important to us to see how many users are on our site and how long they stay for, along with other info.
There are a few ways to do this:

google analytics
roll our own custom analytics
other third party analytics providers

Review genre logic and model

We (@karlwithak & @julius-sneezer) need to meet up and discuss if we are happy with, and how we can improve the genre logic and model. In particular:

The actual genres and their related keywords
If we want to keep the double layer system/double button system
What we should do about adding more colours or hand selecting a color for each genre
Is the sort order of the stations in each genre good (sorted by current listeners) or should there be randomness
Should we add randomness to the order that the genres are presented, or should we incorporate some sort of client-side storage of favourites (automatic or manual)
Matt: goofy, or the goofiest?
Is there any genres we should not include at all, so we can focus on a specific market. For example, foreign language stations or talk/news stations. Or maybe there is a better way to handles these.
Having a limit on the number of stations returned in a genre or not. Whether looping back to station 1 is better than playing station 101 or going to the next genre.
Maybe we should do same genre-specific yandex queries?

Replace all jquery animations with velocity.js animations

Seems like a no brainer: http://julian.com/research/velocity/

Limit the number of stations accessable in each genre

Right now, if a user cycles repeatedly through stations of the same genre they will 'run out' because we are just returning pages from the db that have a decreasing number of current listeners. For example lets say we have 124 jazz stations, if the user gets to the end of these they get silence and are actually unable to get any more jazz stations without refreshing the page.

I suggest we set a limit for each genre such as 100. So after cycling through the 100th station, they go back to station 1. Another reason this change will help is that I am confident that the user would rather hear the 1st station again then listen to the 101th station which likely does not have many current listeners. This means the overall quality will not degrade after using the site for extended periods of time.

Clean up and comment javascript

Now that we have modularized all of the javascript, we should take care to only expose the necessary functions and variables. Also, all functions should be commented with expected parameters to help mitigate future errors.

Loading station from url hash puts user in the correct genre

Right now if I load the app with a url hash I start playing the station but the app still has me in the genre as I would have been had I not had the url hash. This means the color is wrong (assuming #2 is done) but more importantly the small skip will take me to a station of a different genre.

To fix this, when loading the given station, make a request to the server to find out when genre the ip belongs to, and set the current genre to match.

Share button

The user should be able to share the current station (using the url hash) on social media. We can probably use some sort of plug in for this?

We might want to make a related twitter/facebook account to make this easier.