The finding first, the evidence second
A page of numbers answers “how much”.
Jump there →
The finding first, the evidence second
A page of numbers answers “how much”.
Jump there →
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 →
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 →
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 →
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 →
The finding first, the evidence second
A page of numbers answers “how much”.
Jump there →
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
“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.