Skip to content
Statistics & analysis

The finding first, the evidence second

A page of numbers answers “how much”.

Jump there →
Screenshot: The finding first, the evidence second
Statistics & analysis

Who requests, who takes up space, who is happy

Per person: how many requests, how many finished, how much space is booked to them and how they rate what they got.

Jump there →
Screenshot: Who requests, who takes up space, who is happy
Statistics & analysis

Who is watching, and whether your server is sweating

Across every connected media server at once: who, what, on which device, how far in, and how hard your server is working for it.

Jump there →
Screenshot: Who is watching, and whether your server is sweating
Statistics & analysis

What is there, whose it is, and which disk it sits on

Holdings in items and bytes, split into the household collection and what is booked to individual accounts, plus the orphaned entries with no file left behind them.

Jump there →
Screenshot: What is there, whose it is, and which disk it sits on
Statistics & analysis

Where Radarr, the media server and Nexview disagree

Every setup has at least three sources claiming the same thing: Radarr and Sonarr manage the files, the media server plays them, Nexview bills them to somebody.

Jump there →
Screenshot: Where Radarr, the media server and Nexview disagree
Statistics & analysis

Six tabs, and each opens with what is wrong

Requests, people, watching, library, services, operations. Every tab opens with the findings for its area and backs them up with figures below. If you only want the numbers, scroll past; if you want to know whether something needs doing, it is in the first line.

The shape

The finding first, the evidence second

A page of numbers answers “how much”. It does not answer “do I have to do something”, for that you would have to know which number is unusual. So every tab puts the finding at the top and the figure it came from below it.

⚠️ Since 0.25 the page is for administrators only. Approvers could see it before; it now carries instance state, disk levels, backups and the source reconciliation, operating data nobody needs in order to decide on a request. As a side effect it fixes an old fault: the “Clean-up” tab was shown to approvers while the address behind it had always answered 403.

The overview across everything is the admin dashboard, this page is for looking things up and understanding them, not for acting fast.

Screenshot: the Requests tab with a finding about a waiting approval, below it five key figures and two charts
Six tabs, always the same rhythm. The finding with its button at the top, the key figures below, the charts below that.
Requests

How long your people wait for an approval

The figure that used to be missing: how long it typically takes for a request to be decided, and how long the oldest open one has been sitting there.

It is given as the middle value: half went faster, half slower. An average would be the wrong number here, one single request somebody left lying over a holiday would shift the everyday picture by weeks.

Alongside it the familiar figures: how many requests in total, how many finished downloading, how many rejected or cancelled, the spread of ratings, and the trend over the months, films and series apart.

People

Who requests, who takes up space, who is happy

Per person: how many requests, how many finished, how much space is booked to them and how they rate what they got.

The table answers two questions you would otherwise guess at: who keeps the place busy, and with whom a conversation about the quota is worth having before it gets tight.

Screenshot: the People tab with a table per person — requests, completed, storage used and rating
One row per person. No ranking, no judgement, the numbers sit side by side, the verdict stays with whoever runs the place.
Watching

Who is watching, and whether your server is sweating

Across every connected media server at once: who, what, on which device, how far in, and how hard your server is working for it. An account Nexview knows appears with its Nexview name; one that only exists on the media server appears with the name from there.

Transcoding has three states here, not two, and that was measured, not assumed: both Plex and Emby report a transcode while passing the video through untouched and only re-encoding the audio. That costs almost nothing. So only video transcoding is red, the one that actually eats CPU.

Without that distinction you see three red lines and buy a graphics card for a problem you do not have.

Screenshot: the Watching tab with three sessions running — one direct play, one audio transcode, one video transcode — each with account, device, progress and bandwidth
Three rows, three states. Green passed through, yellow audio only, red the video. Top right sits the number that counts: how many video transcodes are running.
Watching

And what happened before

Below the live sessions comes the history: how much was watched per month, how the library grew over the last eighteen months, and who watches how much.

Plus the curve that justifies or spares a purchase: how many streams ran at the same time, per day, the busiest quarter hour. Not the average: the question is what the hardware has to cope with at once, and that is decided at the worst moment of the evening, not by a mean over twenty-four hours.

The library grew by the date the file carries, not by the day Nexview first saw it. Otherwise every fresh installation would look as though everything appeared on a single day.

Library

What is there, whose it is, and which disk it sits on

Holdings in items and bytes, split into the household collection and what is booked to individual accounts, plus the orphaned entries with no file left behind them.

Per mount point the fill level with the real path beside it. If you run three instances on three disks, you see three numbers and not one average.

Screenshot: the Library tab with holdings, household collection, assigned storage and orphaned items, below it three disks with their paths
Four key figures, three disks. The path is right there, on somebody else's setup the mount points are named differently to yours.
Reconciliation

Where Radarr, the media server and Nexview disagree

Every setup has at least three sources claiming the same thing: Radarr and Sonarr manage the files, the media server plays them, Nexview bills them to somebody. Where the three disagree, errors appear that nobody looks for, because nothing is red anywhere.

Only in Radarr/Sonarr, the file is there, the media server does not know it. To everybody else the title looks absent, and sooner or later somebody requests it a second time. Usually the server has not scanned, or the path mapping is wrong.

Only in the media server, it plays, but it is never upgraded and never renamed. No identifier, invisible to Nexview. Listed more than once, often two cuts or a separate 4K library, worth a look. Year conflict, either a wrong match or merely a festival versus a cinema release; the text says both and leaves the verdict to you.

Which titles they are, the comparison table shows. Running several media servers, Compare servers lists every title in a row and every server in a column: present, missing, different ID, or the file is there but the server identified it as another movie, and then which one. Opened, each row shows the IDs and file paths on each server. Every view comes with short steps to narrow the cause down, and View on a finding leads straight there.

Rematch fixes a wrongly identified title on Plex, Jellyfin or Emby itself, by its TMDB or TVDB ID instead of its name. The choice is only the IDs already in the row, with the one from the file name suggested. Afterwards Nexview asks the server whether it kept the fix. It is the only place where Nexview writes to a media server, and only on click.

⚠️ The reconciliation runs on the hourly round, not when the page is opened. With a few thousand titles across several providers that is not something a click may trigger. And with no media server connected the section disappears entirely, rather than showing an empty table.

Screenshot: the “Do the sources agree?” section with five figures — ten only in Radarr, three only in the media server, none without an identifier, none listed twice, no year conflicts
Five questions, five numbers. Whatever is not zero gets highlighted, and from ten titles on it becomes a finding that also shows on the dashboard.
Clean-up

What is lying around unused

Titles nobody watches any more that have been here a while, biggest first. A title only appears if nobody watched it within the chosen period and it has been here at least that long; something downloaded recently does not show up.

Above the table it says, unasked, how solid the number is: how many accounts the watch data comes from and which are missing. Without that sentence half a truth would look like a whole one.

Screenshot: the clean-up table with fifteen titles, each with size, last watched, how long it has been here, who watched it and who it is booked to
Biggest first. Filters by kind and period above; every row says who watched the title and whose quota it counts against.
Before anything disappears

Deleting with a grace period, not on the spot

Two ways stand side by side in the dialogue: delete now, or with fourteen days' grace. The grace period is the actual suggestion, and it is more than a waiting time.

During those fourteen days the title stands on the home page for everyone to see, everyone connected to it is told, and whoever watches it in that time cancels the deletion by doing so. No button, no objection, nobody has to ask. Knowing the outcome in advance saves the argument.

Deleting goes through Radarr and Sonarr, not around them. If a recycling bin is set up there, the file lands in it first; without one it is gone immediately and for good. That is in the dialogue before you press, not in a guide you read afterwards.

Screenshot: the delete dialogue with both ways — delete now or with fourteen days' grace — and the note about the recycling bin
The grace period is the suggestion. The red button is the one with the fourteen days, delete now sits beside it, unobtrusively.
Services

Per instance: is it answering, since when, and what does it say itself

For every Radarr and Sonarr instance: reachable or not and since when, the version, the length of the queue, how many titles are still missing, and the state of the callback.

“Since when” is the actual information. “Restarting right now” and “gone since last night” are two different messages, and a bare red light does not tell them apart.

If the instance reports a problem itself, it stands there in its original English wording. It is their statement, not ours, and anybody who goes searching with it will find the answer faster with the original text.

Screenshot: the Services tab with three findings about silent callbacks, below them per instance the version, state, queue and the message verbatim
One card per instance. Above them the findings for the area, here three callbacks that are not arriving, with the reason in brackets.
Operations

Nexview about itself

Backups and when the last one ran, how many mails are stuck in the outbox and how many were given up on, how many errors went into the log in the last twenty-four hours, plus version, schedule and the log level in force.

Three buttons lead straight from there to the backups, the log and the mail settings.

Screenshot: the Operations tab with four key figures on backups, outgoing mail and log errors, below them version, schedule and log level
Short, because usually nothing is here. And that is exactly the information you want.
Honestly

What Nexview cannot know

“Last watched” is only as good as the connected accounts. The watch data comes from the media server. Anybody who has not linked one does not appear in this calculation, what they watch, Nexview simply does not know. The list says so unasked: above the table it states how many of the existing accounts the watch data comes from and which are missing. Without that sentence half a truth would look like a whole one.

And sometimes Nexview knows somebody watched something but not when, media servers keep the two apart, and a trimmed history leaves the counter and loses the timestamp. The row then does not say “never”, it says “watched, when is unknown”. Such entries stay in the list and are counted above the table: leaving them out would hide exactly the oldest items.

“Here since” comes from Radarr and Sonarr, not from Nexview, it is the date the file was created there. Entries where it is still missing are skipped and counted above, rather than being quietly left out. The comparison runs hourly and fills it in.

And the library figures describe what Nexview manages, not what is on the disk. Files copied by hand, a second folder, old backups: none of that counts here. The disk itself is measured only by the ring on the dashboard, and that is exactly why it labels the rest “everything else” instead of hiding it.