Jag byggde en röststyrd hemmabio för Windows för att jag var trött på att resa mig för att pausa filmer

Jag byggde inte detta för att jag ville ha en "smart underhållningsplattform". Jag byggde det för att jag var trött på att behöva resa mig upp. Min installation var enkel: en Windows-dator ansluten till en TV via HDMI, lokala filmfiler och en vanlig mediaspelare. Ingen streaming. Ingen medieserver. Ingen molnsynkronisering. Bara filer på disk och direktuppspelning. Den delen var okej. Den irriterande delen började efter att filmen hade börjat. Pausa filmen? Räcka efter tangentbordet. Hoppa framåt? Samma sak. Behöver undertexter? Tillbaka till datorn. Vill du ha nästa avsnitt? Tillbaka igen. Den verkliga friktionen kom från något väldigt enkelt. När du tittar på film från sängen, innebär varje paus, hopp eller nästa kommando att du måste resa dig, gå till datorn, använda tangentbordet och sedan gå tillbaka igen. Uppspelningen i sig var enkel – bara lokala filer och en mediaspelare – men upplevelsen runt den fungerade fortfarande som på en stationär dator. Det kändes inte som en hemmabio. Naturligtvis finns det befintliga sätt att hantera detta. Trådlösa tangentbord, luftmöss och fjärrkontrollappar kan alla hjälpa till. Men de behandlar fortfarande upplevelsen som att man använder en dator. Du flyttar fortfarande en muspekare, navigerar i menyer eller trycker på tangenter – interagerar med programvara istället för att bara titta på filmen. I en verklig bioupplevelse försvinner tekniken. Du fokuserar på filmen, inte på gränssnittet. Så jag började med en mycket praktisk fråga: Kan en Windows-dator ansluten till en TV vara mindre irriterande att styra från andra sidan rummet? Den frågan växte så småningom till ett fristående Windows-program som jag nu kallar Smart Home Cinema – Voice Control. Men den intressanta delen kom tidigare än själva programmet. Först stötte jag ständigt på de vanliga idéerna: spellistor, metadata, spårning av sedda filer, bibliotekslogik, allt det normala du kan förvänta dig i en medieapp. Men det var inte riktigt det jag försökte bygga. Jag försökte inte hantera ett helt mediefilbibliotek. Jag ville bara ha några röstkommandon som skulle fungera på ett enkelt, tillförlitligt sätt med lokala filer. Så jag började titta på problemet från en annan vinkel. Tänk om systemet inte behövde förstå hela mappen alls? Tänk om det bara använde den första videofil det hittade där? Tänk om Spela film, Nästa film och resten följde samma regel? Ju mer jag tänkte på det, desto mer logiskt verkade det tillvägagångssättet. Det var enkelt, synligt och lättare att lita på. Ju fler lager jag lade till – spellistor, metadata, spårning, bibliotekslogik – desto fler ställen fanns det för saker att gå fel. Jag ville ha något mer förutsägbart, med färre rörliga delar. Den idén blev så småningom grunden för hela systemet. Senare började jag kalla det (Första filregeln). First File Rule Systemet arbetar alltid med den första videofilen i mappen Movies. Det betyder att själva mappen blir kön. Första filregeln I C++ blev den centrala logiken till slut väldigt liten: // konceptuellt exempel std::string GetFirstMovie(const std::string& folder) { auto files = ListFiles(folder); for (auto& file : files) { if (IsSupportedVideo(file)) return file; } return ""; } Det här är en förenklad version – den faktiska implementeringen inkluderar ytterligare kontroller och hantering av specialfall. Det ser trivialt ut, men den lilla funktionen kom att bära mycket av systemet. Jag behövde inte det interna uppspelningsläget. Jag behövde inte en databas. Jag behövde inte synkronisera en biblioteksvy med filsystemet. Själva filsystemet blev sanningskällan. Det enda beslutet formade nästan allt annat. Det fungerade också naturligt för TV-avsnitt, eftersom avsnitt oftast redan är ordnade efter filnamn. Och om jag ville ha en anpassad ordning för filmer kunde jag helt enkelt numrera filnamnen numeriskt och låta samma regel göra resten. Den första fungerande pipeline Jag hade redan en Amazon Alexa-högtalare och TriggerCMD installerat på min dator för andra, mindre viktiga automatiseringar. Så den första uppspelningspipelinen var tillräckligt uppenbar: Alexa → TriggerCMD → lokal BAT/PS1-skript → mediaspelare Vid den tidpunkten försökte jag inte bygga en produkt. Jag försökte ta bort mycket specifika irritationer från min egen installation. De första kommandona var så minimala som möjligt: Spela film Pausa film Stoppa film Det räckte för att bevisa konceptet. På den tiden använde jag främst PotPlayer, så den första generationen av systemet byggdes kring det. Och det var där det första verkliga ingenjörsproblemet dök upp. Den första generationen var skriptbaserad Innan jag byggde om något i C++, fungerade systemet redan som en samling av BAT- och PowerShell-skript. Det spelar roll eftersom arkitekturen inte började i C++. C++ kom senare. Även skriptversionen utförde redan verkligt arbete: valde den aktuella filmen, flyttade sedda filer ur den aktiva mappen, hanterade intilliggande undertexter, startade spelaren och inledde övergången till nästa fil. Så när jag säger att projektet började i liten skala, menar jag inte att det bara var en grov skiss. Det var redan användbart. Till exempel, i den tidiga PowerShell-versionen av Nästa film, såg kärnlogiken ut ungefär så här: # konceptuellt exempel # hämta aktuell film $current = Get-FirstVideoFile $moviesFolder # flytta filmen till sedda mappen Move-File $current $watchedFolder # flytta matchande undertexter Move-MatchingSubtitles $current $moviesFolder $watchedFolder # hämta nästa film $next = Get-FirstVideoFile $moviesFolder Det var inte elegant kod, men den fångade redan systemets kärnbeteende. Den grundläggande idén – att välja den första filen, flytta den och fortsätta – fungerade från allra första början. Mappen var redan i kön. Övergångslogiken var redan filbaserad. Och Nästa film var redan mer än en filmoperation. Det var redan en uppspelningsövergång byggd på samma tillståndsmodell. PotPlayer hade ingen lokal API som jag kunde använda Med PotPlayer hade jag inget rent lokalt HTTP-kontrollager som VLC erbjuder. Så den första generationen var tvungen att förlita sig på: simulerad tangentbordinmatning detektering av aktivt fönster fokusstyrning tidsfördröjningar Till en början låter det hanterbart. Skicka en tangent. Klart. I praktiken var det inte problemet. Problemet var att säkerställa att PotPlayer faktiskt var fönstret som tog emot tangenttryckningen. Det tvingade mig att skriva hjälpfunktionslogik kring fönsterupptäckt och fokushantering. I C++-versionen såg det ut så här att hitta PotPlayer-fönstret: HWND FindPotPlayerWindow() { // iterera genom toppnivåfönster // identifiera PotPlayer-fönster baserat på titel eller klass return hwndPotPlayer; } Sedan var jag tvungen att tvinga det fönstret till förgrunden: bool BringToForeground(HWND hwnd) { if (!IsWindow(hwnd)) return false; // koppla inmatningstrådar om nödvändigt // återställ fönster om minimerat // för fönstret till förgrunden och aktivera det return true; } Först efter det kunde jag säkert skicka en tangent: void SendPotPlayerKey(WORD vk) { HWND hPot = FindPotPlayerWindow(); if (!hPot) return; BringToForeground(hPot); // liten fördröjning för att säkerställa att fokus har applicerats SendKeystroke(vk); } Jag trodde att den intressanta delen skulle vara röstlagret. Det var det inte. Ett av de första riktigt irriterande problemen var bara att få Windows fokusbeteende att vara tillräckligt pålitligt för att ett röstkommando inte tyst skulle göra ingenting eller gå till fel plats. Det var ett av de första ögonblicken då detta slutade kännas som "ett fåtal skript" och började kännas som verklig Windows-automatiseringsingenjörskonst. Determinisk uppspelning utan spellistor När First File Rule väl fanns, dök ett annat problem upp omedelbart. Om den aktuella filmen stannar kvar i mappen, kommer Play Movie bara att öppna samma fil i evighet. Så jag hamnade med två olika sätt att hantera den aktuella filen. 1. Radera film Om jag var klar med en film och inte ville ha den kvar i den aktiva mappen längre, skulle kommandot ta bort filmen och dess intilliggande undertextfiler. Först gjorde jag det till en permanent radering. Det var ett dåligt beslut. Det fungerade, men det var för aggressivt. Ett röstkommando är fel plats att vara nonchalant med oåterkallelig radering. Så jag ändrade implementeringen till att istället flytta filer till papperskorgen. Det gjorde beteendet mycket säkrare utan att ändra den övergripande arkitekturen. 2. Nästa film Ibland ville jag behålla filmen, inte radera den. Så jag lade till ett andra kommando: . Nästa film Istället för att radera den aktuella filen, flyttar det: den aktuella filmen dess associerade undertexter till en andra mapp, till exempel "Watched Movies" (Sedda filmer). Men det är bara en del av vad kommandot faktiskt gör. Dess faktiska syfte är att skapa en smidig övergång till nästa objekt. När den aktuella filmen lämnar mappen Movies, blir nästa fil automatiskt den första filen. Systemet startar sedan den filen omedelbart. Så Nästa film är inte bara ett filhanteringskommando. Det är verkligen ett uppspelningsövergångskommando byggt ovanpå Första filregeln. Det finns ingen kö att uppdatera. Det finns ingen "spelas nu"-index att underhålla. Det finns ingen databas för sedda filer att fixa senare. Systemet tar bort det aktuella objektet, låter nästa fil bli den första och startar uppspelningen. Det är därför den här regeln visade sig vara mycket mer användbar än jag förväntade mig. Den förenklade inte bara urvalet. Den förenklade också övergångarna. Från enstaka kommandon till en faktisk tittararbetsflöde När de första uppspelningskommandona var stabila, slutade jag tänka i isolerade handlingar och började tänka i termer av en hel tittarsession. Det ledde till kommandon som: Pausa film Stoppa film Framåt 30 sekunder Framåt 1 minut Framåt 2 minuter Bakåt 30 sekunder Bakåt 1 minut Bakåt 2 minuter Jag höll medvetet dessa hopp fasta. Jag försökte inte exponera varje möjlig spelaråtgärd via röst. Jag ville bara ha de kommandon som tog bort de vanligaste anledningarna att gå tillbaka till datorn. Ett annat litet kommando visade sig vara förvånansvärt användbart i praktiken: . Mestadels används datorn normalt på sin huvudskärm. Men när det är dags att titta på en film, bör upplevelsen flyttas till TV:n. Istället för att manuellt byta skärmutgång och sedan starta uppspelningen, gör detta kommando båda stegen samtidigt. Det byter den aktiva skärmen till TV:n och startar filmen direkt i helskärmsläge. Tekniskt sett är det en liten funktion, men i verklig användning tar det bort ytterligare en liten bit friktion mellan att sitta vid datorn och starta en film från soffan eller sängen. Spela film TV Sedan blev ett kommando gradvis viktigare än de andra. Kommandot "Stoppa allt" Det här kommandot kom från en mycket specifik verklig irritation. Att titta från sängen är lätt. Att avsluta sessionen är där friktionen kommer tillbaka. Om jag redan var halvsovande, var det sista jag ville göra att kliva ur sängen, gå till datorn, stoppa spelaren, flytta skärmen tillbaka från TV:n till monitorn, stänga av datorn och sedan gå och lägga mig igen. Det kan låta obetydligt. För mig var det inte det. Om jag redan höll på att bli sömnig, var även den korta avbrottet tillräckligt för att bryta ögonblicket. Jag byggde det här kommandot för att jag ville att filmpasset skulle sluta lika rent som det började. Så jag skapade ett enda kommando som utför hela avstängningssekvensen i ordning. I VLC-utgåvan är logiken i princip: // konceptuellt exempel void StopEverythingVlc(const Config& cfg) { StopPlayback(); RestoreDisplayOutput(); // vänta tills systemet har stabiliserats WaitShortDelay(); ShutdownSystem(); } Tekniskt sett är detta inte den mest komplicerade funktionen i systemet. Det som spelar roll är vad den tar bort. Den tar bort friktionen i slutet av sessionen: stoppa uppspelningen, återställ den normala skärmvägen, vänta tills bytet har stabiliserats, och stäng sedan av maskinen. För mig visade sig detta vara ett av de mest användbara kommandona i hela systemet, inte för att det var tekniskt imponerande, utan för att det löste en väldigt mänsklig irritation på ett rent sätt. Undertexter blev ett eget problem Uppspelningskontroll visade sig bara vara halva problemet. Undertexter blev ett andra ingenjörsspår nästan av misstag. Steg 1: Subliminal Min första undertextautomatisering använde Subliminal med den äldre OpenSubtitles API:n. Det fungerade faktiskt. Problemet var inte att det misslyckades omedelbart. Problemet var att jag inte litade på det på lång sikt. Beroendestigen kändes redan för bräcklig, och jag ville inte att undertextstödet tyst skulle försämras senare. Så jag ersatte det. Steg 2: OpenSubtitles API v2 Jag gick över till min egen logik för att hämta undertexter integrerad med OpenSubtitles API v2. Deras nuvarande REST API är dokumenterat kring inloggning/autentisering, tokenbaserad åtkomst och dedikerade slutpunkter för sökning och nedladdning, vilket gjorde det till en mycket bättre långsiktig lösning än det äldre flödet. I min kod blev nedladdningssteget till slut en explicit kommandopipeline, ungefär så här: // konceptuellt exempel std::string cmd = BuildSubtitleCommand( pythonPath, scriptPath, moviesFolder, credentials ); if (!ExecuteCommand(cmd)) { Log("Subtitle download failed"); return; } Det blev steget . Ladda ner undertexter Matchningslogiken ändrades några gånger. Det som var viktigare var att jag hade gått från ett lager som jag inte helt litade på till en API-väg som jag faktiskt kunde resonera kring. Steg 3: Synkronisera undertexter Sedan stötte jag på nästa praktiska problem. Ibland är undertexten den rätta undertexten, men tidpunkten är fel. Först hanterade jag detta manuellt med ett GUI-synkroniseringsverktyg. Det var användbart, men det bröt hela syftet med projektet. Om jag fortfarande var tvungen att dra filer till ett fönster och fixa tidpunkter för hand, hade jag inte riktigt automatiserat arbetsflödet. Så jag bytte till ffsubsync via CLI och byggde ett batch-synkroniseringskommando runt det. I C++-versionen såg kärnloopen ut ungefär så här: // konceptuellt exempel std::string cmd = BuildSubtitleSyncCommand( videoPath, subtitlePath, outputPath ); bool ok = ExecuteCommand(cmd); Det förändrade undertextsynkronisering från ett manuellt reparationssteg till en batchoperation. Steg 4: Rensa undertexter Efter synkronisering använde den korrigerade undertextfilen en modifierad suffix som . _2.srt Det skapade ett annat praktiskt problem: spelaren skulle inte automatiskt föredra den synkroniserade filen om inte filnamnet normaliserades tillbaka till standardformen. Så jag lade till ett tredje undertextkommando: Rensa undertexter Dess uppgift var att: skapa en backup-mapp flytta originalundertexterna dit döpa om synkroniserade undertexter tillbaka till standardfilnamnet .srt Omdöpningssteget såg ut så här: // konceptuellt exempel std::string newStem = RemoveSyncSuffix(originalName); fs::path newPath = moviesPath / (newStem + ".srt"); if (FileExists(newPath)) { ReplaceFile(originalPath, newPath); } Vid den tidpunkten hade undertexter blivit en fullständig pipeline: Ladda ner → Synkronisera → Rensa Jag planerade inte detta subsystem i förväg. Det växte för att verklig användning fortsatte att avslöja nya friktionspunkter. Varför jag lade till en helskärmskommando referens När antalet kommandon växte, dök en annan typ av problem upp. Systemet kunde fungera perfekt och ändå vara obekvämt om själva kommandona var svåra att komma ihåg. Jag lade gradvis till fler röståtgärder, men det fanns inget enkelt sätt att se dem alla på ett ställe. Så jag lade till ett helskärms overlay för kommandoreferens. Poängen var inte presentation. Det var praktisk användbarhet. Arbetsflödet blev: pausa filmen säg Visa kommandon visa tillgängliga kommandon i helskärmsläge kontrollera det jag behöver säg Stäng kommandon fortsätt titta Det här löste inte en teknisk flaskhals. Det löste en minnesflaskhals. I kod var det enkelt att starta overlayet: bool ShowCommandCenterOverlay() { std::string overlayExe = GetOverlaysDir() + "CommandCenterOverlay.exe"; return RunExe("\"" + overlayExe + "\""); } Liten funktion, stor användbarhetspåverkan. Vad jag senare insåg om assistanslagret Jag byggde ursprungligen systemet runt Alexa av en enkel anledning: det var den assistanshårdvara jag redan hade hemma. Så till en början tänkte jag naturligtvis på det som en Alexa-baserad installation. Mycket senare, efter att arkitekturen redan fungerade, insåg jag att Alexa inte riktigt var den viktiga beroendet. Det viktiga beroendet var triggerbron. När assistenten skickar ett kommando till TriggerCMD, är resten av systemet lokalt: skript eller körbara filer, filsystemlogik, spelarkontroll, undertextarbetsflöde, skärmväxling och avstängningsflöde. Det betyder att arkitekturen inte fundamentalt är knuten till Alexa alls. Samma system kan fungera lika bra med Google Assistant eller Google Nest, eftersom båda bara fungerar som utlösarlager för samma lokala exekveringsväg. Det var då jag insåg att assistenten var utbytbar. Den lokala logiken var den verkliga kärnan. Där VLC ändrade arkitekturen Senare skapade jag en andra utgåva av systemet för VLC. Det ändrade arkitekturen mer än jag förväntade mig. Med PotPlayer var jag tvungen att förlita mig på: fönsterfokus simulerade tangenter UI-beteende Med VLC kunde jag aktivera ett lokalt HTTP-kontrollgränssnitt vid start och använda det som ett mycket renare kontrollager. Att starta VLC med HTTP aktiverat såg ut ungefär så här: // konceptuellt exempel std::string cmd = BuildVlcLaunchCommand( vlcPath, moviePath, httpConfig ); Den enda skillnaden ändrade arkitekturen mer än jag förväntade mig. Nu kunde jag skicka kommandon direkt: // konceptuellt exempel bool SendVlcCommand(const VlcConfig& cfg, const std::string& command) { std::string request = BuildVlcRequest(command); return SendHttpRequest(cfg, request); } Och pausa uppspelningen med något så enkelt som: VlcSendCommand(vc, "pl_pause"); Det var mycket renare än simulerade tangenttryckningar. Det gjorde också statusrapportering mycket enklare, vilket var viktigt för framstegs-overlays och andra återkopplingsmekanismer. Där automatiseringen misslyckades: Framstegsvisning i PotPlayer Ett av de mest användbara kommandona jag ville ha var ett sätt att visa hur mycket av filmen som hade passerat och hur mycket som återstod. För PotPlayer försökte jag först lösa det exakt med hjälp av: OCR Tesseract läsning av skärmregioner Jag fick det att fungera på min egen maskin. Men jag kunde inte göra det tillräckligt tillförlitligt över olika: upplösningar bildskärmslayouter TV-inställningar UI-skalningsförhållanden Det var en viktig lärdom. En lösning som fungerar på en maskin är inte automatiskt något du kan generalisera på ett rent sätt. Så för PotPlayer övergav jag idén om en helt universell OCR-baserad lösning och behöll en enklare fallback: avslöja den inbyggda progress-baren och låta användaren visuellt uppskatta positionen. För VLC var berättelsen annorlunda. Där kunde jag direkt fråga om uppspelningsstatus och rendera min egen overlay med interna tidsvärden. Den skillnaden är precis varför jag inte försökte tvinga båda spelarna till en falsk enhetlig abstraktion. Varför jag byggde om allt i C++ BAT- och PowerShell-generationen av systemet var verklig. Den fungerade. Jag betraktar fortfarande den versionen som funktionellt giltig. Men jag ville inte fortsätta projektet på den nivån för evigt. Det berodde för mycket på skriptnivåbeteende, maskinspecifika toleranser och löst sammankopplade delar. Jag ville ha: bättre struktur starkare Windows-integration inbyggda overlays centraliserad konfigurationshantering renare loggning en mer förutsägbar exekverbar arkitektur Så jag byggde om systemet i C++. Arkitekturen förblev densamma. Implementeringen blev mer disciplinerad. Jag gjorde det inte för att skriptversionen var värdelös. Jag gjorde det för att kärnidéerna hade blivit tillräckligt värdefulla för att jag inte längre ville att de skulle hållas ihop av en hög med skript och antaganden. Det var då projektet började kännas som en faktisk Windows-applikation istället för ett användbart automatiserings experiment. Vad jag lärde mig Den största lärdomen från det här projektet är att röststyrning aldrig var det verkliga svåra problemet. Det svåra problemet var att bygga en lokal uppspelningsmodell som inte skulle kollapsa till: dolt tillstånd bräckliga UI-antaganden spellistdrift synkroniseringsfel löste mer än jag förväntade mig. Första filregeln Den eliminerade en hel klass av problem eftersom mappstrukturen i sig blev tillståndsförklaringen. Den andra lärdomen är att lokal-först-design bara spelar roll när den tar bort verklig friktion. I det här systemet innebar lokal-först: filer stannar lokalt uppspelning stannar lokalt logik stannar lokalt endast utlösarvägen är beroende av assistans-/brygglagret Det räckte för att skapa den upplevelse jag faktiskt ville ha från början: en Windows-dator ansluten till en TV som beter sig mer som en enkel hemmabio och mindre som en arbetsstation jag måste gå tillbaka till.