Loading...
Loading...
This video is about setting up an automated home media system using Docker and mentions various tools like Rmapper, LIDAR, radar, sonar, Docker, Transmission, Unraid, Ubuntu server, Umbrel, TrueNAS, and Proxmox.
I've built another tool for you. in my github you'll find arr-mapper, it's a tool that will help you solve the downloads folder not mapping problem for your #sonarr #Radarr #lidarr setup.
Performance Category
Below Average
Score
2.5/5
Shares: 2/5
Comments: 5/5
Retention: 2/5
Views: 1/5
Likes: 3/5
Followers: 1/5
Script: 3.3/5
Total Views
1974
Likes
128
Shares
3
Comments
16
Duration
4m 22s
For You
1,786
90.5% of views
Follow
67
3.4% of views
Personal Profile
61
3.1% of views
Search
43
2.2% of views
Direct Message
10
0.5% of views
Others
6
0.3% of views
Sound
0
0.0% of views
Views
Likes
Shares
Comments
For You Traffic
Profile Traffic
Search Traffic
Non-Followers
32.0%
632 views
Followers
68.0%
1,342 views
4.7% of followers reached
New Followers
0
Performance vs Median
Transcript Available
Perceived Value
65/100
Compared to Average
Average
"If you're just setting up an automated home media system and you're using things like LIDAR, radar, sonar..."
"I've got a free tool in my GitHub that will solve this for you."
"Let me show you how to install it."
"Please let me know if it works for you."
"Feel free to buy me a coffee, and if you don't know, I do guides and giveaways..."
The opening eventually names a real issue, but it takes too long to get there and is hard to parse. Per the data, I am not penalizing the 0s-2s drop from 100% to 67% because early swipe loss is normal. However, there is still a continued decline from 67% at 2s to 50% at 5s and 43% at 10s, which is a normal decline but suggests the first spoken lines did not make the payoff immediately obvious. The hook starts with setup jargon before stating the actual error or benefit.
Lead with the exact pain and fix in one sentence: 'If Radarr/Lidarr says your Docker download path doesn't exist even though your setup is correct, this free GitHub tool auto-fixes the remote path mapping.' Put the audience, problem, and result before any setup detail.
"“If you're just setting up an automated home media system and you're using things like LIDAR, radar, sonar...”"
The script clearly signals a niche audience: home media automation users working with Docker, Lidarr/Radarr/Sonarr-style apps, Transmission, Unraid, and Ubuntu. That specificity is strong. The retention decline from 2s to 14s is mostly normal decline rather than a single anomalous drop, which suggests the right audience is being filtered in, even if the hook could be clearer.
Tighten the audience signal by naming the exact stack sooner and more cleanly: 'For Docker-based Arr-stack users on Unraid/Ubuntu with Transmission...' That will filter the right viewers in faster without the extra wording.
"“...using Docker...” / “The app is built to use Transmission.” / “I have tested this in Unraid and... Ubuntu server...”"
The problem is operational and real: mapped download paths appear correct, but the container cannot see them. That concreteness is a strength. The retention from 5s to 14s declines gradually from 50% to 38%, which is normal decline, not an anomalous collapse, suggesting the problem is relevant enough to sustain a portion of viewers. It loses a point because the wording is cluttered before the exact error is shown.
State the failure mode with a tighter symptom line: 'Your Arr app says the download path doesn't exist, even though Docker volumes are set up correctly.' Then immediately show the error screenshot.
"“...your download client is using this to download the files, but the Docker container doesn't seem to have mapped, even though you did the set-up absolutely correctly.”"
There is a payoff promise—'I've got a free tool in my GitHub that will solve this for you'—but the viewer is not told clearly enough what the end result looks like until much later. Retention shows a normal decline from 2s to 14s, with no positive plateau in the first 15 seconds, so the promise likely was not vivid enough to create strong stay-through motivation. The tool is introduced, but the transformation is not framed sharply.
Spell out the result in outcome language: 'In two minutes, I'll show you how to install a free tool that detects broken remote path mappings and fixes them automatically.' That makes the payoff visual and practical.
"“I've got a free tool in my GitHub that will solve this for you. Let me show you how to install it.”"
Once the tutorial starts, the script contains real utility, but it is slowed by repetition, filler, spelling things out, and live troubleshooting moments. The video is 262 seconds long, yet early retention is already at 38% by 14s, and there is no positive anomaly or like clustering in the first 15 seconds to suggest unusually strong perceived density up front. This indicates the content has value, but not every line advances understanding efficiently.
Compress installation steps and remove spoken filler. Replace live terminal narration with on-screen commands and voiceover summaries such as 'Clone repo, enter folder, run docker-compose up -d --build.' Keep spoken lines for decision points and troubleshooting insights only.
"“...click the code button, click HTTPS, and then copy the URL...” / “Control O, enter, control X to escape...”"
This is the script's strongest area. It uses concrete nouns, exact tools, ports, file paths, commands, environments, and credentials fields. That level of operational detail strongly supports utility. Although retention declines normally in the first 15 seconds, the transcript itself is highly specific and useful for the intended audience, which warrants a high score.
Keep the specificity, but package it better by grouping details into visual overlays or captions so viewers get the precision without needing to process every token in speech.
"“find Rmapper” / “docker-compose up -d --build” / “port 3000” / “docker-compose.yml” / “9091” / “x-api-key”"
The script sounds like it comes from real hands-on experience: the creator notes tested environments, unsupported platforms, actual setup paths, and even a forgotten step during the demo. Those are strong expertise signals. The 128 likes on 1,974 views also indicate decent audience approval for a niche technical tutorial, reinforcing perceived competence despite only moderate reach.
Add one brief proof statement earlier, such as 'I built this after hitting the same Docker path-mapping bug on my own Arr stack.' That would surface your credibility before the installation walkthrough begins.
"“I have tested this in Unraid and I've tested it on a Ubuntu server...” / “Umbrel, TrueNAS, Proxmox, I haven't tested it on.”"
The creator sounds human rather than overproduced, especially when admitting platform limitations and forgetting to connect Transmission before rescanning. That kind of imperfection reads as honest. The engagement profile—128 likes, 16 comments, 3 shares—suggests viewers found it useful and credible, though not highly viral. There is no positive retention anomaly in the first 15 seconds, but authenticity is still strong from the transcript itself.
Lean further into the personal reason for making the tool: mention the exact frustration that led you to build it. That would strengthen emotional honesty and make the tutorial more memorable.
"“Please let me know if it works for you.” / “I need to connect my Transmission. Totally forgot.”"
This is a high-load listen. The script stacks multiple tool names, file paths, commands, and corrections into long spoken lines. The retention trend after 2 seconds continues downward at a normal but persistent rate from 67% to 38% by 14s, which is consistent with viewers needing more effort than ideal to parse the content in real time. The issue is not lack of value; it is dense delivery.
Shorten spoken sentences to one action each and offload command syntax to text on screen. Example: 'Open GitHub. Copy the repo URL. In terminal, cd into your app folder. Then run this command.' Also avoid spelling out names mid-flow unless necessary.
"“CD into the Rmapper folder, so A-R-R forwards, uh, hyphen mapper, M-A-P-P-E-R...”"
The overall structure does move from problem to install to setup to fix, so there is real progression. However, it gets bogged down in step-by-step implementation and a mid-demo correction, which weakens momentum. Since the first-15-second retention shows only normal decline and no positive plateau, there is limited evidence that viewers felt a strong accelerating payoff early. The end result is clear eventually, but the path there could be cleaner.
Use a clearer sequence: 1) show the error, 2) show the fixed state, 3) explain the tool, 4) rapid install montage, 5) key setup fields, 6) scan and fix, 7) takeaway. Showing before-and-after earlier would create stronger forward motion.
"“This is an example of the error...” / “Let me show you how to install it.” / “Run the scan again... Recompute... Click fix.”"
KalSo glad I just run apps natively on my os. Running everything in docker just makes things needlessly complicated.
sometimes yeah.
what is your is choice?
KalJust have all my services running directly on my Mac mini server.
perfect
Jim OlerYES! Thank you.
MintFPShaha dark mode, legend!
Dany GonzalezBen do you know of a good self-hosted ticketing system(for like IT departments)?
I'll find something for you!
🤓🥸Amazing guide Ben, I was just working on my arr stack, so perfect timing really! 🫡
Awesome!
sorry for the Jumpscare there.. I really need to sort out my editing!!
bababUgzhonestly it was kind of funny ! do as you see fit but that bit was legit funny
if it was funny, then i meant to do it!!
Total viewers and likes aligned with spoken words.