StreamLink — Devlog #1

🚀 Project Overview

StreamLink is a lightweight, cross-platform desktop application built to streamline how users discover movies and TV shows, manage personal watchlists, and launch streaming options or official trailers instantly.

---

🛠️ Tech Stack

• Desktop Core: Electron.js / Node.js
• Frontend: HTML5, Modern CSS3 (CSS Grid/Flexbox), Vanilla JavaScript
• APIs & Services:
  • OMDb API — Movie/TV metadata & poster retrieval
  • JustWatch — External streaming provider routing
  • YouTube — Official trailer query integration

---

✨ Key Features Built

1. Dynamic Search & Multi-Page Fetching

• Built a asynchronous fetch pipeline integrated with OMDb API.
• Implemented request debouncing on search input to optimize network calls and avoid rate limits.

2. Format Filtering

• Added client-side category filtering allowing users to isolate Movies Only or TV Series Only in real time.

3. Persistent Local Watchlist

• Implemented a client-side bookmarking engine using localStorage.
• Users can star/unstar titles from any view, with data persisting across application restarts without requiring external database authentication.

4. Fast External Routing

• Integrated Electron’s shell.openExternal IPC module to launch streaming platforms and trailer searches directly in the user’s default browser.
• Bypasses <iframe> and embed restrictions (such as YouTube Error 153) while delivering instant playback.

5. UI Resilience & Fallbacks

• Handled broken image URLs with custom onerror image fallbacks to ensure clean card grid renders at all times.

---

📝 Learning Points & Challenges

• iFrame Embed Restrictions: Enlisted fallback routing via shell.openExternal after encountering YouTube embed blocks (Error 153) and public API latency inside Electron windows.
• Electron Window Handling: Configured custom User-Agent headers and tuned node integration preferences for secure local data operations.

---

🎯 Next Steps

• Add genre-based tagging and sorting options.
• Implement local cache for poster images to reduce startup fetch times.
• Build a packaged production executable (.exe) using electron-builder.

ladies and gentlemen i hv killed my screen and i no dont hv any other screen to continue the project i hv no clue on what to do now

devlog 1.6(i hv ate): i did not really do that much so i dont want to code an entire paragraph in markdown but what i hv done is that i have created a system where when i hold the second button for more than 5 seconds i can reset my bidget and savongs goal i also had to differentiate from a press and a hold and add a failsafe. i also need to go study social science BYE👋👋👋👋

Devlog #1.5(cus i need to go eat): Display Upgrade & 5-Second Safety Hold

Overview

In this update for Teal Tracker, we made a major visual upgrade by ditching the old display setup for a clean OLED layout, fixed input responsiveness, and made accidental resets impossible with a new hold gesture.

---

Key Updates & Hardware Changes

• Hardware Migration (7-Segment Removal):

  • Removed: Legacy 12-pin 4-digit 7-segment display module to free up I/O pins and eliminate complex multiplexing routines.
  • Added: I2C 0.96” SSD1306 OLED Display (128x64), streamlining control down to just 2 communication pins (SDA/SCL) and enabling a clean graphical UI.

• Fixed Input Lag & Missing Taps:

  • Stripped out blocking delay() calls in the button loop in favor of non-blocking millis() timing logic.
  • Inputs and potentiometer readings are now instantaneous without MCU freezes.

• 5-Second Hold-to-Reset Requirement:

  • Replaced the previous double-tap method on Pin 4 with a strict 5-second hold.
  • Eliminates accidental EEPROM resets while preserving a simple single-tap for viewing or configuring savings goals.

• Live Progress & Countdown UI:

  • Built a custom hold screen on the OLED that displays a real-time countdown (3… 2… 1…) alongside a dynamic progress bar while holding Pin 4.

---

Current Hardware Configuration

Pin / Component Interface Function 0.96” SSD1306 OLED I2C (A4/A5) Graphical UI, animations, and live feedback Pin 2 (BTN_CONFIRM) Digital Input Single tap to apply value; Hold (>500ms) for auto-repeat Pin 4 (BTN_SECOND) Digital Input Tap (<5s) = Goal Screen; Hold (>=5s) = Reset Budget Pin A0 (POT_PIN) Analog Input Dynamic preset selector (-$50 to +$50) with wake-on-move Pin 3 (BUZZER_PIN) PWM Output Frequency-based audio cues

---

Next Steps

• Add dynamic pitch variation on the buzzer based on whether money is added or subtracted.
• Create a goal-reached celebration screen on the OLED.
• Look into deep-sleep modes for better battery life.

Devlog #1: From Macropad Inspiration to Standalone Hardware

💡 The Spark of Inspiration

Initially, I wanted to build a simple 4-button macropad with a volume knob using an Arduino Uno. But as I started thinking about what would actually be useful day-to-day, I pivoted the idea into a Physical Money Tracker—a desktop device that lets me quickly log financial transactions with the twist of a dial and the press of a single button.

I decided to challenge myself: Ax the PC and PyCharm entirely. I wanted a 100% standalone hardware device that works on raw micro-controller logic and remembers my balance even if I unplug it.

---

🛠️ Designing the Architecture

Instead of hiding data on a computer screen, I dug out a 5461AS 4-digit 7-segment display to show my data directly on my desk.

The control flow is clean and tactile:

• The Dial (B10K Potentiometer): Acts as an amount selector. Turning it scrolls through transaction amounts (-20, -10, 0, +10, +20).
• The Confirmation (Push Button): Acts as the “Enter” key to commit the transaction.
• The Feedback (Active Buzzer): Gives a tiny “click” sound when shifting between numbers, and a satisfying double-beep when a transaction successfully saves.

Because I wanted it to be standalone, I utilized the Arduino’s EEPROM memory so my balance data survives power loss.

---

🎛️ Mapping the Complex Matrix

The hardest part of the prototype was figuring out the routing for the 5461AS display. Without a dedicated driver chip, it requires 12 independent pin connections. I mapped out a custom configuration to keep the standard digital pins (D2 and D3) free for my tactile inputs:

• Digits (Left to Right): Pins 12, 13, A1, A2 -> Connected to D12, D13, A1, A2
• Segments (A through G + DP): Connected to D4, D5, D6, D7, D8, D9, D10, D11
• Inputs: Potentiometer on A0, Button on D2, Buzzer on D3

---

💻 Prototype Core Firmware Logic

I integrated the SevSeg library to handle the rapid background multiplexing needed to keep the display lit without flickering. Here is the core operational loop of the system:

void loop() {
  int potValue = analogRead(POT_PIN);
  int potZone = potValue / 205; 
  
  switch(potZone) {
    case 0: selectedAction = -20; break;
    case 1: selectedAction = -10; break;
    case 2: selectedAction = 0;   break;
    case 3: selectedAction = 10;  break;
    case 4: selectedAction = 20;  break;
  }

  // Handle Button Press and Save to EEPROM
  int buttonState = digitalRead(BUTTON_PIN);
  if (buttonState == LOW && lastButtonState == HIGH) {
    currentBalance += selectedAction;
    saveBalance(currentBalance); // EEPROM storage
    
    sevSeg.blank();
    tone(BUZZER_PIN, 2700); delay(80); noTone(BUZZER_PIN);     
    delay(40);
    tone(BUZZER_PIN, 2700); delay(80); noTone(BUZZER_PIN);
  }
  lastButtonState = buttonState;

  if (buttonState == HIGH) {
     sevSeg.setNumber(selectedAction); 
  } else {
     sevSeg.setNumber(currentBalance);
  }
  sevSeg.refreshDisplay(); 
}