Timer @ dashboard / Room status

[hems]

In order to print the current status of the dashboard ( when the user is the room owner ), the backend is rendering the following info:

Before the user go live:

• receive: status.is_live = false

When the user is live, you will receive, and should keep counting the "Live time" on the frontend

• receive: status.live.started_at
• receive: status.is_live = true

For instance: thomas-live-tonight

In order to count the time, user moment js, something among this lines ( please not the utc() that is important due to user and server timezones ):

now     = moment.utc()
started = moment.utc( status.live.started_at )

duration = now.diff( started, 'seconds' )

When the already went live ( live finished ), you will receive

• receive: status.live.started_at
• receive: status.live.stopped_at
• receive: status.is_live = false

Same happens with recording, but variables will be: status.is_recording and status.recording.started_at and status.recording.stopped_at.

Another thing that is important notice, is that the Room can go live while you are looking at the page ( when you are not the owner )

In this case, a socket message "status" will come from pusher, you can subscribe to that channel with:

  channel = pusher.subscribe "#{user_id}.#{room_id}"
  channel.bind 'status', ( status ) -> console.log "new room status ->", status

Also worth noticing, if the user is inside of a Room and the Room goes live we will start playing the music automatically on Desktop computers.

If the user is already playing something we will probably show a pop up asking "Channel Blah Blah by User just when online, would you like to play the music in that Room?". If yes, then the player should start playing the room address: status.live.url and fade in

The same probably has to happen, in case the room goes offline we would need to fadeout the music and then stop playing status.live.url

I'm not sure what we will display if the user already recorded / went offline, but maybe @thomas1602 has some layouts for that already.

[stefanoortisi]

@hems I think we should provide an api call to get the live url of the room with the room id as a parameter. Doing this way we avoid to manage different cases like:

• the user enter on a live room (i could get the live url from a printed hidden input)
• the user is on a room while the owner press live (I should get the url from the pusher callback or something like this)

What do you think?

[stefanoortisi]

Actually I would need to get the current data:

data = 
      thumb
      title
      url
      author
      author_id
      author_link

So i can use the same call everywhere across the website (see the play buttons on profile page or on the explore room

[stefanoortisi]

I added the api call on loopcast.coffee with a temp response (b9adec07c6ed0c00dd73e21ee50764ad9b48f195)

Let me know!

[hems]

@stefanoortisi makes sense!

What is the difference between author_id and author_link ?

[stefanoortisi]

At the moment just the initial backslash, so we could even cut it :+1:

[hems]

@stefanoortisi I just created an endpoint to get room information and added some placeholder on the api.

One thing i think will be good idea to avoid is to be "transforming" the data objects that comes from the backend so in the tempaltes / frontend code the "path" to the values are different from the database, this will generate a lot of confusion //=

So for now when you get a room information, it returns "user" and "room" info separately like this:

I believe you would have update the code to call the callback passing this object ( which contain both objects ).

Also, when calling "callbacks", remember that the convention is to use the first argument of the callback for errors, and the second for data, if there is not errors the callback should be called with first parameter set to "null".

This way the code stays compatible with node.js / common.js callback styles, so if we decided to implement promises or mix different callbacks from different libraries in the code the code it will work flawlessly ( :

peace!

[hems]

also i'm starting to think we should print "start_time" for live, and for recording on the page, so we don't need to query the API for start counting, neither to show the status.

Also then we could print micro-data for the event: https://schema.org/Event so perhaps it would show on google "Live now" and stuff like that ( :

[thomas1602]

@hems can we close this issue now? Wasn't this fixed yesterday?

[hems]

now that i'm changing some code, this might break again, unfortunately.

i'm working on the new thing about record many sets and keeping records of how many streams the user did.

let's close it for now, and see how it goes once i finish refactoring the code