Where to start

Symptom

Look at

The Configuration Tool reports a service as offline, or a page does not load at all

Web Apps Configuration Tool, below: the proxy, the web applications service, or the external proxy

Apps open, but no rundown data or timers arrive

Unable to reach the Viz Mosart Server, and Issues with Mosart Web Server Connecting to the Mosart Server

Content loads slowly, or only the first 5 to 6 clients work

Slow loading or a client limit in the live apps

Sign-in problems, an unauthorized-access screen, an unexpected logout, or a save that does not reach the server

Sign-in and permission issues

503 or 504 from a studio route

Not a fault in the Web Apps: no Viz Mosart server in that studio's pair is currently on air

Web Apps Configuration Tool

The Mosart Web Applications Configuration Tool provides you with error or warning messages that assist with common issues.
These messages may include a link to the Viz Mosart web server log files. These temporary log files are saved in C:\Users<username>\AppData\Local\Temp, with names starting with the date they were created, followed by an ID.

To troubleshoot issues, check the following locations for relevant logs:

  • Web server logs: By default, these are written to C:\MMLogs\WebServer. The location is configurable in the web server configuration file:
    C:\ProgramData\Mosart Medialab\Mosart Web Apps\serverSettings.json. Look for the NLogConfig setting.

  • Proxy server logs: By default, these are stored at C:\MMLogs\Mosart Web Proxy.

  • Windows Event Log: Use the Event Viewer to check for system or application-related errors.

  • Browser logs: To view logs in your browser, press Ctrl+Shift+I (this toggles the Developer Tools panel). Do this while using the Mosart Web Applications Configuration Tool or any browser with a Mosart web application open.

The Mosart Web Proxy Service is not running or is not functioning properly

Review the settings in

  • The Server Configuration page.
    Proxy server logs are located by default at C:\MMLogs\Mosart Web Proxy.

  • The browser logs.
    You can investigate your browser logs by typing CTRL+Shift+I (this is a toggle) in the Mosart Web Applications Configuration Tool or the browser where a Mosart web application is open.

Start the Mosart Proxy Service in console

If the Mosart Web Proxy service fails to start and there is little information in either the proxy logs or the browser, you can start Caddy in the console to troubleshoot the problem using the following command. If this is running as a Windows service, stop it first.

C:\Program Files (x86)\Mosart Medialab\Mosart Web Proxy>caddy2.exe run --config "C:\ProgramData\Mosart Medialab\Mosart Web Apps\Caddyfile"

Typical situations are where Caddy fails to start because the port (default 55142 for HTTP and 55143 for HTTPS) is already in use by other applications or the certificate and/or the key files configured are not valid:

The Mosart Web Applications Service is not running or is not functioning properly

A common offline error occurs when the Windows service fails to start because its port is already in use. The default port is 65142 for HTTP and 65143 for HTTPS, and it can only be changed in the configuration file at C:\ProgramData\Mosart Medialab\Mosart Web Apps\serverSettings.json.

Note: Any changes to the Viz Mosart web server configuration file (C:\ProgramData\Mosart Medialab\Mosart Web Apps\serverSettings.json) are overwritten when you press Save in the Mosart Web Applications Configuration Tool.

Review the settings in

  • The Server Configuration page.

  • Web server related logs written in the Windows Event Log accessible from the error message in the Mosart Web Applications Configuration Tool.

  • Web server logs written on disk (default location “C:/MMLogs/WebServer“ configurable in the web server configuration file, C:\ProgramData\Mosart Medialab\Mosart Web Apps\serverSettings.json - search for setting NLogConfig).

  • The browser logs. You can investigate the browser logs by typing CTRL+Shift+I (this is a toggle) in the Mosart Web Applications Configuration Tool or the browser where a Mosart web application was opened for more details.

You can also try restarting the service with the Restart button in the error message in the Configuration Tool.

Start the Mosart Web Applications Service in console

If the Mosart Web Applications service fails to start and there is little information in either the web server logs or the browser, you can start the service in the console to troubleshoot the problem. If this is running as a Windows service, stop it first.

Typical situations are where the web server fails to start because the port (default 65142 for HTTP and 65143 for HTTPS) is already in use by other applications or the certificate and/or the key files configured for HTTPS are not valid.

The External Proxy Service is unreachable or not functioning properly

Review the settings in

  • The Server Configuration page.

  • External proxy configurations.

  • The web server logs accessible from the error message in the Mosart Web Applications Configuration Tool.

  • The browser logs. You can investigate the browser logs by typing CTRL+Shift+I (this is a toggle) in the Mosart Web Applications Configuration Tool or the browser where a Mosart web application was opened.

Unable to reach the Viz Mosart Server (main or backup)

Some of the Mosart Web Applications might not function as expected. Ensure that the Mosart Remote Control Service (RCS) located on the Viz Mosart server is running. Review the settings in the Server Configuration page, web server log file accessible from the error message in the Mosart Web Applications Configuration Tool or the browser logs for more details. You can investigate the browser logs by typing CTRL+Shift+I (this is a toggle) in the Mosart Web Applications Configuration Tool or the browser where a Mosart web application was opened.

Check the status of the Viz Mosart server

In a browser, paste the URL to the Viz Mosart server status endpoint:

HTTP
http://<mosart-server-host>:55167/status for HTTP

HTTPS
https://<mosart-server-host>:55168/status for HTTPS

Using a Web proxy

http://<webproxy-url>:55142/mosart/main/status

Note: In the first two examples above, replace <mosart-server-host> with the hostname, IP address or the FQDN of your Viz Mosart server.

Info: /status needs no credential, even when the Mosart server runs with authentication enabled, so it stays usable as a health check. The versioned alias /api/v1/status does require one.

You should get a result similar with the following (serverDescription is not available in older Mosart versions):

If no response is received:

  • Ensure that the Viz Mosart server version is compatible with the Viz Mosart Web Applications. Refer to the Release Notes for System Requirements.
    or

  • Start Mosart Remote Control Service (RCS) as console to investigate further the issue. If the service is running as Windows service, stop it first.
    Typical situations are where RCS fails to start because the port (default 55167 for HTTP and 55168 for HTTPS) is already in use by other applications or the certificate and/or the key files configured for HTTPS are not valid:

Viz Mosart Server version might be incompatible with this version of Viz Mosart Web Applications

  • Please review the corresponding version Release Notes for product interoperability.

If HTTPS is used, this must be enabled on both Viz Mosart Server and Viz Mosart Web Applications

You may get this warning messages because no updates could be retrieved from Viz Mosart server.

  • Ensure that the Viz Mosart server version is compatible with the Viz Mosart Web Applications. Refer to the latest Release Notes for System Requirements.

  • Ensure that HTTPS is used and enabled on both Viz Mosart server and the Viz Mosart Web Applications. Check the settings in the Server Configuration page, Viz Mosart web server log file or the browser logs (CTRL+Shift+I in the Configuration Tool) for more details.

  • Check the status to the Viz Mosart server as described above.

If the server answers on its status endpoint but requests through the web apps fail with 500 and authentication is enabled, the cause is usually on the Mosart server itself: it cannot reach the identity provider. See the Viz Mosart Administrator Guide, chapter Security in Viz Mosart Ecosystem.

Sign-in and permission issues

These apply when authentication is enabled. The web apps read the user's roles from the token your identity provider issues; roles are never assigned in Viz Mosart. For the full setup and the identity provider requirements, see the Viz Mosart Administrator Guide, chapter Security in Viz Mosart Ecosystem, and the Authentication page.

Symptom

Cause

A signed-in user gets an unauthorized-access screen

That user holds no role for the app. Assign one in the identity provider. Note that a user with no role does not get a read-only view.

Everybody is locked out right after enabling authentication

No roles assigned yet, or the role names do not match. The Named Overlays Editor roles are mosart-admin and mosart-viewer; earlier documentation used namedoverlays-admin and namedoverlays-viewer, which no current version reads.

An app looks correct, with all its controls, but every save fails

The roles reached the ID token only. They must be present in both the ID token and the access token: the Web Apps server reads the ID token to decide what the app shows, the Mosart server reads the access token to accept or refuse the call.

An unattended screen, such as a wall display, shows a login page some hours after it was started

Either the offline_access scope is missing in the Scopes field, so the token the app uses to reach the Viz Mosart server cannot be refreshed, or that app has been switched on in Allow session timeout in Server Configuration, so it now expires when nobody is at it. For an unattended screen, set it back to Stays signed in while open.

Session timeout! reading You have been logged out due to inactivity.

Expected for an app that is switched on in Allow session timeout, by default Showmaker, the Template Editor and the Named Overlays Editor, when nobody has been active for the length of Session timeout, 30 minutes by default. Raise the window, or set that app to Stays signed in while open.

Session timeout! reading The connection to the server was lost for too long, so you have been logged out.

An app set to Stays signed in while open could not reach the Mosart Web Apps server for longer than Session timeout. This is a connection fault rather than a timeout setting: check the proxy and the web applications service, above.

A wall panel shows Session timeout! reading Your session has ended. Log in to continue.

The page was loaded onto a session that had already ended: the machine had been switched off or rebooted, or the page was reloaded. Nobody was signed in on that page for anything to expire.

You will be logged out soon appears while somebody is working

From 3.3 the window follows the user's own activity, so this should not happen at a keyboard. Check whether the user works mainly inside an embedded panel from another product, such as Viz Pilot Edge: the host page cannot see that panel's events, so focus alone stands in for activity for five minutes at a time.

A laptop reopened after a long sleep goes straight to Session timeout! with no warning first

Expected. The countdown comes from the server, not the browser clock, so a machine that was asleep through the warning window finds the session already gone.

The NRCS Plugin stays blank inside ENPS, with no certificate warning

Either the Content Security Policy on the identity provider does not list the ENPS host under frame-ancestors, or the certificate is not trusted on that machine. An embedded plugin often shows no warning at all, just a blank page.

Mosart Server settings under Help & Resources is dimmed, or asks for sign-in when opened

The Remote Control Service on that Mosart server is not reachable, or the settings editor is not enabled on it, or OIDC authentication is enabled and the editor has no browser sign-in. The row's own tooltip says which of the first two it is. See Configuration Tool.

An integration that used to work now returns 401

Expected if it authenticates with the Mosart REST API key: enabling OIDC on the Mosart server switches the key off.

A save did not reach the server

Showmaker talks to the server over a real-time connection. Before 3.3 that traffic did not renew an idle session, so once the session had gone the saves were refused with nothing on screen to say so, and a journalist could lose a script on reload. From 3.3 the failure is visible and the work is kept.

  • While the connection is down, Showmaker shows a banner at the top of the rundown: Disconnected from the server. Changes are not being saved. It appears only once a connection has succeeded, so it does not flash during start-up.

  • A save the server refuses raises an error toast naming what was lost, Could not save the script, Could not save the story, Could not save the item and so on, followed by the server's own reason.

  • Showmaker keeps retrying the connection, and asks the server about the session as it does. A session that has really ended therefore produces the Session timeout! dialog rather than an app that goes on looking signed in.

  • Unsaved script text is committed automatically in the last seconds before the session ends, so in the ordinary case there is nothing to recover.

  • If no save could run at all, because the machine was asleep or offline for the whole countdown, the text is kept in that browser tab and put back when you sign in again. If the same line was also changed by somebody else while you were signed out, a warning toast says so: Recovered your unsaved text. This line was also changed while you were signed out, so check it before saving.

Info: If a user reports lost work on a version before 3.3, this is the mechanism to look for. It was reported as support case 00227212.

Slow loading or a client limit in the live apps

If you experience the following issues with the live apps (Rundown Viewer, Smart Panel, Prompter):

  • The content loads slowly or only partially.

  • You cannot open more than 5-6 web sessions, meaning that opening the web application in multiple browser tabs or instances fails after 5-6 clients.

These problems may indicate that HTTPS is not properly configured across all relevant components.

In the screenshot below, the 6th Rundown Viewer client displays an error connecting to the Mosart server, while the other clients are functioning correctly:

Troubleshooting Steps:

  1. Inspect Browser Logs:

    • Open the browser's Developer Tools and go to the Network tab.

    • Inspect some of the URLs. For example, you might see a request URL to the Mosart Server like http://proxy-server:55142/mosart/mosarthub/negotiate?name=MosartWebUI&negotiateVersion=1.

    • A "307 Temporary Redirect" status code indicates that the resource has been temporarily moved to a different URL. This suggests that the proxy server (Caddy) has redirected the client to use HTTPS instead of the original HTTP request.

  2. Understand the issue:

    • In this example, the client (the Rundown Viewer in the web browser) initially made a request over HTTP to the Mosart server, but the proxy server redirected it to HTTPS.

    • This indicates that HTTPS is configured for the Mosart server but not for the Mosart web server and the proxy server.

    • By default, the Mosart Web Proxy is configured to enforce HTTPS by redirecting HTTP requests to HTTPS before they reach the Mosart server, if the Mosart server is set up with HTTPS.

  3. Fix the problem:

    • To resolve this issue, enable HTTPS for the Mosart web server and the proxy server (internal or external) using the Mosart Web Apps Configuration Tool.

Issues with Mosart Web Server Connecting to the Mosart Server

Mosart Remote Control Service (RCS)

Issues with Mosart web server connecting to the Mosart Remote Control Service (RCS), may be due to the RCS not automatically detecting the fully qualified domain name (FQDN) of the machine where it is installed.

For enhanced security and connection stability between the Mosart web server and the Mosart Remote Control Service, the setting SignalR allowed origins lets you specify an exclusive list of origins that may access the SignalR service used for communication with the RCS.

To configure it, open the Mosart settings on the Viz Mosart server, from Manus Administrator (type settings in the console), AV Automation or Media Administrator, and go to Remote Controller Service > Security:

  1. Set SignalR allowed origins to a semicolon-separated list of origins, including the fully qualified domain name of your Mosart server, for example https://app.example.com;https://admin.example.com. Left empty, the auto-detected host names are used.

  2. Restart the Mosart Remote Control Service. The setting is marked "Requires restart".

Note: For Mosart applications that rely on SignalR for real-time communication, such as the Rundown Viewer, Smart Panel and Prompter, defining the allowed origins is essential when a failure to recognize an FQDN prevents communication with the RCS.

Info: In earlier versions this value was set as SignalRAllowedOrigins by hand in the RCS configuration file RemoteDispatcherServiceConfig.xml. Use the setting above instead; a value edited directly in the installation folder can be replaced on upgrade.

Firewall Ports

  • Ensure the default ports have access.

Browser Logs

To investigate browser logs

In failure situations, you can use your web browser to access the Mosart Web Apps directly and further investigate the browser logs.

  1. From Home in the Configuration Tool, click a web app to open it in the default browser, or paste the web app link directly into your preferred browser:

    Application

    Address

    NRCS Plugin

    http(s)://<your-hostname>:<web-proxy-port>/plugin/?nrcs=ENPS&mosid=mosart

    Rundown Viewer

    http(s)://<your-hostname>:<web-proxy-port>/rundown

    Smart Panel

    http(s)://<your-hostname>:<web-proxy-port>/smartpanel

    Prompter

    http(s)://<your-hostname>:<web-proxy-port>/prompter

    Showmaker

    http(s)://<your-hostname>:<web-proxy-port>/showmaker/

    Named Overlays Editor

    http(s)://<your-hostname>:<web-proxy-port>/namedoverlayseditor

    Template Editor

    http(s)://<your-hostname>:<web-proxy-port>/templateeditor

    In a multi-studio installation, add ?studioId=<studio> to open a studio-scoped app against that studio.

  2. Type CTRL+Shift+I (this is a toggle) in the browser and inspect the Console tab or the Network tab.