concerto / concerto-hardware Goto Github PK

Create a user interface for setting screen on/off time and report it back as part of the player information API.

Develop an infrastructure to manage the pushing of files to Concerto Players - X configs, certificates, software updates, etc.

The workflow for creating a new player is to click the Hardware: add link in screens/show. Right now, the user has to then enter the screen ID in the player#new form once they click the link.

Instead, we should pass a screen_id GET parameter as part of that link, and use that for the new player. It would probably make sense to hide the Screen ID field (since there's no reason to change it) and just show the screen name.

Allow screens to log in via devise with their secret password

Use the correct Concerto elements, eliminate unnecessary tables and links.

As in Concerto 1, it should be possible to determine a screen's IP address through the hardware UI.

Since times can't wrap, should probably validate that begin time is before end time.

Weekend time fields should be disabled or hidden if the "Disable on weekends" checkbox is checked.

If not, we need to fix the _screen_link.html.erb...

Or does the browser keep making requests?

Also, are you planning on including a feature so that you can either reboot or restart the browsers on each player?

Upon having @emalac deploy a hardware-controlled screen, the screen will at times begin flickering on and then off. I set what I thought to be reasonable on and off times that wouldn't even coincide with the UTC time in case this was a time zone interpretation issue.

@gbprz I know you had this issue in the past. Was there a resolution?

I'm assuming that there is different methods to do this for the different kinds of displays, so where do you specify the actual hardware type so (bandshell?) will know how to do it?

Or will it just use some x command to do it?

Provide the action for a new screen to register itself, and a seperate view/action for the administrator to verify the screen and get directed to its configuration options.

As reported in the forum when a screen is deleted that a player was using, errors appear in the players index view. Perhaps the deletion should be prevented and a message displayed stating why?

It seems the setter from attr_accessor via our time_accessor method is being overwritten. Everytime a call is made, for example to wkday_on_time=, it seems to get sucked up by ActiveModel, which attempts to interpret it is a DB field. wkday_on_time= is called in :after_find so the plugin is non-viable while this bug exists.

ActiveModel seems to be doing some funny things these days (aliasing method_missing for one). Some investigation is required to see if the on-the-fly attr_accessor approach is still valid.

ActiveModel::MissingAttributeError in ConcertoHardware::PlayersController#show
can't write unknown attribute `wkday_on_time'
vendor/bundle/ruby/2.1.0/gems/activerecord-4.1.6/lib/active_record/attribute_methods/write.rb:93:in `write_attribute_with_type_cast'
vendor/bundle/ruby/2.1.0/gems/activerecord-4.1.6/lib/active_record/attribute_methods/write.rb:58:in `write_attribute'
vendor/bundle/ruby/2.1.0/gems/activerecord-4.1.6/lib/active_record/attribute_methods/dirty.rb:68:in `write_attribute'
vendor/bundle/ruby/2.1.0/gems/activerecord-4.1.6/lib/active_record/attribute_methods.rb:395:in `[]='
vendor/bundle/ruby/2.1.0/gems/activerecord-4.1.6/lib/active_record/aggregations.rb:255:in `block (2 levels) in writer_method'
vendor/bundle/ruby/2.1.0/gems/activerecord-4.1.6/lib/active_record/aggregations.rb:255:in `each'
vendor/bundle/ruby/2.1.0/gems/activerecord-4.1.6/lib/active_record/aggregations.rb:255:in `block in writer_method'
/home/mike/dev/concerto-hardware/app/models/concerto_hardware/player.rb:107:in `block in retrieve_screen_on_off'
/home/mike/dev/concerto-hardware/app/models/concerto_hardware/player.rb:102:in `each'
/home/mike/dev/concerto-hardware/app/models/concerto_hardware/player.rb:102:in `retrieve_screen_on_off'

Odd as it may seem, I'm unable to change my screen weekend off time away from 8PM. I set the control for weekend on at 1PM and off at 3PM, but the off value remains 8PM. I'm able to change the weekday on and off times without incident.

For example, GETing /hardware/players/by_screen/1.json without appropriate permissions does a 302 redirect to /users/sign_in. Better would be to detect that this is a non-interactive format and render a 403 with empty data instead.

Some research is needed to decide whether this should be done on a piecemeal basis or just made part of the exception handler in Concerto.

Secrets are now handled by Concerto proper. I have to look in to whether the best way to change the schema is to add another migration or to just modify the existing one (leaving existing deployments in the lurch, but there are not many). Low priority.

Users should be able to disable the on/off screen control

There is currently no intuitive way to see all the players.

Because a player must be connected with a screen [and you can easily add one from there], and because the screen_id field is now a hidden field in the form, perhaps we should remove the "New Player" button from the All Players view?

Currently if you used this button you cant specify the screen and hence it never validates.

Each Player should have information about how to control its screen. For the purposes of this ticket we will only implement control method selection, but it should be implemented so more parameters may be added in the future.

Since this is likely to evolve, it might be best implemented as serialized JSON, as was done with the screen_on_off field. The field could be called screen_control_info.

The JSON should represent a hash. Right now there will only be one key, method. the associated value would be a string determining the control type, initially either dpms (default) or none.

The Player owner should be able to control this through the Edit Player view. This information should be available to the Player through the API.

Ensure necessary data (for example Screen information) is displayed and private data (hashed secret) is not. Make sure proper authorizations are in place for the views that the Player will talk to.

Can someone tell me what this is for? When it would be used? And when it is reset?

Provide UI and a database object that allow the user to optionally override the resolution (px x px) and rotation (normal, left, right, inverted) of the player's graphics card.

Storage will likely take the form of a JSON blob in the database since it need not be indexed or searchable, and may grow over time.

Future modifications may include overscan/underscan adjustment and reflection, though these are probably not priorities right now.

@mikldt or @augustf I'm wondering why this view stuff is in the engine.rb

        add_view_hook "ScreensController", :screen_details, :text => "<p><b>All systems:</b> go</p>"
        add_view_hook "ScreensController", :screen_details do
          "<p><b>Name via View Hook:</b> "[email protected]+"</p>"
        end

since the screen_link is already wired up here...

     add_view_hook "ScreensController", :screen_details, :partial => "concerto_hardware/screens/screen_link"

and can't it be moved into the screen_link partial? And shouldn't the partial be renamed to screen_details?

Why do you have the require and screen_api filter in the controller? When will other plugins need these?

require_dependency "concerto_hardware/application_controller"

module ConcertoHardware
class PlayersController < ApplicationController
  unloadable #marks this class for reloading in between requests
  #include routes.named_routes.helpers
  before_filter :screen_api

We should capture the player IP address from the API rather than having the user enter it into the form. The UI should then link to the status and configuration pages on the Bandshell server.

Ideally it would only write to the database when the recorded IP address is nil or different from the reported one.

A bonus might be to check whether it is routable from the server (could be a delayed job). This would be informative to the user and possibly useful down the line in a pseudo-push scenario. In this case we could store some serialized data (address, last updated, and routability) rather than just the address.