Gemini kiểm tra Plex server của tôi. Kết quả chẩn đoán khiến tôi bất ngờ

Ai cần Netflix khi đã có Plex — phần mềm media server chạy cục bộ cho phép bạn stream các file video lưu trữ tại nhà? Tôi đã vận hành Plex server của riêng mình trên Raspberry Pi 5 trong vài năm và hầu như nó chạy rất ổn định.

Nhưng cũng giống như việc mang xe đi bảo dưỡng dù không thấy có vấn đề rõ ràng, thỉnh thoảng bạn nên “mở nắp capo” Plex để xem có cần thay dầu hay không. Vấn đề là tôi không phải chuyên gia về streaming video. Tôi biết (đại khái) MKV là gì và biết cách sắp xếp thư viện Plex, nhưng hoàn toàn mù mờ về các chi tiết của transcoding.

Nói ngắn gọn: tôi cần trợ giúp, và — bạn đoán đúng rồi — tôi tìm đến AI, cụ thể là Gemini. (Tôi cũng có thể dùng ChatGPT hoặc Claude, nhưng hiện tại tôi đang là người dùng Google AI Pro.)

Giống như mọi công cụ khác, các mô hình LLM như Gemini giỏi một số việc và dở tệ ở những việc khác. Cưa máy rất tốt để cắt tỉa cây, nhưng không phù hợp để cắt bánh cưới. Tương tự, LLM thường tệ ở life coaching và viết sáng tạo thật sự (chúng thích sao chép hơn), nhưng lại cực kỳ giỏi trong việc phân tích hàng đống log lỗi — và với một cuộc “khám tổng quát” cho Plex, đó chính là kỹ năng cần thiết.

Có vài cách để cho LLM kiểm tra hệ thống Plex. Một cách là mô tả cấu hình cơ bản (Windows, Mac hoặc Linux) rồi để nó đưa ra các lệnh terminal để lấy log, sau đó bạn copy–paste vào khung chat. Cách này hoạt động và khá an toàn vì bạn không thả AI vào hệ thống của mình. Nhưng nó chậm và mệt — ngón tay Ctrl-C và Ctrl-V sẽ nhanh chóng than phiền.

Thay vào đó, tôi chọn cách hiện đại hơn. Tôi đang thử Google Antigravity — IDE do Google tạo ra cho phép Gemini và các LLM khác (bao gồm Claude) viết code dựa trên prompt ngôn ngữ tự nhiên. Đúng kiểu vibe coding.

Tôi mở Antigravity và đưa cho Gemini prompt: “Bạn có thể kiểm tra Plex server của tôi không?”

Antigravity là một trong số các IDE AI kiểu này. OpenAI có Codex (kể cả bản cho macOS), Claude Code và Cursor cũng tương tự. Với Antigravity, bạn cấp quyền cho Gemini truy cập một “workspace” trên hệ thống (một hoặc nhiều thư mục), và dưới sự hướng dẫn của bạn, nó có thể đọc file trong đó, thậm chí — gulp! — chạy lệnh terminal. Gemini còn có thể suy nghĩ trước và đưa ra kế hoạch thực hiện trước khi hành động.

Mức độ tự động của Gemini là do bạn quyết định. Bạn có thể yêu cầu nó xin phép trước mỗi lệnh terminal, hoặc bật chế độ “always allow” để nó tự do chạy lệnh. Google khuyến nghị chế độ an toàn hơn là “always approve”, và tôi đồng ý.

Quay lại Plex. Tôi đã thiết lập sẵn workspace Plex trên Raspberry Pi cho Antigravity. (Tôi dùng một thư mục con làm khu staging có git để có thể lần lại các bước nếu có sự cố.) Tôi mở Antigravity, chọn workspace Plex và đưa cho Gemini 3 Flash prompt: “Hãy kiểm tra Plex server của tôi.”

Gemini im lặng một lúc (“Thinking…”) rồi đưa ra kế hoạch: kiểm tra nhiệt độ CPU và tải, RAM, dung lượng lưu trữ, đọc một loạt log Plex, kiểm tra database, test transcoding và mạng, đồng thời đảm bảo các ổ lưu trữ ngoài được mount đúng và có tốc độ truyền dữ liệu ổn. Nói cách khác, một cuộc khám tổng thể Plex.

Sau khi xem kế hoạch, tôi nhấn Proceed và Gemini bắt đầu chạy, các đoạn lệnh terminal xuất hiện khi tôi thỉnh thoảng bấm Approve.

Giống như bác sĩ phát hiện kết quả xét nghiệm đáng lo trong một lần khám định kỳ, cuộc kiểm tra Plex của Gemini phát hiện ra một vấn đề hệ thống nghiêm trọng.

(Cũng cần nói rằng khi làm vậy tôi đã cho Gemini quyền truy cập toàn bộ file media Plex của mình — bạn nên cân nhắc kỹ việc này.)

Khoảng năm phút sau, Gemini đưa ra chẩn đoán và tôi tròn mắt. Nó nói Plex server vẫn hoàn toàn ổn (“thể trạng đỉnh cao”), nhưng phát hiện bằng chứng cho thấy thẻ SD lưu trữ đang hỏng.

Điều này khiến tôi bất ngờ vì tôi nghĩ mình đã chuyển boot từ thẻ SD sang NVMe rồi. Nhưng Gemini tìm thấy hàng loạt lỗi I/O từ thẻ SD cũ. Giả thuyết ban đầu: Raspberry Pi vẫn boot từ thẻ SD.

Gì cơ? Tôi đã quên chuyển file hệ thống sang NVMe sau cả một cuối tuần cài đặt sao?

Giống như một bệnh nhân lo lắng, tôi đi tìm ý kiến thứ hai. Tôi mở một Antigravity khác, gọi Claude Opus 4.5 và đưa báo cáo của Gemini vào. Claude kiểm tra thêm log và trả lời: Pi không boot từ SD, nhưng vẫn kiểm tra thẻ vì tôi chưa rút nó ra, khiến log đầy lỗi I/O. Nói cách khác, Gemini thấy dấu hiệu cảnh báo và đưa ra kết luận quá nghiêm trọng.

Tôi mang thông tin này quay lại Gemini và yêu cầu đánh giá lại. Nó xác nhận: Pi boot từ NVMe như dự kiến, và thẻ SD vẫn cắm là nguồn gây lỗi I/O.

Kết luận tổng thể của Gemini: B+. Các chỉ số tốt, hệ thống ổn, nhưng thẻ SD cũ giống như cái dằm trong ngón chân — nên rút ra càng sớm càng tốt. Và có thể xóa cache transcoder để tránh buffering.

Vậy là bạn đã có công thức cho việc kiểm tra Plex định kỳ bằng AI — rất phù hợp để phát hiện các vấn đề âm thầm. Hãy thử, bạn có thể phát hiện điều bất ngờ.

---

# Plex Diagnostic Expert – Custom GPT System Prompt

Bạn là Plex Diagnostic Expert, một trợ lý AI chuyên biệt được thiết kế để giúp người dùng Plex Media Server khắc phục sự cố phát nội dung, máy chủ không ổn định và lỗi thư viện mà không cần kiến thức kỹ thuật nâng cao hoặc công cụ chuyên dụng.

🎯 Mục tiêu chính

Nhiệm vụ của bạn là hướng dẫn người dùng thực hiện một quy trình “khám sức khỏe” có cấu trúc cho Plex server bằng cách yêu cầu các đoạn log cụ thể và diễn giải kết quả bằng ngôn ngữ dễ hiểu.

---

🛠 Quy trình tương tác

Giai đoạn 1: Xác định môi trường

Trước tiên, hãy hỏi:

1. Plex đang chạy trên nền tảng nào? (Windows, Mac, Linux, Docker/Unraid, Synology)

2. Vấn đề chính là gì? (“Buffering”, “Server unavailable”, “Files not appearing”)

---

Giai đoạn 2: Hướng dẫn lấy log

Đường dẫn phổ biến:

• Windows:

  %LOCALAPPDATA%\Plex Media Server\Logs

• Linux:

  /var/lib/plexmediaserver/Library/Application Support/Plex Media Server/Logs

• Docker:

  [Config Path]/Library/Application Support/Plex Media Server/Logs

• Synology:

  /volume1/Plex/Library/Application Support/Plex Media Server/Logs

Hướng dẫn:
“Mở

Plex Media Server.log. Kéo xuống cuối, copy 100 dòng cuối và dán vào đây.”

---

Giai đoạn 3: Kiểm tra chẩn đoán

1. Nhịp tim (độ ổn định lõi)
   Tìm

   Database corrupt, CRITICAL, Error

2. Tuần hoàn (transcoding)
   Tìm

   Speed =>

   • Speed > 1.0 → server khỏe

   • Speed < 1.0 → phần cứng quá tải

3. Thị lực (quét thư viện)
   Tìm

   Scanner: Processing directory và các dòng ERROR sau đó

4. Kết nối từ xa (mạng)
   Tìm lỗi

   NAT, AsyncConnector, ConnectivityTest

---

Giai đoạn 4: Báo cáo của bác sĩ

1. Điểm tổng thể (A → F)

2. Tóm tắt bằng ẩn dụ dễ hiểu

3. 3 bước rõ ràng để khắc phục

---

🚑 Quy trình khẩn cấp

Nếu log quá khó:

• Khởi động lại server

• Analyze file cụ thể

• Kiểm tra dung lượng ổ đĩa

---

⚠️ Ràng buộc

KHÔNG yêu cầu chạy lệnh terminal phức tạp trừ khi người dùng là “Power User”. Chỉ dùng đường dẫn file và copy–paste.