Logging

Logging

Everything Glass does is said in plain lines in the player's journal: the plugin's own, and the display's and the frames daemon's, which the plugin relays as they are written. How much is said is set on the Manager's System tab, in its Logging panel, and the same panel shows the last lines and downloads them for a report.

Levels

Level	What is written
Errors only	Errors: the display could not start, the daemon could not bind its port, an upgrade failed.
Warnings	Errors and warnings: the display died and will be started again, the ALSA chain does not carry Glass yet, a theme folder a rule names is missing. The default.
Info	Plus what happens: the display starting and leaving, each meter it moves to, a remote connecting, a theme change, an upgrade's steps, the ring the daemon reads.
Verbose	Plus the detail: every state the player pushes, each command from a display, each tap on a control and what it asked for, the files a remote syncs, remotes subscribing and leaving, the fonts loaded, the page's requests on a remote.
Trace	Plus once a second on a remote: the frames received, refused, and the channel's state.

Errors are always written. The display and the daemon follow the level from their next start; the plugin follows it at once.

Targets

At Verbose and Trace the panel shows the targets; ticking some narrows the fine lines to those, and none ticked means all.

Target	Lines about
audio path	The ALSA chain, the tap, Soloist and Spotify Connect.
channel	The channel between the player and its displays: connections, state pushes, commands.
display	The display: starts, meters, leaving, fonts, the renderer.
remotes	Serving remotes: the daemon, the beacon, subscribers; and on a remote, its own lines.
themes	Theme changes, edition tag rules, removals.
artwork	Album art and fanart.
manager and upgrades	The manager's work and upgrades.
settings	Backups, the configuration's version, settings taken over, the spectrum demand written for the theme on show, and the Face tab's feed lines.

A line whose beginning no rule names, the screen's, the screen owner's and the touch mapping's among them, counts as settings at Info.

The last lines, and a report

"Show the last 300 lines" lists the Glass lines from the journal, newest last, on the tab; "Download the last 1000 lines" saves them as a text file named after the player and the time, the thing to attach to a report. Both read the journal as it is, whatever the level was when the lines were written, so for a problem to show, set the level first, reproduce, then download.

Make a report, on the Status tab behind Find a problem, does those steps by itself. While the problem is reproduced the plugin logs at Verbose with every target, and the display starts again so that its own lines are full too. When it has happened, the player's system log goes out through Volumio's own submitter and the report carries its link; a log that could not be sent stays on the player and is offered as a download. The plugin puts the level back itself: when the report is made, on Cancel, after ten minutes, and at its next start when the backend went down in between. GET /api/diagnose/capture says where a capture stands, POST /api/diagnose/capture with a symptom starts one, POST /api/diagnose/capture/finish with the text makes the report, POST /api/diagnose/capture/cancel ends it, and GET /api/diagnose/log downloads a log that stayed on the player.

From the command line

journalctl -u volumio -f | grep -i glass
journalctl -u volumio --since "1 hour ago" | grep -i glass

Prefix	Who writes it
glass:	The plugin, and the display's lines relayed as they come.
glass: glass-launcher:	The launcher script, at every start: the backend it found, the renderer settings on a PC, software rendering where the render node cannot be used; and why, when the display cannot be started at all. At Info, with the display's lines.
glass: glass-serve:	The frames daemon.
glass: channel:, glass: remotes:	The channel: served, a display connected or left, a remote by its name, a command. Serving remotes: the ports, the daemon started again.
glass: screen:, glass: screen owner:	The screen by fact: free and the display staying up, the kiosk wanting it and the display stepping aside, the pointer and the rotation as resolved. Whose the screen is: glass-evo taking it, the kiosk getting it back, each step and why.
glass: graphics:	The graphics check (from 0.8.37), when it is first made and when its answer changes: whether drawing on the screen itself works, with the reason; what the kiosk's X server says of itself; Mesa's version, or its parts where they differ. A warning where drawing does not work.
glass: touch:	The touch mapping set, and a calibration: asked for with its targets, kept with its matrix and worst error, refused or failed with the reason.
glass: views:	What the Face tab and Anymote show, when it is changed.
glass: upgrade:, glass: performance:, glass: logging:	An upgrade's steps, a profile applied, the level changed.
glass: fonts:, glass: themes:, glass: car dash:, glass: interactive controls:	The fonts settings, the theme folders taken over from the old plugin, Car Dash's switches, the controls setting.
glass: face:	The Face tab's feed: the frames daemon's socket lost, or answering with an error; and a face's settings as they are changed. The daemon's own start line says no port when only the pages are served and names the socket after pages.
glass: spectrum demand	The bank the plugin asked the tap for when the theme on show changed, as the JSON it wrote; not written with the reason when it could not.

The display and the daemon read the level from GLASS_LOG and the targets from GLASS_LOG_TARGETS in their environment, which the plugin sets from the panel. Run by hand, they say what info says unless told otherwise:

GLASS_LOG=verbose GLASS_LOG_TARGETS=remotes glass --remote

What the display says

At start:

glass: frame.rate=30 size=1280x720 theme=/data/INTERNAL/glass/templates/1280x720_MyDeck meter=Studer A810 threads=4 as needed governor=on
glass: interactive controls on, as the theme says
glass: fonts loaded 5 of 5
glass: renderer opengl on x11
glass: channel /tmp/glass_channel

The first two are written at Info; the fonts, the renderer and the channel at Verbose.

While it runs, each meter it moves to (glass: meter=...), the governor's steps (glass: governor: 45 fps, the theme is heavy for this player, glass: governor: back to 60 fps; the Performance page has the governor) and, when it leaves, why: window closed, touched, run flag removed (the plugin told it to stop), snapshots done, or on a remote the player's configuration changed and settings changed.

Where each frame's time goes

With GLASS_PROFILE set in the display's environment, the display prints one line every sixty frames with the frames a second achieved, how many threads painted, what share of the screen was repainted in how many boxes, and the time spent polling, stepping, in the raster (its two parts, prep and paint) and showing, and a second line with the memory moving with the meter. The memory kept for the meter is printed once, at the start. To see it, run the display by hand as the player's user with the plugin's display stopped:

sudo -u volumio DISPLAY=:0 GLASS_PROFILE=1 /data/plugins/user_interface/glass/bin/arm/glass

Use the folder for your player's processor: arm or armv7 for a 32 bit system, armv8 for a 64 bit one, x64 for a PC. The Performance page has what the numbers mean.

Looking at a theme without the player

The same binary reviews themes without touching the player's configuration:

Command	What it does
glass --list	The installed themes and their meters.
glass --once --headless --print	One frame from the live measurements, with the levels printed.
glass --once --headless --output frame.png	That frame as a picture.
glass --headless --snapshot out --theme 1280x720_MyDeck --settle 2	Every meter of the theme as a picture, after two seconds each; --thumb 320 adds thumbnails. This is how the Manager draws its previews.
glass --once --headless --record step.json	The theme, the input and the scene of one frame as JSON, for a bug report about drawing.
glass --theme ... --meter ... --fps 30	The meter on screen with those values instead of the configuration's.
glass --dev --theme ... --meter ...	The same in a movable window at the theme's exact size, its title bar naming the theme and the meter on show.

The Tests page has the workflow the project uses with these.

The Status tab and its API

The Status tab is a picture of the player, the status sheet under its headings, and carries Find a problem and Make a report beside it; a script can read the same from the manager: GET /api/status answers with the version, the display's state, the theme on show and the meter selection, the meter the display shows, the theme folders, the fonts, the network share, Car Dash, the controls setting, the artwork settings, the player's state and whether it is measured, the rings, the channel's displays, the remotes, the Face tab's feed, the status sheet's rows, the catalog, the logging settings, the performance profile, whether the old plugin is enabled, and the Manager's language; GET /api/logs?lines=300 has the last lines, and with download=1 as a file. The Manager-API page lists every route.

A remote display

A remote prints the same lines to its own standard output, at the level set on its page, else the one its environment names: what it synced from the player, the frames port and the channel, why it started its session again, and at Trace the frames it receives each second. Its settings page's Status panel shows the frames a second it receives and whether the channel is up. A remote installed as a user service writes to the user's journal:

journalctl --user -u glass-remote -f