Sukūriau balsu valdomą namų kino teatrą „Windows“, nes pavargau keltis stabdyti filmus.

Aš jo nesukūriau, nes norėjau „išmaniosios pramogų platformos“. Sukūriau, nes pavargau keltis. Mano sąranka buvo paprasta: „Windows“ kompiuteris, prijungtas prie televizoriaus per HDMI, vietiniai filmai ir įprastas medijos grotuvas. Jokių srautinių transliacijų. Jokių medijos serverių. Jokių debesies sinchronizavimų. Tik failai diske ir tiesioginis atkūrimas. Ta dalis buvo gerai. Eilinė dalis prasidėjo po to, kai filmas buvo paleistas. Sustabdyti filmą? Imkitės klaviatūros. Praleisti į priekį? Tas pats. Reikia subtitrų? Atgal prie kompiuterio. Norite kito epizodo? Vėl atgal. Tikrasis trukdis atsirado dėl labai paprasto dalyko. Žiūrint filmus iš lovos, kiekvienas pauzės, praleidimo ar kitos komandos reiškia, kad reikia atsikelti, nueiti prie kompiuterio, naudoti klaviatūrą, o tada grįžti atgal. Pats atkūrimas buvo paprastas – tik vietiniai failai ir medijos grotuvas – bet aplink esanti patirtis vis tiek veikė kaip stalinis kompiuteris. Tai nebuvo panašu į namų kiną. Žinoma, yra ir kitų būdų tai išspręsti. Belaidės klaviatūros, oro pelės ir nuotolinio valdymo programėlės gali padėti. Bet jos vis tiek traktuoja šią patirtį kaip kompiuterio valdymą. Vis tiek judinate žymeklį, naršote meniu arba spaudžiate klavišus – sąveikaujate su programine įranga, o ne tiesiog žiūrite filmą. Tikroje kino patirtyje technologija išnyksta. Sutelkite dėmesį į filmą, o ne į sąsają. Taigi, pradėjau nuo labai praktiško klausimo: Ar „Windows“ kompiuteris, prijungtas prie televizoriaus, gali būti mažiau erzinantis valdomas iš kitos kambario pusės? Tas klausimas galiausiai išaugo į atskirą „Windows“ programą, kurią dabar vadinu „Smart Home Cinema – Voice Control“. Tačiau įdomiausia dalis atsirado anksčiau nei pati programa. Iš pradžių nuolat susidūriau su įprastomis idėjomis: grojaraščiai, metaduomenys, žiūrėjimo būsenos stebėjimas, bibliotekos logika, visa normali informacija, kurios tikėtumėtės medijos programoje. Bet tai nebuvo tai, ką iš tikrųjų bandžiau sukurti. Neiškopiau visos medijos bibliotekos. Tiesiog norėjau kelių balso komandų, kurios paprastai ir patikimai veiktų su vietiniais failais. Taigi, pradėjau žiūrėti į problemą iš kitos pusės. Ką daryti, jei sistemai nereikėtų suprasti viso aplanko? Ką daryti, jei ji tiesiog naudotų pirmąjį ten rastą vaizdo failą? Ką daryti, jei „Play Movie“, „Next Movie“ ir visa kita veiktų pagal tą patį taisyklę? Kuo daugiau galvojau, tuo labiau tas metodas atrodė protingas. Tai buvo paprasta, matoma ir lengviau patikima. Kuo daugiau sluoksnių pridėjau – grojaraščius, metaduomenis, stebėjimą, bibliotekos logiką – tuo daugiau vietų atsirado, kur viskas galėjo pasisukti blogai. Norėjau kažko labiau nuspėjamo, su mažiau judančių dalių. Ta idėja tapo visos sistemos pagrindu. Vėliau pradėjau vadinti tai . „First File Rule“ (Pirmojo failo taisyklė) Sistema visada veikia su pirmuoju vaizdo failu aplanke „Movies“. Tai reiškia, kad pats aplankas tampa eile. Pirmojo failo taisyklė „C++“ kalba pagrindinė logika tapo labai maža: // konceptualus pavyzdys std::string GetFirstMovie(const std::string& folder) { auto files = ListFiles(folder); for (auto& file : files) { if (IsSupportedVideo(file)) return file; } return ""; } Tai supaprastinta versija – tikroji implementacija apima papildomus patikrinimus ir kraštutinių atvejų tvarkymą. Tai atrodo nereikšminga, bet ta maža funkcija prisiėmė didelę dalį sistemos. Man nereikėjo vidinės atkūrimo būsenos. Man nereikėjo duomenų bazės. Man nereikėjo sinchronizuoti bibliotekos rodinio su failų sistema. Pati failų sistema tapo tiesos šaltiniu. Tas vienas sprendimas pakeitė beveik viską kita. Tai taip pat natūraliai veikė su TV epizodais, nes epizodai paprastai jau yra sutvarkyti pagal failo pavadinimą. O jei norėjau pasirinktinio filmų tvarkymo, galėjau tiesiog numeruoti failų pavadinimus ir leisti tai pačiai taisyklei padaryti visa kita. Pirmasis veikiantis procesas Aš jau turėjau „Amazon Alexa“ garsiakalbį ir „TriggerCMD“ įdiegtą mano kompiuteryje, skirtą nesusijusioms lengvoms automatizacijoms. Taigi, pirmasis atkūrimo procesas buvo pakankamai akivaizdus: „Alexa“ → „TriggerCMD“ → vietinis BAT/PS1 scenarijus → medijos grotuvas Tuo metu nebandžiau kurti produkto. Bandžiau pašalinti labai specifinius erzulius iš savo sąrankos. Pirmosios komandos buvo minimalios: (Leisti filmą) Play Movie (Pristabdyti filmą) Pause Movie (Sustabdyti filmą) Stop Movie To pakako, kad įrodyčiau koncepciją. Tuo metu daugiausia naudojau „PotPlayer“, todėl pirmoji sistemos karta buvo sukurta aplink jį. Ir čia pasirodė pirmoji tikra inžinerinė problema. Pirmosios kartos pagrindas buvo scenarijai Prieš pertvarkydamas viską „C++“ kalba, sistema jau veikė kaip BAT ir „PowerShell“ scenarijų rinkinys. Tai svarbu, nes architektūra neprasidėjo „C++“. „C++“ atėjo vėliau. Net scenarijų versija jau atliko realų darbą: pasirinkdavo dabartinį filmą, perkeldavo žiūrėtus failus iš aktyvaus aplanko, tvarkydavo gretimus subtitrus, paleisdavo grotuvą ir pradėdavo perėjimą prie kito failo. Taigi, kai sakau, kad projektas prasidėjo nuo mažų dalykų, nereiškia, kad tai buvo tik grubus maketas. Tai jau buvo naudotina. Pavyzdžiui, ankstyvoje „PowerShell“ versijoje „Next Movie“, pagrindinė logika atrodė taip: // konceptualus pavyzdys # gaukite dabartinį filmą $current = Get-FirstVideoFile $moviesFolder # perkelti filmą į žiūrėtų aplanką Move-File $current $watchedFolder # perkelti atitinkamus subtitrus Move-MatchingSubtitles $current $moviesFolder $watchedFolder # gaukite kitą filmą $next = Get-FirstVideoFile $moviesFolder Tai nebuvo elegantiškas kodas, bet jis jau apėmė pagrindinį sistemos elgesį. Pagrindinė idėja – pasirinkti pirmąjį failą, jį perkelti ir tęsti – veikė nuo pat pradžių. Aplankas jau buvo eile. Perėjimo logika buvo pagrįsta failais. Ir „Next Movie“ jau buvo daugiau nei filmo operacija. Tai buvo atkūrimo perėjimas, pagrįstas ta pačia būsenos modeliu. „PotPlayer“ neturėjo vietinės API, kurią galėčiau naudoti Su „PotPlayer“ neturėjau švaraus vietinio HTTP valdymo sluoksnio, kaip jį siūlo „VLC“. Taigi, pirmoji karta turėjo pasikliauti: simuliuojamu klaviatūros įvestimi aktyvaus lango aptikimu fokusavimo valdymu laiko delsimais Iš pradžių tai atrodo valdoma. Siųskite klavišą. Atlikta. Praktiškai tai nebuvo problema. Problema buvo užtikrinti, kad „PotPlayer“ iš tikrųjų būtų langas, gaunantis klavišą. Tai privertė mane parašyti pagalbinę logiką, susijusią su langų paieška ir fokusavimo tvarkymu. „C++“ versijoje „PotPlayer“ lango paieška atrodė taip: HWND FindPotPlayerWindow() { // pereikite per viršutinio lygio langus // nustatykite „PotPlayer“ langą pagal pavadinimą ar klasę return hwndPotPlayer; } Tada man reikėjo priversti tą langą būti priekyje: bool BringToForeground(HWND hwnd) { if (!IsWindow(hwnd)) return false; // prijunkite įvesties gijas, jei reikia // atkuriate langą, jei jis minimizuotas // pateikite langą į priekį ir suaktyvinkite jį return true; } Tik po to galėjau saugiai siųsti klavišą: void SendPotPlayerKey(WORD vk) { HWND hPot = FindPotPlayerWindow(); if (!hPot) return; BringToForeground(hPot); // trumpas delsimas, kad užtikrintumėte, jog fokusas pritaikytas SendKeystroke(vk); } Aš maniau, kad įdomiausia dalis bus balso sluoksnis. Taip nebuvo. Viena iš pirmųjų tikrai erzinausių problemų buvo tiesiog užtikrinti, kad „Windows“ fokusavimo elgesys būtų pakankamai patikimas, jog balso komanda tyliai nieko nepadarytų arba nepatektų į netinkamą vietą. Tai buvo vienas iš pirmųjų momentų, kai tai nustojo būti „keletas scenarijų“ ir pradėjo panašėti į tikrą „Windows“ automatizavimo inžineriją. Determinuotas atkūrimas be grojaraščių Kai atsirado „First File Rule“, iškart atsirado kita problema. Jei dabartinis filmas lieka aplanke, „Play Movie“ tiesiog vėl atidarys tą patį failą amžinai. Taigi, turėjau du skirtingus būdus tvarkyti dabartinį failą. 1. Ištrinti filmą Jei baigiau filmą ir nenorėjau jo daugiau matyti aktyviame aplanke, komanda pašalintų filmą ir gretimus subtitrų failus. Iš pradžių tai padariau kaip nuolatinį trynimą. Tai buvo blogas sprendimas. Tai veikė, bet buvo per agresyvu. Balso komanda yra netinkama vieta būti atsitiktiniam negrįžtamam trynimui. Taigi, pakeičiau implementaciją į failų perkėlimą į „Recycle Bin“. Tai padarė elgesį daug saugesnį, nepakeičiant bendros architektūros. 2. Kitas filmas Kartais norėjau pasilikti filmą, o ne jį ištrinti. Taigi, pridėjau antrą komandą: (Kitas filmas). Next Movie Užuot ištrynus dabartinį failą, jis perkelia: dabartinį filmą jo susijusius subtitrus į antrą aplanką, pvz., „Watched Movies“ (Žiūrėti filmai). Bet tai tik dalis to, ką iš tikrųjų daro komanda. Jos tikrasis tikslas yra sukurti sklandų perėjimą prie kito elemento. Kai dabartinis filmas išeina iš aplanko „Movies“, kitas failas automatiškai tampa pirmuoju failu. Tada sistema jį nedelsdama paleidžia. Taigi, „Next Movie“ yra ne tik failų valdymo komanda. Tai iš tikrųjų yra atkūrimo perėjimo komanda, sukurta ant „First File Rule“. Nėra eilės, kurią reikia atnaujinti. Nėra indekso „dabar groja“, kurį reikia palaikyti. Nėra žiūrėjimo būsenos duomenų bazės, kurią reikia taisyti vėliau. Sistema pašalina dabartinį elementą, leidžia kitam failui tapti pirmuoju ir pradeda atkūrimą. Štai kodėl ši taisyklė pasirodė daug naudingesnė nei tikėjausi. Ji supaprastino ne tik pasirinkimą. Ji taip pat supaprastino perėjimus. Nuo pavienių komandų iki realaus žiūrėjimo darbo eigos Kai pirmosios atkūrimo komandos tapo stabilios, nustojau galvoti apie izoliuotus veiksmus ir pradėjau galvoti apie visą žiūrėjimo sesiją. Tai paskatino tokias komandas kaip: (Pristabdyti filmą) Pause Movie (Sustabdyti filmą) Stop Movie (Pirmyn 30 sekundžių) Forward 30 Seconds (Pirmyn 1 minutę) Forward 1 Minute (Pirmyn 2 minutes) Forward 2 Minutes (Atgal 30 sekundžių) Rewind 30 Seconds (Atgal 1 minutę) Rewind 1 Minute (Atgal 2 minutes) Rewind 2 Minutes Aš sąmoningai laikiau šiuos šuolius fiksuotus. Nebandžiau atskleisti kiekvieno galimo grotuvo veiksmo per balsą. Tiesiog norėjau komandų, kurios pašalintų dažniausias priežastis grįžti prie kompiuterio. Kita maža komanda pasirodė esanti stebėtinai naudinga praktiškai: (Paleisti filmą per TV). Daugeliu atvejų kompiuteris yra naudojamas įprastai pagrindiniame monitoriuje. Bet kai ateina laikas žiūrėti filmą, patirtis turėtų persikelti į televizorių. Užuot rankiniu būdu perjungiamos ekrano išvesties ir tada paleidžiant atkūrimą, ši komanda atlieka abu veiksmus vienu metu. Ji perjungia aktyvų ekraną į televizorių ir paleidžia filmą tiesiai per visą ekraną. Techniškai tai nedidelė funkcija, bet realiai ją naudojant ji pašalina dar vieną nedidelį trinties tašką tarp sėdėjimo prie kompiuterio ir filmo sesijos pradžios iš sofos ar lovos. Play Movie TV Tada viena komanda palaipsniui tapo svarbesnė už kitas. Visko sustabdymo komanda Ši komanda kilo iš labai specifinio realaus gyvenimo erzulio. Žiūrėti iš lovos lengva. Sesijos pabaiga sugrąžina trintį. Jei jau buvau pusiau užmigęs, paskutinis dalykas, ko norėjau, buvo keltis iš lovos, eiti prie kompiuterio, sustabdyti grotuvą, perkelti ekraną atgal nuo televizoriaus prie monitoriaus, išjungti kompiuterį, o tada vėl atsigulti į lovą. Tai gali skambėti smulkiai. Man taip nebuvo. Jei jau jutau mieguistumą, net toks trumpas pertraukimas buvo pakankamas, kad sugadintų akimirką. Sukūriau šią komandą, nes norėjau, kad filmo sesija pasibaigtų taip pat švariai, kaip prasidėjo. Taigi, padariau vieną komandą, kuri atlieka visą išjungimo seką iš eilės. „VLC“ leidime logika yra iš esmės tokia: // konceptualus pavyzdys void StopEverythingVlc(const Config& cfg) { StopPlayback(); RestoreDisplayOutput(); // palaukite, kol sistema nusistovės WaitShortDelay(); ShutdownSystem(); } Techniškai tai nėra pati sudėtingiausia funkcija sistemoje. Svarbu tai, ką ji pašalina. Ji pašalina sesijos pabaigos trintį: sustabdo atkūrimą, atkuria normalų ekrano kelią, laukia, kol jungiklis nusistovės, tada išjungia mašiną. Man tai tapo viena naudingiausių komandų visoje sistemoje ne todėl, kad ji buvo techniškai įspūdinga, bet todėl, kad ji švariai išsprendė labai žmogišką erzulį. Subtitrai tapo savarankiška problema Atkūrimo valdymas pasirodė esąs tik pusė problemos. Subtitrai beveik atsitiktinai tapo antruoju inžineriniu keliu. 1 etapas: paslėptas Mano pirmoji subtitrų automatizacija naudojo „Subliminal“ su senesne „OpenSubtitles“ API. Tai iš tikrųjų veikė. Problema nebuvo ta, kad ji iš karto nepavyko. Problema buvo ta, kad nepasitikėjau ja ilgalaikėje perspektyvoje. Priklausomybės kelias jau atrodė per daug trapus, ir nenorėjau, kad subtitrų palaikymas vėliau tyliai pablogėtų. Taigi, aš jį pakeičiau. 2 etapas: „OpenSubtitles“ API v2 Perėjau prie savo subtitrų paieškos logikos, integruotos su „OpenSubtitles“ API v2. Jų dabartinė REST API yra dokumentuota su prisijungimu/autentifikavimu, žetonų pagrindu veikiančia prieiga ir dedikuotais paieškos bei atsisiuntimo galiniais taškais, todėl tai buvo daug geresnis ilgalaikis sprendimas nei senesnis srautas. Mano kode atsisiuntimo žingsnis galiausiai tapo aiškia komandų grandimi, maždaug taip: // konceptualus pavyzdys std::string cmd = BuildSubtitleCommand( pythonPath, scriptPath, moviesFolder, credentials ); if (!ExecuteCommand(cmd)) { Log("Subtitle download failed"); return; } Tai tapo (Atsisiųsti subtitrus) žingsniu. Download Subtitles Atitikimo logika kelis kartus keitėsi. Svarbiau buvo tai, kad perėjau nuo sluoksnio, kuriuo nevisiškai pasitikėjau, prie API kelio, kurį galėjau iš tikrųjų suprasti. 3 etapas: sinchronizuoti subtitrus Tada susidūriau su kita praktine problema. Kartais subtitras yra tinkamas, bet laikas neteisingas. Iš pradžių tai tvarkiau rankiniu būdu naudodamas GUI sinchronizavimo įrankį. Tai buvo naudotina, bet sugriovė visą projekto idėją. Jei vis tiek turėjau vilkti failus į langą ir taisyti laiką rankomis, nebuvau iš tikrųjų automatizavęs darbo eigos. Taigi, perėjau prie „ffsubsync“ per CLI ir sukūriau aplink jį partijos sinchronizavimo komandą. „C++“ versijoje pagrindinė kilpa atrodė taip: // konceptualus pavyzdys std::string cmd = BuildSubtitleSyncCommand( videoPath, subtitlePath, outputPath ); bool ok = ExecuteCommand(cmd); Tai pakeitė subtitrų sinchronizavimą iš rankinio taisymo žingsnio į partijos operaciją. 4 etapas: išvalyti subtitrus Po sinchronizavimo pataisytas subtitrų failas turėjo modifikuotą priesagą, pvz., . _2.srt Tai sukėlė dar vieną praktinę problemą: grotuvas automatiškai nepirmenybę suteiktų sinchronizuotam failui, nebent failo pavadinimas būtų normalizuotas atgal į standartinę formą. Taigi, pridėjau trečią subtitrų komandą: (Išvalyti subtitrus) Clean Subtitles Jos užduotis buvo: sukurti atsarginį aplanką perkelti originalius subtitrus ten pervadinti sinchronizuotus subtitrus atgal į standartinį failo pavadinimą .srt Pervadinimo žingsnis atrodė taip: // konceptualus pavyzdys std::string newStem = RemoveSyncSuffix(originalName); fs::path newPath = moviesPath / (newStem + ".srt"); if (FileExists(newPath)) { ReplaceFile(originalPath, newPath); } Tada subtitrai tapo pilnu procesu: (Atsisiųsti → Sinchronizuoti → Išvalyti) Download → Sync → Clean Aš neplanavau šios posistemės iš anksto. Ji augo, nes realus naudojimas nuolat atskleidė naujus trinties taškus. Kodėl pridėjau viso ekrano komandų nuorodą Didėjant komandų skaičiui, atsirado kitokio pobūdžio problema. Sistema galėjo veikti puikiai ir vis tiek būti nepatogi, jei pačias komandas buvo sunku atsiminti. Aš palaipsniui pridėjau daugiau balso veiksmų, bet nebuvo paprasto būdo pamatyti juos visus vienoje vietoje. Taigi, pridėjau viso ekrano komandų nuorodą. Idėja nebuvo pristatymas. Tai buvo praktinis naudojimas. Darbo eiga tapo: pristabdyti filmą pasakyti (Rodyti komandas) Show Commands pamatyti galimas komandas per visą ekraną pasirinkti tą, kurios reikia pasakyti (Uždaryti komandas) Close Commands tęsti žiūrėjimą Tai neišsprendė techninės kliūties. Tai išsprendė atminties kliūtį. Kode, paleisti nuorodą buvo paprasta: bool ShowCommandCenterOverlay() { std::string overlayExe = GetOverlaysDir() + "CommandCenterOverlay.exe"; return RunExe("\"" + overlayExe + "\""); } Nedidelė funkcija, didelis naudojimo poveikis. Ką vėliau supratau apie asistento sluoksnį Iš pradžių sistemą sukūriau aplink „Alexa“ dėl vienos paprastos priežasties: tai buvo asistento aparatinė įranga, kurią jau turėjau namuose. Taigi, iš pradžių natūraliai galvojau apie tai kaip apie „Alexa“ pagrįstą sąranką. Daug vėliau, kai architektūra jau veikė, supratau, kad „Alexa“ nebuvo tikrai svarbi priklausomybė. Svarbi priklausomybė buvo paleidimo tiltas. Kai tik asistentas išsiunčia komandą į „TriggerCMD“, visa kita sistema yra vietinė: scenarijus arba vykdomasis failas, failų sistemos logika, grotuvo valdymas, subtitrų darbo eiga, ekrano perjungimas ir išjungimo srautas. Tai reiškia, kad architektūra nėra iš esmės susieta su „Alexa“. Ta pati sistema gali veikti lygiai taip pat gerai su „Google Assistant“ ar „Google Nest“, nes abu jie veikia tik kaip paleidimo sluoksniai tam pačiam vietiniam vykdymo keliui. Tada supratau, kad asistentas yra pakeičiamas. Vietinė logika buvo tikroji esmė. Kur „VLC“ pakeitė architektūrą Vėliau sukūriau antrą sistemos versiją, skirtą „VLC“. Tai pakeitė architektūrą labiau, nei tikėjausi. Su „PotPlayer“ turėjau pasikliauti: langų fokusavimu simuliuojamais klavišais UI elgesiu Su „VLC“ galėjau įjungti vietinę HTTP valdymo sąsają paleidžiant ir naudoti ją kaip daug švaresnį valdymo sluoksnį. „VLC“ paleidimas su įjungtu HTTP atrodė taip: // konceptualus pavyzdys std::string cmd = BuildVlcLaunchCommand( vlcPath, moviePath, httpConfig ); Tas vienas skirtumas pakeitė architektūrą labiau nei tikėjausi. Dabar galėjau siųsti komandas tiesiogiai: // konceptualus pavyzdys bool SendVlcCommand(const VlcConfig& cfg, const std::string& command) { std::string request = BuildVlcRequest(command); return SendHttpRequest(cfg, request); } Ir pristabdyti atkūrimą su kažkuo taip paprastu kaip: VlcSendCommand(vc, "pl_pause"); Tai buvo daug švariau nei simuliuojami klavišų paspaudimai. Tai taip pat žymiai palengvino būsenos ataskaitų teikimą, o tai buvo svarbu progreso perdangoms ir kitiems grįžtamojo ryšio mechanizmams. Kur automatizavimas nepavyko: progreso rodymas „PotPlayer“ Viena iš naudingiausių komandų, kurią norėjau, buvo būdas parodyti, kiek filmo praėjo ir kiek liko. „PotPlayer“ atveju pirmiausia bandžiau tai išspręsti tiksliai naudodamas: OCR Tesseract ekrano regiono skaitymas Man pavyko tai padaryti savo mašinoje. Bet negalėjau padaryti jos pakankamai patikimos įvairiems: rezoliucijoms monitoriaus išdėstymams TV sąrankoms UI mastelio sąlygoms Tai buvo svarbi pamoka. Sprendimas, kuris veikia vienoje mašinoje, automatiškai nėra tai, ką galima švariai generalizuoti. Taigi, „PotPlayer“ atveju atsisakiau idėjos apie visiškai universalią OCR pagrįstą sprendimą ir pasilikau paprastesnį atsarginį variantą: atskleisti gimtąjį progreso juostą ir leisti vartotojui vizualiai įvertinti padėtį. „VLC“ atveju istorija buvo kitokia. Ten galėjau tiesiogiai užklausti