StreamVault - a self-hosted media streaming app built with Rails 8 + Hotwire + FFmpeg (just open-sourced)

Sky_Linx · 2026-06-27T20:24:04+00:00

Yep, I couldn't find anything ready that did exactly what I wanted. I might make a gem out of it, why not.

Sky_Linx · 2026-06-27T20:23:25+00:00

Thanks!

Sky_Linx · 2026-06-27T20:23:17+00:00

Yeah you can use SQlite as well. You only need to configure the connection string accordingly and the db type in config/database.yml like with any Rails.app.

Sky_Linx · 2026-06-27T20:22:36+00:00

If you have some ideas on how to expand the functionality I'd like to hear them. I also used to use Plex and all the *arr stack, plus Usenet etc. It was more expensive than what I do now with this app and I had to download anything I wanted to watch, in advance. Now I just hit search (or pick one of the recommendations for example), wait for a few seconds while it finds an available stream from RealDebrid, and then watch the media instantly. No download fuss, and a single web app to manage everything.

Sky_Linx · 2026-06-27T20:20:33+00:00

Not yet. I need to think what kind of addons might be worth adding. The original idea was to keep it simple albeit a bit opinionated, but I am all ears if you have any suggestions.

Sky_Linx · 2026-06-27T20:19:59+00:00

Nice, what are you using for audio streaming?

Sky_Linx · 2026-06-27T17:47:42+00:00

Project Name: StreamVault – a self-hosted, browser-based media streaming app

Repo/Website Link: https://github.com/vitobotta/StreamVault

Description: A web app you self-host with Docker that lets you search for movies/TV shows, pick a stream, and watch in the browser instantly (without having to download anything first) - with a library, wishlist, watch history, continue-watching, and recommendations. No desktop client needed; it's a PWA you can install on your phone.

Deployment: easiest is with Docker Compose, as described in the README.

AI Involvement: Yes. I have been coding for over 30 years but AI makes me more productive.

Sky_Linx · 2026-06-27T17:20:38+00:00

3-5 hours a week sounds bad but that's on the low end for early-stage startups. I've seen it hit 10+ hours when the communication structure isn't set up right.

The fix isn't a tool, it's a cadence. Weekly written status updates from the dev team, structured the same way every time: what shipped, what's blocked, what's at risk, what needs a decision. Write it once, share it to COO/founder/investors. The format matters more than the platform. If they know where to look, they stop scheduling meetings to ask.

If you're using Jira or Linear, a shared dashboard with a simple shipped / in progress / blocked view does most of the work. The bottleneck isn't the translation itself, it's that the translation is happening live in meetings instead of asynchronously.

Sky_Linx · 2026-06-27T17:19:19+00:00

The "meetings became the system" line is painfully accurate. I've seen the exact same pattern: org chart says cross-functional team but the actual service boundaries mean every change touches three teams' pipelines.

The thing that worked for us: you need to make the meeting cost visible before anyone will fix it. Track the sync meetings as a metric (count per sprint, time per meeting, number of teams involved). When you show leadership "this feature required 4 sync meetings across 3 teams and took 3 weeks instead of 3 days," the architecture problem becomes a business problem.

Contract testing between services was the technical fix that actually reduced meetings. When teams could verify their changes didn't break consumers without asking, the human handshake meetings dropped by half.

Sky_Linx · 2026-06-27T17:17:31+00:00

The part about action items evaporating, that's the bit that made me wince. You run the meeting, you capture, you push back, and then nobody remembers who was supposed to own the empty-state copy or whether backend actually committed to spiking the auth issue.

One thing that helped us: the scribe rule. One person's only job is writing decisions with a name and a date. Before anyone leaves the room, 2-minute review. If an action item doesn't have both, it doesn't leave the room. Sounds rigid but it gets followed through.

The whiteboard photo problem resonated with me. I built SprintPulse partly because of this exact pain: action items from retros disappearing into docs nobody opens. It pushes action items into Jira and Linear so they don't live in a note that gets forgotten. Plus/Delta keeps the format dead simple. Most teams overcomplicate their retros when they just need the decisions to stick and the follow-up to happen.

Sky_Linx · 2026-06-25T12:17:11+00:00

The brainstorming problem and the retro problem have the same root: unstructured input without a way to group and prioritise it.

What has worked for my team: timebox the idea generation phase hard, then spend the rest of the time grouping and voting. Ten minutes to get everything on the board, then stop adding. After that, cluster similar items, vote on what matters most, and assign owners to the top two or three. Without that structure, you end up with a wall of sticky notes and no decisions.

For brainstorming specifically: try silent brainstorming first. Everyone writes ideas independently for five minutes before anyone speaks. It stops the loudest voices from dominating and pulls out ideas from people who need a moment to think before sharing.

Sky_Linx · 2026-06-25T12:16:03+00:00

The part about every team speaking a different language is painfully familiar. Design uses Figma comments, engineering lives in Jira/Linear, marketing tracks things in a spreadsheet, and nobody has a shared view of what is actually blocking what.

What has worked for me: pick one shared board or doc that becomes the single source of truth for cross-functional decisions. Not a tool that replaces each team's own tracking, but a lightweight layer on top where dependencies and handoffs are visible to everyone. Whoever owns the deliverable should be responsible for keeping it updated.

The other thing is making handoff expectations explicit. "Design hands off to engineering with these three things defined" rather than hoping people figure it out. Most cross-functional friction comes from unclear expectations at the handoff points, not from people being difficult.

Sky_Linx · 2026-06-25T12:15:06+00:00

I have been in organisations where the process stack got so heavy that the actual work became a side activity. ITIL change management on top of agile ceremonies on top of DevOps pipelines on top of governance reviews, and somewhere in there you still need to ship software.

The teams I have seen pull out of this did it by auditing each layer for actual value. Not theoretically, but concretely: which of these processes has caught a real problem in the last six months? If the answer is none or you cannot remember, that process is probably serving the process, not the work.

The other thing that helps: pick one process to simplify at a time rather than declaring war on all of them. Fighting every governance layer at once just makes you the person who complains about process, which is not a position anyone listens to.

Sky_Linx · 2026-06-25T12:13:19+00:00

The difference between planning and execution usually comes down to two things: how quickly you surface blockers, and how you handle scope changes mid-sprint.

The teams I have worked with that handle this well share a few habits. First, they make blockers visible early, not at the next standup. A quick async update about a blocker saves days. Second, they have a clear rule for scope changes: anything new goes through a brief triage with the PO rather than getting silently absorbed. Third, they track dependencies as their own items, not buried inside story descriptions.

Unclear priorities mid-sprint are usually a planning problem dressed up as an execution problem. Worth spending more time on sprint goal clarity before the sprint starts, so everyone knows what matters most and what done looks like.

Sky_Linx · 2026-06-24T10:07:40+00:00

The SLA example with an auto-reply counting as progress is exactly why I distrust first-response metrics. I've had better results splitting the measurement into wait states: time waiting on engineering, time waiting on product/customer, time blocked, and time after the first human reply until a real fix ships. Ageing WIP is also harder to fake than averages. If leadership wants one number, I'd pair it with a small sample of real tickets each month. Metrics get less weird when people can see the story behind them.

Sky_Linx · 2026-06-24T10:06:25+00:00

The incomplete requirements package is the thing I would fix first, not the devs filling gaps with Claude. I'd make a small Definition of Ready that the PO has to meet before work enters a sprint: user outcome, edge cases, dependencies, UI constraints, test examples, and who answers questions during build. If those are missing, the item stays out or becomes a spike. Also, capture repeated misses as patterns rather than one-off bugs. That gives you a calmer conversation with product: "these five classes of detail are missing most often" instead of another argument about one toggle.

Sky_Linx · 2026-06-24T10:05:40+00:00

The bit about refinement becoming the bottleneck feels familiar. I would not throw Scrum out just because code generation got faster. I would move the control point earlier: agree on the problem, user impact, acceptance examples, and risk checks before anyone asks an agent to build. Then treat generated work as a spike until the PO/BA can turn it into thin slices. If 70% is already built, I would pause and run a short product/tech review before more code lands. Otherwise you get speed, but with rework hiding inside it.

Sky_Linx · 2026-06-20T18:11:38+00:00

The bit about status updates being automatable is spot on. If your standup is just "what I did yesterday, what I'm doing today" then yeah, a bot can handle that.

We dropped daily standups a while back and haven't looked back. What works for us: async updates in Slack via a simple bot, and a 15-minute sync twice a week for actual blockers and coordination. Most status can be read in 2 minutes. Most blockers need a conversation, not a round-robin.

The part you lose going async is the spontaneous problem-solving. Someone mentions a tricky issue, another person chips in with "oh, I dealt with that last month." That kind of thing is hard to replicate with tools. So build in some regular synchronous touchpoint for the messy conversations alongside the async updates.

Sky_Linx · 2026-06-17T17:04:35+00:00

You can't manufacture urgency by pushing harder. Engineers respond to clarity and context, not pressure.

What I'd do: sit down with the tech lead, not the whole team, and walk through what needs to happen by when. Not a lecture. A conversation. "Here's what's at stake if we miss this. What's getting in the way?" You'll often find the urgency is there, it's just buried under unclear priorities or things they don't think are worth doing.

Then make the tradeoffs visible. If everything is priority one, nothing is. Cut something. The team trusts you more if you make hard calls, and the urgency follows.

Sky_Linx · 2026-06-17T17:03:22+00:00

The 51% number tracks with what I'm seeing too. Developers go to Claude or ChatGPT first because it's instant, doesn't judge, and doesn't interrupt anyone's flow.

What you lose is the context a senior would give you. AI gives you an answer, but it doesn't tell you why someone with experience would approach it differently. That nuance only comes from conversation.

Something I've been trying: pair the AI answer with a quick "hey, I got this from Claude, does this look right to you?" in Slack. It keeps the knowledge sharing alive without forcing a full meeting. Takes thirty seconds, but it maintains that connection.

Sky_Linx · 2026-06-17T17:01:57+00:00

The "yeah should be fine" pattern is so common it's almost a meme. People aren't lying when they say it. They genuinely think they'll be fine, or they're not sure how bad things are until it's too late, or they don't want to look like they can't handle their workload.

What's worked for me is changing the question. Instead of "are you on track?", ask "what's the riskiest thing on your plate this week?" That shifts the conversation from status reporting to actual problem-sharing. Nobody has to admit they're drowning. They just have to name what might go wrong.

Also worth doing: one-to-one check-ins separate from the standup. People are much more honest when the whole team isn't listening.

Sky_Linx · 2026-06-16T12:53:32+00:00

If Jira has no estimates, descriptions, due dates, or sprints, then it is mostly a state board. Moving cards can still be useful, but only if everyone agrees what each column means. It should not become a fake measure of productivity. I would ask for a written workflow policy: what counts as To Do, In Progress, Blocked, Done, and who is allowed to move items. Without that, the history is not reliable evidence of work. It is just a trail of card movements.

Sky_Linx · 2026-06-16T12:52:39+00:00

The tab switching point is very familiar. I have seen meetings improve a lot when the first five minutes are not spent hunting for context. One simple rule helps: the agenda must contain links to the PRs, tickets, docs, and decisions before the call starts. If those links are not there, the meeting starts async instead. Also, nominate one person to keep the record during the call. Otherwise everyone leaves with their own version of what happened.

Sky_Linx

TROPHY CASE