Resolving Issues with the Web Interface

Sometimes the web interface of Flussonic might be displayed in the browser incorrectly, or not displayed at all.
This article explains why this happens and what can be done.

Support in browsers

The web interface is designed for viewing in popular modern desktop browsers ( running on personal computers under Windows, OSX, and Linux OS).

The main browsers are Firefox and Chrome (Chromium). It may (and may not) run on new Internet Explorer 11, Safari, new Opera (versions 15 and higher, using the Chromium engine).
It won't run on older versions of IE (on IE version 8 does not run surely), old Opera (on the Presto engine up to Opera 12 inclusive), etc.

It will probably run on new Android devices in Chrome, and in mobile Safari for iOS.
It will definitely not work in Opera Mini and in the standard Android browser (that is not Chrome) and its modifications.

This set of browsers is determined by the support in the technologies and frameworks.
For example, here is Google's position in regard to their AngularJS framework: https://docs.angularjs.org/guide/ie

The same is true for the Adobe's policy about Flash on Android devices, inability to run Flash on iOS, presence or absence of HLS support in HTML5 video tags, and so on.

If you use an unsupported browser, the only recommendation is to use another one, for example, Firefox or Chromium.

Troubleshooting

If you have any problem viewing in the browser, there are standard actions that could help.

The first action is to completely clear the browser cache and restart it.
Sometimes the browser caches JavaScript, styles, even whole pages, and does not update cache when they are changed. Most likely this is due to bugs in the browser. The user of the web interface may see a list of streams that fail to load, settings from the previous Flussonic versions (which should have disappeared long since), settings that change absolutely different features, and so on. The only simple way to solve this problem is to clear the browser cache and restart it.

Sometimes a similar effect occurs after installing all kinds of plugins into the browser. Especially, "viral" plugins and extensions on Windows are often installed together with installation free programs. Open the control panel for your plugins, and disable/remove everything suspicious there. Especially those plugins that you don't remember installing yourself.

Check whether the web sockets are activated. If web sockets are inactive, the web interface will not work either.
For example, you can use this website for checking: http://websocketstest.com.
(We did not create this website, and we are not related to it; this website is in top of Google search results).

The fact that they do not work is the first sign of a malfunctioning proxy or of incorrect network settings.
For example, there are cases when Kerio WinRoute Firewall blocks web sockets by default, and one just had to update the version of WinRoute to a later one or better delete firewall.

One should be suspicious to install security systems like Agnitum Outpost Security or Kaspersky Internet Security on the client. Try to stop protection for a couple of minutes and open the web interface with disabled protection.

Another frequent problem is proxies. A malfunctioning proxy leads to problems similar to the problems with the web interface. For example, due to a malfunctioning proxy, a list of streams may fail to load, and a spinning loading indicator may be displayed instead. The easiest way to know about the presence of the proxy is to ask the system administrator in your organization. Or try opening the web interface from another location, e.g., from home, where there is no proxy for sure.

Note that the network in the organization may be configured in a very complicated way. For example, all mobile devices with Internet access via wifi use proxies, while ordinary computers connected to the local network do not. This may lead to strange effect when the web interface is accessible from a computer, but not from a mobile phone, or vice versa. Before you try solving such puzzles, you should contact your system administrator.

Contacting technical support

If you think that the problems with the web interface is caused by errors in Flussonic, you should contact technical support.

Error description

Be sure to exactly describe the error. Only screenshots are not enough. Mind that using only screenshots, a technical engineer may fail to understand your problem.

Correct error description should contain at least these three points:

1. What action caused the error. Describe in detail, what you opened, what buttons you clicked, what text was typed and where, etc.
2. What you wished to see as a result of all these actions. For example: "a Save button should appear".
3. What is actually displayed on the screen, and why you think it's bad. For example: "the Save button has not appeared, and I have nothing to save changes with".

Loading logs

Make sure to load the logs and send their IDs in the email.
This is usually done from the web interface: Support->Upload logs. However, if the web interface is inactive, loading from the command line on the server may help: service flussonic upload-logs.

Uploading screenshots and videos

If an error is detected in the web interface (e.g., broken layout or disappearing indicators), it is the best to send a screenshot.

If the error is only visible in motion (for example, incorrectly displayed animation), it is worth recording the video of the desktop. There are many programs to do that. For example, one of the best applications for Windows is Camtasia that has a demo version. In Linux, you can use recordmydestktop. In OSX, it is ScreenFlow. Just record the video from the screen with any tool and upload it to a hosting. (If you don't have a hosting, you can upload this video to your server, and provide for us access to it via SSH).

Access to the web interface

Whatever information you provide, we have to manually check it, and to find the reasons. This requires access to the Flussonic web interface.

1. If we are talking about the main control panel, i.e., http://flussonic:80/admin, we need its URL, login and password.
2. If we are talking about Flussonic Watcher, i.e. http://flussonic:80/vsaas, we need access to the Watcher: URL, email, password.
   And we will also need access to the main panel (see par. 1).

Configuring access to the web interface

In all cases, when the error are associated with the video, you should make sure the admin account is up and running, so that it is possible to watch videos over the Internet.

If the Flussonic web interface is available only from your local network, you need to connect it to the Internet, so we can open it in our browser. Also you will have to connect to the Internet all ports that are used for video delivery (default values are 80 for HTTP (HLS, MPEG-TS), 554 (RTSP) and 1935 (RTMP)).

Note that ports should only be connected with the same name. That is, if Flussonic opens port 80, the port of the router should also be 80, and port 5454 in Flussonic should match port 5454 on the router. In other words, the following connection is incorrect: 5454->80, but the correct one is: 5454->5454.

We do not work with various VPNs or remote access, or remote access applications like Team Viewer, all connections must be directly accessible via the Internet, it is required for normal operation of our diagnostic applications.

We do not advise our IPs (people often ask them to add to the "white list" on the router), since we have many IPs from which the testing is done.

If some kind of authorization (global or local auth directive in the config file) is used, it should be temporarily disabled during the test. (Except for the case when authentication is made using Flussonic Watcher, where there is no need to disable it). At the very least — change the script/backend of the authorization to some secret token that would always permit watching the video.

IP limitations with the use of api_allowed_from also should be temporarily disabled.

Developer's tools

Try to send us the information from the developer tools.
It is especially important if you are not able to provide to us the access to the web interface.

In Firefox, it is done from the main menu: Tools->Web development->Development Tools.
You have to refresh the page after opening the Network tab, and later when you open the Console tab.
Note that in the new versions of Firefox, the main menu is not displayed by default, and it is necessary to press the Alt key to display it.

In Chrome (Chromium), it is done from the main menu: Additional Tools->Developer's Tools.
You have to refresh the page after opening the Network tab, and later when you open the Console tab.
Note that in the new versions of Chrome, the main menu is displayed by default if the Menu key is pressed (it is in the right-top corner of the browser window and looks like three small horizontal lines).

The content of tabs Network and Console should be somehow sent to us, e.g., by means of a screenshot.
If in the Network tab you see any errors, like 404 or 503, you can click your mouse on them and view additional information that will be displayed next to them. It can also be sent to us as a screenshot. In Firefox, particularly interesting are tabs Headers and Reply.

It is clear that Developer's Tools tab contains a huge amount of information; also the browser has other sources of information, and transmitting all this information as screenshots and texts is rather difficult. If you have experience in web development, systems administration or something similar, send us any information that you suppose to be possible sources of error.