Forem: Pratyush Mishra

The problem with every watch-party app ever made

Pratyush Mishra — Mon, 13 Apr 2026 16:27:39 +0000

You open Teleparty. Your friend opens Teleparty. You both navigate to the same Netflix URL. You count to three. Someone's internet hiccups. Now you're 4 seconds ahead and the joke lands for only one of you.

The fundamental issue isn't synchronization. It's architecture. Every mainstream watch-party tool works by syncing a cursor position on top of a third-party stream. You're both still pulling separate streams from Netflix's CDN, hoping latency is kind, and papering over the cracks with a shared play/pause event.

SameRow approaches this differently. Instead of syncing a cursor on someone else's platform, it syncs playback state between two self-hosted Jellyfin instances. Each user streams true 4K from their own server, to their own screen. The only thing traveling over the network is a lightweight state signal — play, pause, seek, timestamp. No screen capture. No transcoding penalty. No DRM fights.

This is the technical breakdown of how it works.

The Architecture at a Glance

Before diving into individual components, here's what the full system looks like:

User A                          Signaling Server              User B
┌─────────────────┐            ┌──────────────────┐          ┌─────────────────┐
│  Jellyfin       │            │  Room State      │          │  Jellyfin       │
│  Instance (4K)  │            │  WebSocket Hub   │          │  Instance (4K)  │
│                 │◄──sync─────│                  │─────sync►│                 │
│  SameRow Client │            │  Clock Sync      │          │  SameRow Client │
│  (WebRTC)       │◄──p2p─────────────────────────────p2p───►│  (WebRTC)       │
└─────────────────┘            └──────────────────┘          └─────────────────┘
        │                                                              │
        │                                                              │
Cloudflare Tunnel                                            Cloudflare Tunnel
(CGNAT bypass)                                               (CGNAT bypass)

Three layers working simultaneously:

Signaling layer — a lightweight server managing room state and clock synchronization
P2P layer — WebRTC direct connection for video calling and screen sharing
Media layer — each client's local Jellyfin instance, playing content independently but in sync

The CGNAT Problem and Why It Matters

Most home internet connections in India — and increasingly everywhere — use Carrier-Grade NAT. Your ISP assigns you a private IP shared with hundreds of other subscribers. Port forwarding is impossible. Your Jellyfin server is invisible to the public internet.

The standard advice is "just buy a VPS and reverse proxy it." That works but it routes all your 4K media traffic through a server you're paying for by the gigabyte. Expensive and unnecessarily slow.

SameRow uses a split-tunneling approach instead:

Cloudflare Tunnels for Jellyfin access:

# Install cloudflared
curl -L https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64 -o cloudflared
chmod +x cloudflared

# Authenticate and create tunnel
./cloudflared tunnel login
./cloudflared tunnel create samerow-jellyfin

# Configure the tunnel
cat > ~/.cloudflared/config.yml << EOF
tunnel: <YOUR_TUNNEL_ID>
credentials-file: /root/.cloudflared/<YOUR_TUNNEL_ID>.json

ingress:
  - hostname: jellyfin.yourdomain.com
    service: http://localhost:8096
  - service: http_status:404
EOF

# Run as service
./cloudflared tunnel run samerow-jellyfin

This gives each user a stable public HTTPS endpoint for their Jellyfin instance with zero open ports and zero VPS costs. The media streams directly from their machine to their own browser. Only the Jellyfin API calls — the lightweight state signals — travel through the tunnel.

Tailscale for the signaling server:

# Install Tailscale
curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up

# Signaling server is now accessible at the Tailscale IP
# No public exposure needed for the coordination layer

The Signaling Server

The signaling server has one job: coordinate room state between clients. It does not touch media. It does not proxy streams. It is intentionally thin.

Built with Node.js and Socket.io:

// server/index.js
const express = require('express')
const { createServer } = require('http')
const { Server } = require('socket.io')

const app = express()
const httpServer = createServer(app)
const io = new Server(httpServer, {
  cors: { origin: '*' }
})

// Room state store
const rooms = new Map()

io.on('connection', (socket) => {
  console.log(`Client connected: ${socket.id}`)

  // Room creation
  socket.on('create-room', ({ roomId, jellyfinUrl }) => {
    rooms.set(roomId, {
      host: socket.id,
      jellyfinUrl,
      playbackState: {
        isPlaying: false,
        currentTime: 0,
        itemId: null,
        lastUpdated: Date.now()
      },
      clients: new Set([socket.id])
    })
    socket.join(roomId)
    socket.emit('room-created', { roomId })
  })

  // Room joining
  socket.on('join-room', ({ roomId }) => {
    const room = rooms.get(roomId)
    if (!room) return socket.emit('error', { message: 'Room not found' })

    room.clients.add(socket.id)
    socket.join(roomId)

    // Send current state to joining client
    socket.emit('room-state', room.playbackState)
    socket.to(roomId).emit('peer-joined', { peerId: socket.id })
  })

  // Playback state sync
  socket.on('playback-update', ({ roomId, state }) => {
    const room = rooms.get(roomId)
    if (!room) return

    // Only host can update state
    // (prevents feedback loops from multiple simultaneous updates)
    if (socket.id !== room.host) return

    room.playbackState = { ...state, lastUpdated: Date.now() }
    socket.to(roomId).emit('playback-sync', room.playbackState)
  })

  socket.on('disconnect', () => {
    rooms.forEach((room, roomId) => {
      room.clients.delete(socket.id)
      if (room.clients.size === 0) rooms.delete(roomId)
    })
  })
})

httpServer.listen(3001)

The host-only write pattern on line 47 is important. It's what prevents the feedback loop problem — when multiple clients can all emit state updates, you get an infinite ping-pong of play/pause events. One source of truth, broadcast to everyone else.

WebRTC: Video Calls and Screen Sharing

The media synchronization and the video calling are separate concerns in SameRow. WebRTC handles the human layer — seeing your friend's face, sharing your screen — while Jellyfin handles the content layer.

// client/webrtc.js
class SameRowPeer {
  constructor(socket, roomId) {
    this.socket = socket
    this.roomId = roomId
    this.peers = new Map()
  }

  async initializeMedia() {
    // Get camera and microphone
    this.localStream = await navigator.mediaDevices.getUserMedia({
      video: { width: 1280, height: 720 },
      audio: true
    })
    return this.localStream
  }

  async startScreenShare() {
    // Capture display — this is traditional screen sharing
    // but in SameRow it's used for the UI overlay, not the media
    this.screenStream = await navigator.mediaDevices.getDisplayMedia({
      video: { frameRate: 30 },
      audio: true
    })
    return this.screenStream
  }

  async createPeerConnection(peerId) {
    const pc = new RTCPeerConnection({
      iceServers: [
        { urls: 'stun:stun.l.google.com:19302' },
        // Add TURN server here for production
      ]
    })

    // Add local tracks
    this.localStream.getTracks().forEach(track => {
      pc.addTrack(track, this.localStream)
    })

    // ICE candidate handling
    pc.onicecandidate = ({ candidate }) => {
      if (candidate) {
        this.socket.emit('ice-candidate', {
          roomId: this.roomId,
          peerId,
          candidate
        })
      }
    }

    // Handle incoming tracks
    pc.ontrack = ({ streams }) => {
      const remoteVideo = document.getElementById('remote-video')
      remoteVideo.srcObject = streams[0]
    }

    this.peers.set(peerId, pc)
    return pc
  }

  async makeOffer(peerId) {
    const pc = await this.createPeerConnection(peerId)
    const offer = await pc.createOffer()
    await pc.setLocalDescription(offer)

    this.socket.emit('webrtc-offer', {
      roomId: this.roomId,
      peerId,
      offer
    })
  }

  async handleOffer(peerId, offer) {
    const pc = await this.createPeerConnection(peerId)
    await pc.setRemoteDescription(offer)

    const answer = await pc.createAnswer()
    await pc.setLocalDescription(answer)

    this.socket.emit('webrtc-answer', {
      roomId: this.roomId,
      peerId,
      answer
    })
  }
}

The Jellyfin Integration

This is where SameRow diverges from every other watch-party implementation.

Instead of capturing and re-encoding your screen, SameRow reads playback state from Jellyfin's API and replicates it on the other client's Jellyfin instance. Both users are playing the same file from their own library. The streams never leave their respective machines.

// client/jellyfin.js
class JellyfinSync {
  constructor(serverUrl, apiKey) {
    this.serverUrl = serverUrl
    this.apiKey = apiKey
    this.headers = {
      'X-Emby-Token': apiKey,
      'Content-Type': 'application/json'
    }
  }

  // Poll current playback state
  async getPlaybackState(sessionId) {
    const response = await fetch(
      `${this.serverUrl}/Sessions?api_key=${this.apiKey}`
    )
    const sessions = await response.json()
    const session = sessions.find(s => s.Id === sessionId)

    if (!session?.NowPlayingItem) return null

    return {
      itemId: session.NowPlayingItem.Id,
      currentTime: session.PlayState.PositionTicks / 10000000, // Convert ticks to seconds
      isPlaying: !session.PlayState.IsPaused,
      mediaTitle: session.NowPlayingItem.Name
    }
  }

  // Apply playback state to local Jellyfin instance
  async applyPlaybackState(sessionId, state) {
    const positionTicks = Math.floor(state.currentTime * 10000000)

    // Seek to position
    await fetch(
      `${this.serverUrl}/Sessions/${sessionId}/Playing/Seek`,
      {
        method: 'POST',
        headers: this.headers,
        body: JSON.stringify({ SeekPositionTicks: positionTicks })
      }
    )

    // Play or pause
    const command = state.isPlaying ? 'Unpause' : 'Pause'
    await fetch(
      `${this.serverUrl}/Sessions/${sessionId}/Playing/${command}`,
      { method: 'POST', headers: this.headers }
    )
  }

  // Start polling for state changes (host only)
  startPolling(sessionId, onStateChange, interval = 1000) {
    this.pollingInterval = setInterval(async () => {
      const state = await this.getPlaybackState(sessionId)
      if (state) onStateChange(state)
    }, interval)
  }

  stopPolling() {
    clearInterval(this.pollingInterval)
  }
}

The polling approach is used here rather than webhooks for simplicity. Jellyfin does support a webhooks plugin for real-time push events — that's the production-grade version — but for an MVP, 1-second polling introduces acceptable latency and is far easier to implement and debug.

The Drift Compensation System

This is the most technically interesting part of SameRow and the problem most WebRTC tutorials skip entirely.

When two clients receive a "seek to timestamp X" command, they don't execute it at exactly the same moment. Network latency means Client B receives the command some milliseconds after Client A. Over time, these small offsets compound into visible desync.

SameRow handles this with a three-tier system:

Tier 1: NTP-Style Clock Offset Calculation

On session start, both clients calculate the true network offset between them:

// client/clockSync.js
class ClockSync {
  constructor(socket) {
    this.socket = socket
    this.offset = 0
    this.rtt = 0
  }

  async calculateOffset() {
    return new Promise((resolve) => {
      const t1 = Date.now()

      this.socket.emit('clock-ping', { t1 })

      this.socket.once('clock-pong', ({ t1, t2, t3 }) => {
        const t4 = Date.now()

        // NTP offset formula
        this.rtt = (t4 - t1) - (t3 - t2)
        this.offset = ((t2 - t1) + (t3 - t4)) / 2

        console.log(`Clock offset: ${this.offset}ms, RTT: ${this.rtt}ms`)
        resolve(this.offset)
      })
    })
  }

  // Schedule playback to start at a future agreed timestamp
  // Both clients receive the same startAt value
  // Network delay is already accounted for in the offset
  schedulePlayback(startAt) {
    const localStartAt = startAt + this.offset
    const delay = localStartAt - Date.now()

    if (delay > 0) {
      setTimeout(() => this.triggerPlayback(), delay)
    } else {
      this.triggerPlayback()
    }
  }
}

Tier 2: Gradual Drift Correction (The Silent Fix)

For small ongoing drift under 2 seconds, SameRow adjusts playback rate rather than seeking. This is the same technique streaming platforms use — imperceptibly playing at 1.05x or 0.95x until the clients converge:

// client/driftCompensation.js
class DriftCompensation {
  constructor(jellyfinClient) {
    this.jellyfin = jellyfinClient
    this.checkInterval = null
  }

  start(sessionId, getExpectedTime) {
    this.checkInterval = setInterval(async () => {
      const state = await this.jellyfin.getPlaybackState(sessionId)
      if (!state || !state.isPlaying) return

      const expectedTime = getExpectedTime()
      const drift = state.currentTime - expectedTime

      await this.compensate(sessionId, drift)
    }, 1000)
  }

  async compensate(sessionId, drift) {
    const absDrift = Math.abs(drift)

    if (absDrift < 0.1) {
      // Under 100ms — within acceptable tolerance, do nothing
      return
    }

    if (absDrift >= 0.1 && absDrift < 0.5) {
      // 100ms to 500ms — silent rate adjustment
      // User never notices a 5% speed change
      const rate = drift > 0 ? 0.95 : 1.05
      await this.jellyfin.setPlaybackRate(sessionId, rate)

    } else if (absDrift >= 0.5 && absDrift < 2.0) {
      // 500ms to 2s — more aggressive rate adjustment
      const rate = drift > 0 ? 0.90 : 1.10
      await this.jellyfin.setPlaybackRate(sessionId, rate)

    } else {
      // Over 2s — hard resync, pause both clients
      await this.hardResync(sessionId)
    }
  }

  async hardResync(sessionId) {
    // Pause, seek to correct position, resume
    // This is the last resort — visible to user but necessary
    console.log('Drift exceeded 2s threshold — executing hard resync')
    // Implementation: emit resync event to signaling server
    // Server broadcasts pause + seek + resume to all clients
  }

  stop() {
    clearInterval(this.checkInterval)
  }
}

Tier 3: Hard Resync

Only triggered when drift exceeds 2 seconds — network congestion, a client that was backgrounded, a machine that went to sleep. At this point invisible correction isn't possible and both clients pause, seek to the correct timestamp, and resume together.

Docker Deployment

The entire stack ships as a single docker-compose.yml. Any user with Docker installed can run SameRow with their own Jellyfin instance in under five minutes:

# docker-compose.yml
version: '3.8'

services:
  signaling:
    build: ./signaling
    ports:
      - "3001:3001"
    environment:
      - NODE_ENV=production
    restart: unless-stopped

  client:
    build: ./client
    ports:
      - "3000:3000"
    environment:
      - NEXT_PUBLIC_SIGNALING_URL=http://localhost:3001
    depends_on:
      - signaling
    restart: unless-stopped

networks:
  default:
    driver: bridge

# signaling/Dockerfile
FROM node:18-alpine

WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production

COPY . .
EXPOSE 3001

CMD ["node", "index.js"]

The Jellyfin instances are not containerized here — they're external. Users bring their own. The JELLYFIN_URL and JELLYFIN_API_KEY are runtime environment variables, meaning SameRow works with any Jellyfin instance anywhere, including behind a Cloudflare Tunnel.

# One command deployment
JELLYFIN_URL=https://jellyfin.yourdomain.com \
JELLYFIN_API_KEY=your_api_key_here \
docker-compose up -d

Key Features Summary

Feature	Implementation	Why it matters
Synchronized playback	Jellyfin API polling + signaling server	True 4K, no quality loss
CGNAT bypass	Cloudflare Tunnels	Works on any home connection
Drift compensation	Three-tier rate adjustment	No jarring pause-and-resync
Video calling	WebRTC P2P	See your friend while watching
Screen sharing	`getDisplayMedia()`	Share UI context, not media
Room management	Socket.io + host authority model	Prevents feedback loops
Portable deployment	Single Docker Compose file	Anyone can self-host it

What's Next

The current implementation uses polling to read Jellyfin state. The production upgrade is Jellyfin's webhooks plugin — real-time push events instead of 1-second polls, dropping the baseline latency from ~1000ms to near-zero.

The TURN server situation also needs addressing for production. STUN works when both clients have relatively open NATs. Behind stricter firewalls — corporate networks, some mobile connections — WebRTC P2P fails and you need a TURN relay. Coturn is the standard self-hosted option and slots into the Docker Compose setup cleanly.

The GitHub repository with full source, deployment documentation, and architecture diagrams is at: github.com/devpratyushh/samerow

SameRow is open source. If you run a Jellyfin instance and want synchronized watch parties without giving up 4K quality, this is the setup.

Post-Mortem: Why My Ubuntu Docker Homelab Failed (And Why I Killed It)

Pratyush Mishra — Sun, 12 Apr 2026 11:23:13 +0000

The Origin Story

It started with a spare 500GB hard drive and a problem that had been quietly annoying me for months.

My digital life was fragmented across three different services I didn't control, two hard drives I kept forgetting to back up, and a Google Photos library that was one policy change away from becoming someone else's problem. July 2024. I had a virtualization host, a free weekend, and the dangerous combination of too much free time and just enough Linux knowledge to be overconfident.

The original goal was modest — a basic NAS. Centralize the drives, access files from anywhere, stop worrying about losing photos. That was the plan.

Scope creep had other ideas.

Within a few weeks, the "basic NAS" had grown into something I started calling Ghar Labs v1 — a monolithic microservices host running:

Media Automation — Jellyfin with the full *Arr stack for automated library management
Sovereign Cloud — Nextcloud replacing Google Drive and Photos entirely
Observability — Prometheus, Grafana, and Netdata for real-time monitoring

The inspiration was equal parts practical and philosophical. I'd been reading about self-hosting communities — r/homelab, r/selfhosted — and the idea of owning your own data stack resonated. Not paranoia. Just the quiet satisfaction of knowing exactly where your files live and who has access to them.

I also wanted to learn. Running production services on your own hardware teaches you things no tutorial covers — because tutorials don't page you at 3 a.m. when something breaks.

The Technical Architecture

The entire system ran as a single Ubuntu Server 24.04 LTS virtual machine, orchestrating 10+ containers via Docker Compose.

Component	Choice	Why
Hypervisor	Oracle VirtualBox (Windows host)	Already available, zero cost
Resources	4 vCPUs, 4GB RAM	Proof of concept allocation
Networking	Bridged Adapter	Direct LAN access for SMB
Public routing	Cloudflare Tunnels	CGNAT bypass, no exposed ports
Private routing	Tailscale	Secure SSH and SMB access

All services were containerized. To prevent I/O errors and duplicate media files, the downloader and media player were pointed at the exact same physical path using strict PUID/PGID permissions:

/mnt/data/
├── media/              # The unified directory
│   ├── movies/
│   └── shows/
└── nextcloud/          # Sovereign cloud data

Clean architecture on paper. Production, as usual, had other plans.

The CGNAT Problem

The first real engineering challenge wasn't Docker. It was my ISP.

CGNAT — Carrier-Grade NAT — means your ISP assigns you a private IP address shared with potentially hundreds of other subscribers. Port forwarding is impossible. Your server is invisible to the public internet. No A record is going to help you there.

The naive solution is to rent a VPS and reverse proxy everything through it. That works, but it routes all your traffic — including 4K media — through a server you're paying for by the gigabyte. Expensive, slow, and architecturally wasteful.

After research and a lot of trial and error, I landed on a split-tunneling approach:

Public routing: Cloudflare Tunnels handled inbound HTTP traffic (Nextcloud web interface, Jellyfin, dashboards) without ever exposing my origin IP. No open ports required. The tunnel runs as a lightweight daemon on the host and registers itself with Cloudflare's edge network.
Private routing: Tailscale handled everything that didn't need to be public — SMB shares, direct SSH access, internal dashboards. Zero-config mesh VPN with WireGuard under the hood.

# Cloudflare tunnel config
tunnel: <YOUR_TUNNEL_ID>
credentials-file: /root/.cloudflared/<YOUR_TUNNEL_ID>.json

ingress:
  - hostname: nextcloud.yourdomain.com
    service: http://localhost:80
  - hostname: jellyfin.yourdomain.com
    service: http://localhost:8096
  - service: http_status:404

The result was a server that was fully accessible from anywhere in the world, with zero open firewall ports and zero VPS costs. Public traffic through Cloudflare's edge. Private traffic through Tailscale's encrypted mesh. The ISP's CGNAT became irrelevant.

It was the part of this project I was most proud of. It was also completely unrelated to why the server eventually died.

Failure Point 1: The Zombie Process Leak

Over weeks of uptime, RAM usage would creep upward with no corresponding spike in CPU. The server wasn't doing more work — it just wasn't cleaning up after itself.

Logging into the terminal eventually surfaced a warning: 2 zombie processes.

A subsequent htop audit confirmed the diagnosis.

Docker containers were not reaping child processes correctly. When you run an application inside a container without an init system — dumb-init or tini — PID 1 inside the container doesn't know how to adopt orphaned processes. They linger in the process table, unconsumed, until the host reboots.

The fix is straightforward: add --init to your docker run call, or in Compose:

services:
  your-app:
    init: true

I learned this after the fact. The server did not.

Failure Point 2: Silent OOM Kills

Core services like Nextcloud held up reasonably well. Heavier JVM and Go-based monitoring tools did not — they were fighting over the same 4GB ceiling.

During my final audit before decommissioning, a routine docker ps -a revealed what I had missed for months:

CONTAINER ID   IMAGE     COMMAND   STATUS
a3f1b2c9d4e5   grafana   ...       Exited (255) 87 days ago

Grafana had silently crashed — exit code 255, OOM killed — and never came back. Docker's restart policy tried, the kernel said no, and the container just quietly stopped existing. No alert. No notification. The dashboard I thought was watching my stack had itself gone dark.

The lesson: docker ps -a is not optional. Automate the check, or instrument a watchdog. A monitoring tool that nobody monitors is just a pretty corpse.

Failure Point 3: The Single Point of Failure

The zombie leak and the OOM kills were annoying. This one was existential.

The entire lab lived on one virtual disk (.vdi). One volume, no redundancy:

❌ No ZFS bit-rot protection
❌ No RAID parity
❌ No snapshots
❌ No off-host backups of the database

A single bad sector — or a host crash mid-write — could corrupt the Nextcloud database and take years of personal data with it. I had built a fairly sophisticated networking layer on top of a foundation that was, architecturally, one fsck error away from disaster.

This is the part where I stopped calling it a "proof of concept" and started calling it "a liability."

The Resolution

Ghar Labs v1 was a successful learning environment. In twelve months, it taught me things no tutorial would:

How Docker networking actually behaves under sustained load
How to engineer around CGNAT without spending money on a VPS
What happens to PID 1 when you don't think about it
Why storage architecture is the foundation, not an afterthought

But a single-node VM with no storage redundancy, no init system, and a 4GB RAM ceiling is not where you keep data you care about.

I decommissioned the Ubuntu host, wiped the drives, and migrated the entire stack to a dedicated bare-metal machine running TrueNAS Scale with proper ZFS redundancy. The services are the same. The foundation is not.

The spare 500GB drive that started this whole thing is now sitting in a ZFS mirror pool, bit-rot protected, snapshotted nightly.

Sometimes the best thing you can do with a legacy server is document what it taught you, shut it down gracefully, and build the next one right.

The full configuration archive — Compose files, Cloudflare tunnel configs, Tailscale ACLs — is preserved here for reference:

→ devpratyushh/homelab-v1-archive

It's retired. But it earned its README.

Next post: Ghar Labs v2 — migrating the entire stack to TrueNAS Scale with ZFS, proper jail isolation, and a networking layer that survives a power cut.