Am construit un cinematograf de acasă controlat vocal pentru Windows pentru că m-am săturat să mă ridic să pun filmele pe pauză

Nu am construit asta pentru că îmi doream o „platformă de divertisment inteligentă”. Am construit-o pentru că eram obosit să mă ridic. Configurația mea era simplă: un PC Windows conectat la un televizor prin HDMI, fișiere video locale și un player media normal. Fără streaming. Fără server media. Fără sincronizare în cloud. Doar fișiere pe disc și redare directă. Acea parte a fost în regulă. Partea enervantă a început după ce filmul a pornit. Pauză la film? Întinde mâna spre tastatură. Sări înainte? La fel. Ai nevoie de subtitrări? Înapoi la PC. Vrei următorul episod? Înapoi din nou. Adevăratul inconvenient provenea de la ceva foarte simplu. Când privești filme din pat, fiecare pauză, salt sau comandă de următorul film înseamnă să te ridici, să mergi la computer, să folosești tastatura și apoi să te întorci din nou. Redarea în sine era simplă – doar fișiere locale și un player media – dar experiența din jurul ei se comporta în continuare ca pe un computer desktop. Nu se simțea ca un cinematograf de acasă. Desigur, există modalități existente de a gestiona acest lucru. Tastaturile wireless, mouse-urile aeriene și aplicațiile de control de la distanță pot ajuta. Dar acestea tratează în continuare experiența ca pe operarea unui computer. Încă muți un cursor, navighezi prin meniuri sau apeși taste – interacționezi cu software în loc să te uiți pur și simplu la film. Într-o experiență reală de cinematograf, tehnologia dispare. Te concentrezi pe film, nu pe interfață. Așa că am început cu o întrebare foarte practică: Ar putea un PC Windows conectat la un televizor să fie mai puțin enervant de controlat de la distanță? Acea întrebare a evoluat în cele din urmă într-o aplicație Windows independentă pe care acum o numesc Smart Home Cinema – Voice Control. Dar partea interesantă a venit mai devreme decât aplicația în sine. La început, continuam să dau peste ideile obișnuite: liste de redare, metadate, urmărirea stării de vizionare, logică de bibliotecă, toate lucrurile normale pe care te-ai aștepta să le găsești într-o aplicație media. Dar asta nu era cu adevărat ceea ce încercam să construiesc. Nu încercam să gestionez o bibliotecă media completă. Voiam doar câteva comenzi vocale care să funcționeze într-un mod simplu și fiabil cu fișiere locale. Așa că am început să privesc problema dintr-un alt unghi. Ce-ar fi dacă sistemul nu ar trebui să înțeleagă deloc întregul folder? Ce-ar fi dacă ar folosi doar primul fișier video pe care îl găsește acolo? Ce-ar fi dacă „Redare film”, „Următorul film” și restul ar urma aceeași regulă? Cu cât mă gândeam mai mult, cu atât acea abordare părea mai logică. Era simplă, vizibilă și mai ușor de crezut. Cu cât adăugam mai multe straturi – liste de redare, metadate, urmărire, logică de bibliotecă – cu atât erau mai multe locuri unde lucrurile puteau merge prost. Voiam ceva mai predictibil, cu mai puține piese în mișcare. Acea idee a devenit baza pentru întregul sistem. Mai târziu, am început să o numesc . Regula Primului Fișier Sistemul operează întotdeauna pe primul fișier video din folderul Filme. Asta înseamnă că folderul în sine devine coada. Regula Primului Fișier În C++, logica de bază a ajuns să fie foarte mică: // exemplu conceptual std::string GetFirstMovie(const std::string& folder) { auto files = ListFiles(folder); for (auto& file : files) { if (IsSupportedVideo(file)) return file; } return ""; } Aceasta este o versiune simplificată – implementarea reală include verificări suplimentare și gestionarea cazurilor limită. Pare trivială, dar acea mică funcție a ajuns să ducă o mare parte din sistem. Nu aveam nevoie de starea internă de redare. Nu aveam nevoie de o bază de date. Nu aveam nevoie să sincronizez o vizualizare a bibliotecii cu sistemul de fișiere. Sistemul de fișiere în sine a devenit sursa adevărului. Acea decizie unică a modelat aproape tot restul. A funcționat și natural pentru episoadele TV, deoarece episoadele sunt de obicei deja ordonate după nume de fișier. Și dacă doream o ordine personalizată pentru filme, puteam pur și simplu să prefixez numele fișierelor numeric și să las aceeași regulă să facă restul. Primul Pipeline Funcțional Aveam deja un difuzor Amazon Alexa și TriggerCMD instalat pe PC-ul meu pentru automatizări ușoare nelegate. Deci, primul pipeline de redare a fost suficient de evident: Alexa → TriggerCMD → script BAT/PS1 local → player media În acel moment, nu încercam să construiesc un produs. Încercam să elimin neplăceri foarte specifice din propria mea configurație. Primele comenzi au fost cât se poate de minimale: Redare film Pauză film Oprire film Asta a fost suficient pentru a demonstra conceptul. La vremea respectivă, foloseam în principal PotPlayer, așa că prima generație a sistemului a fost construită în jurul lui. Și aici a apărut prima problemă reală de inginerie. Prima generație a fost bazată pe scripturi Înainte să reconstruiesc ceva în C++, sistemul funcționa deja ca o colecție de scripturi BAT și PowerShell. Asta contează deoarece arhitectura nu a început în C++. C++ a venit mai târziu. Chiar și versiunea de script făcea deja muncă reală: selectarea filmului curent, mutarea fișierelor vizionate în afara folderului activ, gestionarea subtitrărilor adiacente, lansarea playerului și inițierea tranziției către următorul fișier. Deci, când spun că proiectul a început mic, nu vreau să spun că a fost doar un prototip brut. Era deja utilizabil. De exemplu, în versiunea timpurie PowerShell a comenzii „Următorul film”, logica de bază arăta deja așa: # exemplu conceptual # obține filmul curent $current = Get-FirstVideoFile $moviesFolder # mută filmul în folderul vizionat Move-File $current $watchedFolder # mută subtitrările corespondente Move-MatchingSubtitles $current $moviesFolder $watchedFolder # obține următorul film $next = Get-FirstVideoFile $moviesFolder Acesta nu era un cod elegant, dar capta deja comportamentul de bază al sistemului. Ideea de bază – selectarea primului fișier, mutarea acestuia și continuarea – funcționa de la început. Folderul era deja în coadă. Logica de tranziție era deja bazată pe fișiere. Și „Următorul film” era deja mai mult decât o operațiune pe un film. Era deja o tranziție de redare construită pe același model de stare. PotPlayer nu avea o API locală pe care să o pot folosi Cu PotPlayer, nu aveam un strat de control HTTP local curat, cum expune VLC. Deci, prima generație a trebuit să se bazeze pe: introducere de tastatură simulată detectarea ferestrei active controlul focusului întârzieri de temporizare La început, asta pare gestionabil. Trimite o tastă. Gata. În practică, asta nu era problema. Problema era să mă asigur că PotPlayer era, de fapt, fereastra care primea tasta. Asta m-a determinat să scriu logica ajutătoare pentru descoperirea ferestrelor și gestionarea focusului. În versiunea C++, găsirea ferestrei PotPlayer arăta așa: HWND FindPotPlayerWindow() { // iterează prin ferestrele de nivel superior // identifică fereastra PotPlayer pe baza titlului sau clasei return hwndPotPlayer; } Apoi a trebuit să forțez acea fereastră să fie în prim-plan: bool BringToForeground(HWND hwnd) { if (!IsWindow(hwnd)) return false; // atașează firele de intrare dacă este necesar // restaurează fereastra dacă este minimizată // aduce fereastra în prim-plan și o activează return true; } Abia după aceea puteam trimite în siguranță o tastă: void SendPotPlayerKey(WORD vk) { HWND hPot = FindPotPlayerWindow(); if (!hPot) return; BringToForeground(hPot); // scurtă întârziere pentru a asigura aplicarea focusului SendKeystroke(vk); } Am crezut că partea interesantă va fi stratul vocal. Nu a fost. Una dintre primele probleme cu adevărat enervante a fost doar obținerea unui comportament de focus Windows suficient de fiabil încât o comandă vocală să nu facă silențios nimic sau să meargă în locul greșit. Acesta a fost unul dintre primele momente în care asta a încetat să mai pară „câteva scripturi” și a început să pară inginerie reală de automatizare Windows. Redare deterministă fără liste de redare Odată ce Regula Primului Fișier a existat, o altă problemă a apărut imediat. Dacă filmul curent rămâne în folder, atunci „Redare film” va redeschide același fișier la nesfârșit. Așa că am ajuns să am două moduri diferite de a gestiona fișierul curent. 1. Șterge filmul Dacă terminam un film și nu voiam să mai fie în folderul activ, comanda ar șterge filmul și fișierele sale de subtitrări adiacente. La început, am făcut asta o ștergere permanentă. A fost o greșeală. A funcționat, dar a fost prea agresiv. O comandă vocală este locul greșit pentru a fi superficial cu ștergerea ireversibilă. Așa că am modificat implementarea pentru a muta fișierele în Coșul de gunoi în schimb. Asta a făcut comportamentul mult mai sigur fără a schimba arhitectura generală. 2. Următorul film Uneori voiam să păstrez filmul, nu să-l șterg. Așa că am adăugat o a doua comandă: . Următorul film În loc să șteargă fișierul curent, mută: filmul curent subtitrările sale asociate într-un al doilea folder, cum ar fi „Filme vizionate”. Dar asta este doar o parte din ceea ce face de fapt comanda. Scopul său real este de a crea o tranziție lină către următorul element. Odată ce filmul curent părăsește folderul Filme, următorul fișier devine automat primul fișier. Sistemul pornește apoi acel fișier imediat. Deci, „Următorul film” nu este doar o comandă de gestionare a fișierelor. Este, de fapt, o comandă de tranziție a redării construită peste Regula Primului Fișier. Nu există nicio coadă de actualizat. Nu există un index „acum redat” de menținut. Nu există o bază de date cu starea de vizionare de corectat ulterior. Sistemul elimină elementul curent, permite următorului fișier să devină primul și pornește redarea. De aceea, această regulă s-a dovedit a fi mult mai utilă decât mă așteptam. Nu doar că a simplificat selecția. A simplificat și tranzițiile. De la comenzi individuale la un flux de vizionare real Odată ce primele comenzi de redare au devenit stabile, am încetat să mai gândesc în acțiuni izolate și am început să mă gândesc în termeni de sesiune completă de vizionare. Asta a dus la comenzi precum: Pauză film Oprire film Înainte 30 secunde Înainte 1 minut Înainte 2 minute Înapoi 30 secunde Înapoi 1 minut Înapoi 2 minute Am păstrat în mod deliberat aceste salturi fixe. Nu încercam să expun fiecare acțiune posibilă a playerului prin voce. Voiam doar comenzile care eliminau cele mai frecvente motive pentru a reveni la PC. O altă comandă mică s-a dovedit surprinzător de utilă în practică: . De cele mai multe ori, computerul este folosit normal pe monitorul principal. Dar când vine momentul să vizionezi un film, experiența ar trebui să se mute pe televizor. În loc să comut manual ieșirea de afișare și apoi să pornesc redarea, această comandă face ambii pași simultan. Comută afișajul activ pe TV și pornește filmul direct pe ecran complet. Tehnic, este o caracteristică mică, dar în utilizare reală, elimină încă o mică parte din inconvenientul dintre a sta la computer și a începe o sesiune de film de pe canapea sau din pat. Redare Film TV Apoi, o comandă a devenit treptat mai importantă decât celelalte. Comanda „Oprește totul” Această comandă a venit dintr-un inconvenient specific din viața reală. Vizionarea din pat este ușoară. Sfârșitul sesiunii este unde inconvenientul revine. Dacă eram deja pe jumătate adormit, ultimul lucru pe care voiam să-l fac era să mă ridic din pat, să merg la computer, să opresc playerul, să mut afișajul de pe TV înapoi pe monitor, să închid PC-ul și apoi să mă întorc în pat. Asta poate suna minor. Pentru mine, nu a fost. Dacă eram deja pe cale să adorm, chiar și acea scurtă întrerupere era suficientă pentru a strica momentul. Am construit această comandă pentru că voiam ca sesiunea de vizionare a filmului să se încheie la fel de curat cum a început. Așa că am făcut o singură comandă care execută întreaga secvență de închidere în ordine. În ediția VLC, logica este practic: // exemplu conceptual void StopEverythingVlc(const Config& cfg) { StopPlayback(); RestoreDisplayOutput(); // așteaptă ca sistemul să se stabilizeze WaitShortDelay(); ShutdownSystem(); } Tehnic, aceasta nu este cea mai complicată funcție din sistem. Ceea ce contează este ceea ce elimină. Elimină inconvenientul de la sfârșitul sesiunii: oprește redarea, restaurează calea normală de afișare, așteaptă stabilizarea comutării și apoi închide mașina. Pentru mine, aceasta s-a dovedit a fi una dintre cele mai utile comenzi din întregul sistem, nu pentru că era impresionantă tehnic, ci pentru că a rezolvat un inconvenient foarte uman în mod curat. Subtitrările au devenit o problemă în sine Controlul redării s-a dovedit a fi doar jumătate din problemă. Subtitrările au devenit o a doua pistă de inginerie aproape din întâmplare. Etapa 1: Subliminal Prima mea automatizare a subtitrărilor a folosit Subliminal cu API-ul mai vechi OpenSubtitles. A funcționat, de fapt. Problema nu a fost că a eșuat imediat. Problema a fost că nu am avut încredere în ea pe termen lung. Calea de dependență se simțea deja prea fragilă și nu voiam ca suportul pentru subtitrări să se degradeze încet mai târziu. Așa că am înlocuit-o. Etapa 2: API OpenSubtitles v2 Am trecut la propria mea logică de recuperare a subtitrărilor integrată cu API-ul OpenSubtitles v2. API-ul lor REST actual este documentat în jurul autentificării/autentificării, accesului bazat pe token și punctelor finale dedicate pentru căutare și descărcare, ceea ce l-a făcut o potrivire mult mai bună pe termen lung decât fluxul mai vechi. În codul meu, pasul de descărcare a devenit în cele din urmă un pipeline de comenzi explicit, aproximativ așa: // exemplu conceptual std::string cmd = BuildSubtitleCommand( pythonPath, scriptPath, moviesFolder, credentials ); if (!ExecuteCommand(cmd)) { Log("Subtitle download failed"); return; } Asta a devenit pasul . Descarcă subtitrări Logica de potrivire s-a schimbat de câteva ori. Ceea ce conta mai mult era că trecusem de la un strat în care nu aveam încredere complet la un traseu API despre care puteam raționa efectiv. Etapa 3: Sincronizează subtitrările Apoi am întâlnit următoarea problemă practică. Uneori, subtitrarea este subtitrarea corectă, dar temporizarea este greșită. La început, am gestionat asta manual cu un instrument GUI de sincronizare. Asta era utilizabil, dar a stricat întregul scop al proiectului. Dacă încă trebuia să trag fișiere într-o fereastră și să corectez temporizarea manual, nu automatizasem cu adevărat fluxul de lucru. Așa că am trecut la ffsubsync prin CLI și am construit o comandă de sincronizare în lot în jurul lui. În versiunea C++, bucla principală arăta așa: // exemplu conceptual std::string cmd = BuildSubtitleSyncCommand( videoPath, subtitlePath, outputPath ); bool ok = ExecuteCommand(cmd); Asta a transformat sincronizarea subtitrărilor dintr-un pas manual de reparare într-o operațiune în lot. Etapa 4: Curăță subtitrările După sincronizare, fișierul subtitrare corectat a folosit un sufix modificat, cum ar fi . _2.srt Asta a creat o altă problemă practică: playerul nu ar prefera automat fișierul sincronizat decât dacă numele fișierului era normalizat înapoi la forma standard așteptată. Așa că am adăugat o a treia comandă pentru subtitrări: Curăță subtitrările Sarcina sa era să: creeze un folder de backup mute subtitrările originale acolo redenumească subtitrările sincronizate înapoi la numele standard .srt Pasul de redenumire arăta așa: // exemplu conceptual std::string newStem = RemoveSyncSuffix(originalName); fs::path newPath = moviesPath / (newStem + ".srt"); if (FileExists(newPath)) { ReplaceFile(originalPath, newPath); } În acel moment, subtitrările deveniseră un pipeline complet: Descărcare → Sincronizare → Curățare Nu am planificat acest subsistem în avans. A crescut deoarece utilizarea reală a continuat să expună noi puncte de inconvenient. De ce am adăugat o referință completă a comenzilor pe ecran Pe măsură ce numărul comenzilor creștea, a apărut un alt tip de problemă. Sistemul putea funcționa perfect și totuși să fie incomod dacă comenzile în sine erau greu de reținut. Adăugam treptat mai multe acțiuni vocale, dar nu exista o modalitate simplă de a le vedea pe toate într-un singur loc. Așa că am adăugat o referință completă a comenzilor pe ecran. Scopul nu era prezentarea. Era utilitatea practică. Fluxul de lucru a devenit: pauză film spune Afișează comenzi afișează comenzile disponibile pe ecran complet verifică pe cea de care am nevoie spune Închide comenzi continuă vizionarea Acest lucru nu a rezolvat un blocaj tehnic. A rezolvat un blocaj de memorie. În cod, lansarea suprapunerii a fost simplă: bool ShowCommandCenterOverlay() { std::string overlayExe = GetOverlaysDir() + "CommandCenterOverlay.exe"; return RunExe("\"" + overlayExe + "\""); } Caracteristică mică, impact mare asupra utilizabilității. Ce am realizat mai târziu despre stratul asistent Inițial am construit sistemul în jurul Alexa dintr-un singur motiv: acela era hardware-ul asistent pe care îl aveam deja acasă. Deci, la început, m-am gândit natural la asta ca la o configurație bazată pe Alexa. Mult mai târziu, după ce arhitectura funcționa deja, am realizat că Alexa nu era de fapt dependența importantă. Dependența importantă era puntea de declanșare. Odată ce asistentul trimite o comandă în TriggerCMD, restul sistemului este local: script sau executabil, logică sistem de fișiere, control player, flux subtitrări, comutare afișaj și flux de închidere. Asta înseamnă că arhitectura nu este fundamental legată de Alexa deloc. Același sistem poate funcționa la fel de bine cu Google Assistant sau Google Nest, deoarece ambele acționează doar ca straturi de declanșare pentru același traseu de execuție locală. Atunci am realizat că asistentul era înlocuibil. Logica locală era nucleul real. Unde VLC a schimbat arhitectura Mai târziu, am creat o a doua ediție a sistemului pentru VLC. Asta a schimbat arhitectura mai mult decât mă așteptam. Cu PotPlayer, a trebuit să mă bazez pe: focus fereastră taste simulate comportament UI Cu VLC, puteam activa o interfață de control HTTP locală la pornire și să o folosesc ca strat de control mult mai curat. Pornirea VLC cu HTTP activat arăta așa: // exemplu conceptual std::string cmd = BuildVlcLaunchCommand( vlcPath, moviePath, httpConfig ); Acea singură diferență a schimbat arhitectura mai mult decât mă așteptam. Acum puteam trimite comenzi direct: // exemplu conceptual bool SendVlcCommand(const VlcConfig& cfg, const std::string& command) { std::string request = BuildVlcRequest(command); return SendHttpRequest(cfg, request); } Și să pun pauză la redare cu ceva la fel de simplu ca: VlcSendCommand(vc, "pl_pause"); Asta a fost mult mai curat decât tastele simulate. De asemenea, a facilitat mult raportarea stării, ceea ce a contat pentru suprapunerile de progres și alte mecanisme de feedback. Unde a eșuat automatizarea: Afișarea progresului în PotPlayer Una dintre cele mai utile comenzi pe care mi-aș fi dorit-o a fost o modalitate de a arăta cât de mult din film a trecut și cât mai rămâne. Pentru PotPlayer, am încercat mai întâi să rezolv asta precis folosind: OCR Tesseract citirea regiunii ecranului Am reușit să o fac să funcționeze pe propriul meu computer. Dar nu am putut să o fac suficient de fiabilă pe diferite: rezoluții layout-uri de monitoare configurații TV condiții de scalare UI Aceasta a fost o lecție importantă. O soluție care funcționează pe un computer nu este automat ceva ce poți generaliza curat. Deci, pentru PotPlayer, am renunțat la ideea unei soluții universale bazate pe OCR și am păstrat o soluție de rezervă mai simplă: dezvăluirea barei de progres native și lăsarea utilizatorului să estimeze vizual poziția. Pentru VLC, povestea a fost diferită. Acolo, puteam interoga direct starea redării și să redau propria mea suprapunere folosind valori interne de timp. Această diferență este exact motivul pentru care nu am încercat să forțez ambii playere într-o abstractizare uniformă falsă. De ce am reconstruit totul în C++ Generația de scripturi BAT și PowerShell a sistemului a fost reală. A funcționat. Încă consider acea versiune funcțional valabilă. Dar nu voiam să păstrez proiectul la acel nivel pentru totdeauna. Depindea prea mult de comportamentul la nivel de script, toleranțe specifice mașinii și piese slab conectate. Voiam: structură mai bună integrare Windows mai puternică suprapuneri native gestionarea centralizată a configurației logging mai curat o arhitectură bazată pe executabile mai predictibilă Așa că am reconstruit sistemul în C++. Arhitectura a rămas aceeași. Implementarea a devenit mai disciplinată. Nu am făcut asta pentru că versiunea de script era fără valoare. Am făcut-o pentru că ideile de bază deveniseră suficient de valoroase încât nu voiam ca acestea să mai fie ținute laolaltă de o grămadă de scripturi și presupuneri. Acesta a fost momentul în care proiectul a început să pară o aplicație Windows reală, mai degrabă decât un experiment de automatizare util. Ce am învățat Cea mai mare lecție din acest proiect este că controlul vocal nu a fost niciodată adevărata problemă dificilă. Problema dificilă a fost construirea unui model de redare locală care să nu se prăbușească în: stare ascunsă presupuneri fragile de UI deriva listelor de redare bug-uri de sincronizare a rezolvat mai mult decât mă așteptam. Regula Primului Fișier A eliminat o întreagă clasă de probleme deoarece structura folderului în sine a devenit mașina de stări. Cealaltă lecție este că designul „local-first” contează doar atunci când elimină inconveniente reale. În acest sistem, „local-first” a însemnat: fișierele rămân locale redarea rămâne locală logica rămâne locală doar traseul de declanșare depinde de stratul asistent/bridge A