Ik heb een spraakgestuurd thuisbioscoop voor Windows gebouwd omdat ik het zat was om op te staan om films te pauzeren

Ik heb dit niet gebouwd omdat ik een “slim entertainmentplatform” wilde. Ik heb het gebouwd omdat ik het beu was om op te staan. Mijn opstelling was eenvoudig: een Windows-pc aangesloten op een tv via HDMI, lokale filmbestanden en een normale mediaspeler. Geen streaming. Geen mediaserver. Geen cloud synchronisatie. Alleen bestanden op schijf en directe weergave. Dat deel was prima. Het vervelende deel begon nadat de film begon. Film pauzeren? Reik naar het toetsenbord. Vooruit springen? Hetzelfde. Ondertitels nodig? Terug naar de pc. De volgende aflevering willen? Weer terug. De echte frictie kwam van iets heel eenvoudigs. Bij het kijken van films vanuit bed, betekent elke pauze, sprong of volgende opdracht opstaan, naar de computer lopen, het toetsenbord gebruiken en dan weer teruggaan. De weergave zelf was eenvoudig – alleen lokale bestanden en een mediaspeler – maar de ervaring eromheen gedroeg zich nog steeds als desktop computing. Het voelde niet als een thuisbioscoop. Natuurlijk zijn er bestaande manieren om dit aan te pakken. Draadloze toetsenborden, air-muizen en afstandsbedieningsapps kunnen allemaal helpen. Maar ze behandelen de ervaring nog steeds als het bedienen van een computer. Je beweegt nog steeds een cursor, navigeert door menu's of drukt op toetsen – je interageert met software in plaats van gewoon de film te bekijken. In een echte bioscoopervaring verdwijnt de technologie. Je focust je op de film, niet op de interface. Dus ik begon met een heel praktische vraag: Kon een Windows-pc die op een tv is aangesloten, minder vervelend te bedienen zijn vanaf de andere kant van de kamer? Die vraag groeide uiteindelijk uit tot een zelfstandige Windows-applicatie die ik nu Smart Home Cinema – Voice Control noem. Maar het interessante deel kwam eerder dan de applicatie zelf. In het begin bleef ik tegen de gebruikelijke ideeën aanlopen: afspeellijsten, metadata, bijhouden van bekeken status, bibliotheeklogica, alle normale dingen die je van een media-app zou verwachten. Maar dat was niet echt wat ik probeerde te bouwen. Ik probeerde geen hele mediabibliotheek te beheren. Ik wilde gewoon een paar spraakopdrachten die op een eenvoudige, betrouwbare manier werkten met lokale bestanden. Dus begon ik het probleem vanuit een andere invalshoek te bekijken. Wat als het systeem de hele map helemaal niet hoefde te begrijpen? Wat als het gewoon het eerste videobestand gebruikte dat het daar vond? Wat als Afspelen Film, Volgende Film en de rest allemaal diezelfde regel volgden? Hoe meer ik erover nadacht, hoe logischer die aanpak werd. Het was eenvoudig, zichtbaar en gemakkelijker te vertrouwen. Hoe meer lagen ik toevoegde – afspeellijsten, metadata, tracking, bibliotheeklogica – hoe meer plaatsen er waren waar dingen mis konden gaan. Ik wilde iets voorspelbaarders, met minder bewegende delen. Dat idee werd uiteindelijk de basis voor het hele systeem. Later begon ik het de te noemen. First File Rule Het systeem werkt altijd op het eerste videobestand in de map Films. Dat betekent dat de map zelf de wachtrij wordt. De First File Rule In C++ was de kernlogica uiteindelijk erg klein: // conceptueel voorbeeld std::string GetFirstMovie(const std::string& folder) { auto files = ListFiles(folder); for (auto& file : files) { if (IsSupportedVideo(file)) return file; } return ""; } Dit is een vereenvoudigde versie – de werkelijke implementatie bevat extra controles en afhandeling van randgevallen. Het lijkt triviaal, maar die kleine functie droeg uiteindelijk veel van het systeem. Ik had de interne afspeelstatus niet nodig. Ik had geen database nodig. Ik hoefde geen bibliotheekweergave te synchroniseren met het bestandssysteem. Het bestandssysteem zelf werd de bron van waarheid. Die ene beslissing vormde bijna al het andere. Het werkte ook natuurlijk voor tv-afleveringen, omdat afleveringen meestal al op bestandsnaam worden gesorteerd. En als ik een aangepaste volgorde voor films wilde, kon ik de bestandsnamen numeriek voorvoegen en dezelfde regel de rest laten doen. De Eerste Werkende Pipeline Ik had al een Amazon Alexa-speaker en TriggerCMD op mijn pc geïnstalleerd voor niet-gerelateerde lichtgewicht automatiseringen. Dus de eerste weergave-pipeline was duidelijk genoeg: Alexa → TriggerCMD → lokale BAT/PS1-script → mediaspeler Op dat punt probeerde ik geen product te bouwen. Ik probeerde zeer specifieke ergernissen uit mijn eigen opstelling te verwijderen. De eerste commando's waren zo minimaal mogelijk: Speel Film Af Pauzeer Film Stop Film Dat was genoeg om het concept te bewijzen. Destijds gebruikte ik voornamelijk PotPlayer, dus de eerste generatie van het systeem was eromheen gebouwd. En daar verscheen het eerste echte technische probleem. De Eerste Generatie Was Script-Gebaseerd Voordat ik iets in C++ herbouwde, werkte het systeem al als een verzameling BAT- en PowerShell-scripts. Dat is belangrijk omdat de architectuur niet in C++ begon. C++ kwam later. Zelfs de scriptversie deed al echt werk: het selecteren van de huidige film, het verplaatsen van bekeken bestanden uit de actieve map, het afhandelen van aangrenzende ondertitels, het starten van de speler en het starten van de overgang naar het volgende bestand. Dus als ik zeg dat het project klein begon, bedoel ik niet dat het slechts een ruwe mockup was. Het was al bruikbaar. Bijvoorbeeld, in de vroege PowerShell-versie van Next Movie, leek de kernlogica al zo: # conceptueel voorbeeld # huidige film ophalen $current = Get-FirstVideoFile $moviesFolder # film verplaatsen naar bekeken map Move-File $current $watchedFolder # bijpassende ondertitels verplaatsen Move-MatchingSubtitles $current $moviesFolder $watchedFolder # volgende film ophalen $next = Get-FirstVideoFile $moviesFolder Dit was geen elegante code, maar het vatte het kern gedrag van het systeem al samen. Het basisidee – het selecteren van het eerste bestand, het verplaatsen ervan en doorgaan – werkte vanaf het begin. De map bevond zich al in de wachtrij. De overgangslogica was al bestandsgestuurd. En Next Movie was al meer dan een filmoperatie. Het was al een weergave-overgang gebouwd op hetzelfde statusmodel. PotPlayer Had Geen Lokale API Die Ik Kon Gebruiken Met PotPlayer had ik geen schone lokale HTTP-besturingslaag zoals die VLC blootlegt. Dus de eerste generatie moest vertrouwen op: gesimuleerde toetsenbordinvoer actieve vensterdetectie focusbeheer tijdsvertragingen In het begin klinkt dat beheersbaar. Een toets drukken. Klaar. In de praktijk was dat niet het probleem. Het probleem was ervoor te zorgen dat PotPlayer daadwerkelijk het venster was dat de toets ontving. Dat dreef me ertoe om hulplogica te schrijven rond vensterontdekking en focusbeheer. In de C++-versie zag het vinden van het PotPlayer-venster er zo uit: HWND FindPotPlayerWindow() { // door top-level vensters itereren // PotPlayer-venster identificeren op basis van titel of klasse return hwndPotPlayer; } Daarna moest ik dat venster naar de voorgrond forceren: bool BringToForeground(HWND hwnd) { if (!IsWindow(hwnd)) return false; // invoerthreads koppelen indien nodig // venster herstellen indien geminimaliseerd // venster naar voren brengen en activeren return true; } Pas daarna kon ik veilig een toets drukken: void SendPotPlayerKey(WORD vk) { HWND hPot = FindPotPlayerWindow(); if (!hPot) return; BringToForeground(hPot); // korte vertraging om te zorgen dat focus wordt toegepast SendKeystroke(vk); } Ik dacht dat het interessante deel de stemlaag zou zijn. Dat was het niet. Een van de eerste echt vervelende problemen was gewoon om Windows focusgedrag betrouwbaar genoeg te maken zodat een spraakopdracht niet stilzwijgend niets deed of naar de verkeerde plaats ging. Dat was een van de eerste momenten waarop dit ophield te voelen als “een paar scripts” en begon te voelen als echte Windows-automatiseringstechniek. Deterministische Weergave Zonder Afspeellijsten Nadat de First File Rule bestond, verscheen er onmiddellijk een ander probleem. Als de huidige film in de map blijft, zal Play Movie steeds hetzelfde bestand opnieuw openen. Dus ik eindigde met twee verschillende manieren om met het huidige bestand om te gaan. 1. Film Verwijderen Als ik klaar was met een film en deze niet meer in de actieve map wilde hebben, zou het commando de film en zijn aangrenzende ondertitelbestanden verwijderen. In het begin maakte ik er een permanente verwijdering van. Dat was een slechte zet. Het werkte, maar het was te agressief. Een spraakopdracht is niet de juiste plek om achteloos om te gaan met onomkeerbare verwijdering. Dus veranderde ik de implementatie om bestanden naar de Prullenbak te verplaatsen. Dat maakte het gedrag veel veiliger zonder de algehele architectuur te veranderen. 2. Volgende Film Soms wilde ik de film behouden, niet verwijderen. Dus voegde ik een tweede commando toe: . Volgende Film In plaats van het huidige bestand te verwijderen, verplaatst het: de huidige film de bijbehorende ondertitels naar een tweede map, zoals Bekeken Films. Maar dat is slechts een deel van wat het commando werkelijk doet. Het werkelijke doel is om een soepele overgang naar het volgende item te creëren. Zodra de huidige film de map Films verlaat, wordt het volgende bestand automatisch het eerste bestand. Het systeem start dat bestand dan onmiddellijk. Dus Next Movie is niet zomaar een bestandsbeheercommando. Het is echt een weergave-overgangscommando gebouwd bovenop de First File Rule. Er is geen wachtrij om bij te werken. Er is geen “nu aan het spelen” index om te onderhouden. Er is geen database met bekeken status om later te repareren. Het systeem verwijdert het huidige item, laat het volgende bestand het eerste worden en start de weergave. Daarom bleek deze regel veel nuttiger dan ik had verwacht. Het vereenvoudigde niet alleen de selectie. Het vereenvoudigde ook overgangen. Van Enkele Commando's tot een Werkelijke Kijkworkflow Nadat de eerste weergavecommando's stabiel waren, stopte ik met denken in geïsoleerde acties en begon ik na te denken in termen van een volledige kijksessie. Dat leidde tot commando's zoals: Pauzeer Film Stop Film Vooruit 30 Seconden Vooruit 1 Minuut Vooruit 2 Minuten Achteruit 30 Seconden Achteruit 1 Minuut Achteruit 2 Minuten Ik heb die sprongen bewust vastgehouden. Ik probeerde niet elke mogelijke speleractie via stem bloot te leggen. Ik wilde gewoon de commando's die de meest voorkomende redenen om terug te gaan naar de pc wegnamen. Een ander klein commando bleek in de praktijk verrassend nuttig: . Meestal wordt de computer normaal gebruikt op de hoofdmonitor. Maar als het tijd is om een film te kijken, moet de ervaring naar de televisie verhuizen. In plaats van handmatig de weergave-uitvoer te wisselen en dan de weergave te starten, doet dit commando beide stappen tegelijk. Het schakelt de actieve weergave naar de tv en start de film direct op volledig scherm. Technisch gezien is het een kleine functie, maar in reëel gebruik verwijdert het nog een klein stukje frictie tussen het zitten achter de computer en het starten van een filmsessie vanaf de bank of vanuit bed. Speel Film Tv Toen werd één commando geleidelijk belangrijker dan de rest. Het Stop Alles Commando Dit commando kwam voort uit een zeer specifieke real-life ergernis. Kijken vanuit bed is gemakkelijk. De sessie beëindigen is waar de frictie terugkomt. Als ik al half sliep, was het laatste wat ik wilde, uit bed komen, naar de computer lopen, de speler stoppen, het scherm terug verplaatsen van de tv naar de monitor, de pc uitschakelen en dan weer terug in bed kruipen. Dat klinkt misschien klein. Voor mij was het dat niet. Als ik al slaperig werd, was zelfs die korte onderbreking genoeg om het moment te doorbreken. Ik heb dit commando gebouwd omdat ik wilde dat de filmsessie net zo schoon eindigde als hij begon. Dus maakte ik één commando dat de hele afsluitingssequentie in volgorde uitvoert. In de VLC-editie is de logica in principe: // conceptueel voorbeeld void StopEverythingVlc(const Config& cfg) { StopPlayback(); RestoreDisplayOutput(); // wachten tot het systeem is ingesteld WaitShortDelay(); ShutdownSystem(); } Technisch gezien is dit niet de meest ingewikkelde functie in het systeem. Wat telt is wat het verwijdert. Het verwijdert de frictie aan het einde van de sessie: stop weergave, herstel het normale weergavepad, wacht tot de overgang is voltooid, en schakel dan de machine uit. Voor mij bleek dit een van de nuttigste commando's in het hele systeem te zijn, niet omdat het technisch indrukwekkend was, maar omdat het een zeer menselijke ergernis netjes oploste. Ondertitels Werd een Eigen Probleem Weergavecontrole bleek slechts de helft van het probleem. Ondertitels werden bijna per ongeluk een tweede technische baan. Fase 1: Subliminaal Mijn eerste ondertitelautomatisering gebruikte Subliminal met de oudere OpenSubtitles API. Het werkte inderdaad. Het probleem was niet dat het onmiddellijk faalde. Het probleem was dat ik er op de lange termijn geen vertrouwen in had. Het afhankelijkheidspad voelde al te fragiel, en ik wilde niet dat de ondertitelondersteuning later stilzwijgend zou verslechteren. Dus verving ik het. Fase 2: OpenSubtitles API v2 Ik stapte over op mijn eigen ondertitelophalingslogica, geïntegreerd met OpenSubtitles API v2. Hun huidige REST API is gedocumenteerd rond login/authenticatie, token-gebaseerde toegang en speciale eindpunten voor zoeken en downloaden, wat het een veel betere langetermijnoplossing maakte dan de oudere workflow. In mijn code werd de downloadstap uiteindelijk een expliciete commando-pipeline, ruwweg als volgt: // conceptueel voorbeeld std::string cmd = BuildSubtitleCommand( pythonPath, scriptPath, moviesFolder, credentials ); if (!ExecuteCommand(cmd)) { Log("Subtitle download failed"); return; } Dat werd de stap . Download Ondertitels De matching-logica veranderde een paar keer. Wat belangrijker was, was dat ik was overgestapt van een laag die ik niet volledig vertrouwde naar een API-pad waar ik daadwerkelijk over kon redeneren. Fase 3: Synchronisatie Ondertitels Toen liep ik tegen het volgende praktische probleem aan. Soms is de ondertitel de juiste ondertitel, maar is de timing verkeerd. In het begin loste ik dit handmatig op met een GUI-synchronisatietool. Dat was bruikbaar, maar het verbrak het hele doel van het project. Als ik nog steeds bestanden in een venster moest slepen en de timing handmatig moest corrigeren, had ik de workflow niet echt geautomatiseerd. Dus schakelde ik over op ffsubsync via CLI en bouwde er een batch synchronisatiecommando omheen. In de C++-versie zag de kernlus er zo uit: // conceptueel voorbeeld std::string cmd = BuildSubtitleSyncCommand( videoPath, subtitlePath, outputPath ); bool ok = ExecuteCommand(cmd); Dat veranderde ondertitel synchronisatie van een handmatige reparatiestap naar een batchoperatie. Fase 4: Opruimen Ondertitels Na synchronisatie gebruikte het gecorrigeerde ondertitelbestand een gewijzigde suffix zoals . _2.srt Dat creëerde nog een praktisch probleem: de speler zou het gesynchroniseerde bestand niet automatisch verkiezen, tenzij de bestandsnaam werd genormaliseerd naar de verwachte standaardvorm. Dus voegde ik een derde ondertitelcommando toe: Ondertitels Opschonen De taak was om: een back-upmap te maken originele ondertitels daarheen te verplaatsen gesynchroniseerde ondertitels terug te hernoemen naar de standaard bestandsnaam .srt De hernoemstap zag er zo uit: // conceptueel voorbeeld std::string newStem = RemoveSyncSuffix(originalName); fs::path newPath = moviesPath / (newStem + ".srt"); if (FileExists(newPath)) { ReplaceFile(originalPath, newPath); } Op dat punt waren ondertitels een volledige pipeline geworden: Download → Synchroniseren → Opschonen Ik had dit sub-systeem niet van tevoren gepland. Het groeide omdat reëel gebruik steeds nieuwe frictiepunten blootlegde. Waarom ik een Volledig Scherm Commando Referentie Heb Toegevoegd Naarmate het aantal commando's groeide, verscheen er een ander soort probleem. Het systeem kon perfect werken en toch onhandig zijn als de commando's zelf moeilijk te onthouden waren. Ik voegde geleidelijk meer stemacties toe, maar er was geen eenvoudige manier om ze allemaal op één plek te zien. Dus voegde ik een overlay met een volledige commandoreferentie toe. Het doel was niet presentatie. Het was praktische bruikbaarheid. De workflow werd: pauzeer de film zeg Toon Commando's geef de beschikbare commando's weer op volledig scherm controleer degene die ik nodig heb zeg Sluit Commando's ga verder met kijken Dit loste geen technische bottleneck op. Het loste een geheugen bottleneck op. In code was het starten van de overlay eenvoudig: bool ShowCommandCenterOverlay() { std::string overlayExe = GetOverlaysDir() + "CommandCenterOverlay.exe"; return RunExe("\"" + overlayExe + "\""); } Kleine functie, grote impact op bruikbaarheid. Wat ik Later Besefte Over de Assistent Laag Ik heb het systeem oorspronkelijk rond Alexa gebouwd om één eenvoudige reden: dat was de assistent hardware die ik al thuis had. Dus in het begin dacht ik er natuurlijk aan als een Alexa-gebaseerde opstelling. Veel later, nadat de architectuur al werkte, realiseerde ik me dat Alexa niet echt de belangrijke afhankelijkheid was. De belangrijke afhankelijkheid was de triggerbrug. Zodra de assistent een commando naar TriggerCMD stuurt, is de rest van het systeem lokaal: script of uitvoerbaar bestand, bestandssysteemlogica, spelerbesturing, ondertitelworkflow, weergaveschakeling en afsluitingsflow. Dat betekent dat de architectuur fundamenteel niet gebonden is aan Alexa. Hetzelfde systeem kan net zo goed werken met Google Assistant of Google Nest, omdat beide alleen fungeren als triggerlagen voor hetzelfde lokale uitvoeringspad. Dat was het moment waarop ik besefte dat de assistent vervangbaar was. De lokale logica was de echte kern. Waar VLC de Architectuur Veranderde Later creëerde ik een tweede editie van het systeem voor VLC. Dat veranderde de architectuur meer dan ik had verwacht. Met PotPlayer moest ik vertrouwen op: vensterfocus gesimuleerde toetsen UI-gedrag Met VLC kon ik een lokale HTTP-besturingsinterface inschakelen bij het opstarten en die gebruiken als een veel schonere besturingslaag. VLC starten met HTTP ingeschakeld zag er zo uit: // conceptueel voorbeeld std::string cmd = BuildVlcLaunchCommand( vlcPath, moviePath, httpConfig ); Dat ene verschil veranderde de architectuur meer dan ik had verwacht. Nu kon ik commando's direct sturen: // conceptueel voorbeeld bool SendVlcCommand(const VlcConfig& cfg, const std::string& command) { std::string request = BuildVlcRequest(command); return SendHttpRequest(cfg, request); } En de weergave pauzeren met iets eenvoudigs als: VlcSendCommand(vc, "pl_pause"); Dat was veel schoner dan gesimuleerde toetsaanslagen. Het maakte ook statusrapportage veel gemakkelijker, wat belangrijk was voor voortgangsoverlays en andere feedbackmechanismen. Waar Automatisering Faalde: Voortgangsweergave in PotPlayer Een van de meest nuttige commando's die ik wilde, was een manier om te laten zien hoeveel van de film was verstreken en hoeveel er nog over was. Voor PotPlayer probeerde ik dat eerst precies op te lossen met: OCR Tesseract schermregio lezen Ik kreeg het werkend op mijn eigen machine. Maar ik kon het niet betrouwbaar genoeg maken voor verschillende: resoluties monitorlay-outs tv-opstellingen UI-schaalcondities Dat was een belangrijke les. Een oplossing die op één machine werkt, is niet automatisch iets dat je netjes kunt generaliseren. Dus voor PotPlayer liet ik het idee van een volledig universele OCR-gebaseerde oplossing vallen en hield ik een eenvoudigere fallback: de native voortgangsbalk onthullen en de gebruiker de positie visueel laten schatten. Voor VLC was het verhaal anders. Daar kon ik de weergavestatus direct opvragen en mijn eigen overlay renderen met interne tijdwaarden. Dat verschil is precies waarom ik niet probeerde beide spelers in een valse uniforme abstractie te dwingen. Waarom ik Alles in C++ Heb Opnieuw Gebouwd De BAT- en PowerShell-generatie van het systeem was echt. Het werkte. Ik beschouw die versie nog steeds als functioneel geldig. Maar ik wilde het project niet voor altijd op dat niveau houden. Het was te afhankelijk van scriptniveau gedrag, machine-specifieke toleranties en losjes verbonden delen. Ik wilde: betere structuur sterkere Windows-integratie native overlays gecentraliseerde configuratiebehandeling nettere logging een voorspelbaardere, uitvoerbare architectuur Dus heb ik het systeem in C++ opnieuw gebouwd. De architectuur bleef hetzelfde. De implementatie werd gedisciplineerder. Dat deed ik niet omdat de scriptversie waardeloos was. Ik deed het omdat de kerngedachten waardevol genoeg waren geworden dat ik niet langer wilde dat ze bij elkaar werden gehouden door een hoop scripts en aannames. Dat was het punt waarop het project begon te voelen als een echte Windows-applicatie in plaats van een nuttig automatiseringsexperiment. Wat ik Geleerd Heb De grootste les van dit project is dat stembediening nooit het echte moeilijke probleem was. Het moeilijke probleem was het bouwen van een lokaal weergavemodel dat niet zou instorten in: verborgen status fragiele UI-aannames afspeellijstdrift synchronisatiefouten De loste meer op dan ik had verwacht. First File Rule Het verwijderde een hele klasse van problemen omdat de mapstructuur zelf de toestandsmachine werd. De andere les is dat lokaal-eerst ontwerp alleen belangrijk is als het echte frictie wegneemt. In dit systeem betekende lokaal-eerst: bestanden blijven lokaal weergave blijft lokaal logica blijft lokaal alleen het triggerpad is afhankelijk van de assistent/bruglaag Dat was genoeg om de ervaring te creëren die ik oorspronkelijk wilde: een Windows-pc aangesloten op een tv die meer aanvoelt als een eenvoudige thuisbioscoop en minder als een werkstation waar ik steeds naar terug moet lopen.