Adding volume control for the displays

We want the slider along with the display list after the MAC address field. We have been looking for that . :pensive:

Well, its a bit more difficult :confused:

1.7 uses a standardised set of template fields to generate the resources (pages, forms, tables, etc) so that we have a nice consistent use of fields, etc.

The file used to generate the table is template/default/html/table_render.php - you’d want to add something in on Line 84 which only effected the Display Grid.

To do that i’d suggest you add an “ID” to the DisplayGrid controller in lib/pages/display.class.php around Line 436. Something like

Theme::Set('gridIdentifier', 'DisplayGrid');

You can then reference that on Line 84 of the table_render.php file, so something like:

if (Theme::Get('gridIdentifier') == 'DisplayGrid') {
  /* Output your slider */
}

Of course, if we implemented this in the system we could have a way to output sliders in a generic fashion, but seeing as you still haven’t shared any code or plans, it is difficult to comment.

Thank you Dan. We will definitely share our plans and code. But, still we didn’t implement the volume control. So, right now we will share our plan. How to share the plan ?

This feature topic is a great place to do that :smiley:

Ok Dan, here is our plan :smile:

Our plan is to add a new feature in xibo 1.7 for controlling volume of the registered displays.
As per the idea, a new field called volume to be added in the displays grid next to the mac address column.

So, first we tried adding a new method in xmdssoap4.php GetVolume() for sending the volume to the client. But, if we are going ahead with this, we will need to communicate for every millisecond to achieve real time control of the volume.So, as of now we planned to write a separate soap service for controlling the volume with more accuracy by providing a collection interval of seconds.
We are not sure about the possibility of this method.

We will definitely share our code after completing this. Thank you.

I don’t think the project would implement that in the same way (because of the high frequency update), but we’d still be interested in seeing your code as we can use it as a basis for our implementation.

If you do want to write a full spec, the blueprint template is here: Blueprint Template

Hi Dan,
What do you mean by high frequency update?

This is very high frequency - this does not fit with the projects goals in general. Having that sort of function active in the player/CMS would cause trouble for a lot of users (image 100 displays all connecting once a millisecond).

It also doesn’t really fit with the idea of digital signage (which is the goal of Xibo). Controlling the volume, yes - 100% agree.

  • Adjusting the volume in the CMS and having that applied to the player next time it connects - yes, great.
  • Real time control - doesn’t fit.

I’ve already described how we would implement the volume control

We would probably have it on display form and as a multi-select option.

Hi Dan,
Is it like having a volume control like we see in media players?

Sorry, I am not sure how to explain this better :blush:

I understand exactly what you want… a volume control - like the one you get in a media player - in Xibo CMS. I understand that when you adjust the volume in the CMS you want the volume to immediately adjust in the player.

The problem is it is not practical to do that with polling technology - imagine we implemented a 1ms polling interval in Xibo… within hours Xibo would be kicked off 99% of shared hosting sites for misuse of bandwidth / CPU.

Therefore I think you can only implement something specific for your use-case and we can then pick over the code for anything reusable by the project as a whole.

Does that make sense?

Yes Dan. Thanks for your patience. We will try doing in some other method :frowning: If you have any method for implementing this, kindly give your suggestion.

I think the only sensible way to implement that sort of “instant” update is to use PUSH technology. Honestly I am not sure how you would implement that in the CMS/Player.

Thank you very much Dan

You’d probably need to look at writing something to push messages via ZeroMQ:
http://zeromq.org/

The CMS would publish messages and the Players would subscribe to those messages to be notified when you moved the volume slider. The exact mechanics of how that works or how you’d implement it are well outside the support we can offer I’m afraid though.

Thank you Alex. I have one doubt regarding content going to blacklist. On what basis the content is going to blacklist and what happens to the content in blacklist? Sorry if I’m asking some stupid question. :frowning:

The Player will blacklist a media item if it fails to play properly - eg a video that’s not of a supported type.

When the Player next connects to the CMS it resets that flag and will try again if the file was changed etc.

Thank you Alex . Now I understood .

One more doubt regarding this. Is it possible to write a separate soap service for this, other than editing the existing xibo and giving a less polling interval? It would be a better solution?

It’s Open Source. Ultimately you can do whatever you like to your CMS.

A webservice is NOT the way to accomplish live event handling as you describe. You need something that can push commands direct to the Player. I’ve suggested some technologies. I’m afraid I can’t offer you more help than that.

Thank you alex :slight_smile: we will try with the way you suggest