Tóm tắt nhanh
- Jellydash là dashboard mã nguồn mở cho Jellyfin, gom phiên phát, lịch sử xem và tình trạng tải về vào một giao diện.
- Thông tin Direct Play, Remux và nguyên nhân Transcode giúp khoanh vùng vấn đề trước khi quyết định nâng cấp máy chủ.
- Có thể chọn SQLite để không phải chạy thêm container MariaDB, rồi mở dashboard dưới dạng PWA trên điện thoại hoặc tablet.
- Đây là lớp giám sát bổ sung: thay đổi hàng đợi vẫn phải thực hiện trong trình tải, còn truy cập từ xa cần chú ý xác thực.
Jellydash đưa các phiên phát Jellyfin, yêu cầu nội dung và trạng thái tải về lên cùng một bảng điều khiển tự lưu trữ. Điểm đáng quan tâm với máy chủ gia đình không nằm ở việc có thêm biểu đồ, mà ở khả năng biết một phiên xem đang buộc máy chủ làm gì trước khi quy mọi hiện tượng giật hình cho phần cứng yếu.
Với người đã có Jellyfin cùng các dịch vụ bổ trợ, cài thêm một dashboard chỉ hợp lý nếu nó giảm được công sức kiểm tra. Jellydash đi theo hướng tương tự Tautulli dành cho Plex: bổ sung lớp quan sát, còn việc phát phim và vận hành các dịch vụ vẫn thuộc về những ứng dụng đang có.
Biết vì sao phải transcode hữu ích hơn chỉ đếm người đang xem
Nguyên nhân chuyển mã là thông tin có giá trị hơn số lượng người kết nối, bởi hai phiên phát có thể đặt yêu cầu rất khác nhau lên cùng máy chủ. Now Playing hiển thị tài khoản, nội dung, chất lượng và tiến độ, kèm phương thức phát Direct Play, Remux hoặc Transcode cùng lý do chuyển mã.
Direct Play là phát trực tiếp nội dung mà thiết bị nhận có thể xử lý; Remux thay cách đóng gói luồng, còn Transcode liên quan đến chuyển mã để đáp ứng điều kiện phát. Phân biệt các trạng thái này giúp tránh nhầm một phiên vẫn đang chạy với một phiên buộc máy chủ xử lý lại video. Chuyển mã có thể chỉ áp dụng cho âm thanh, không nhất thiết toàn bộ video; nhãn Audio Transcode trên thẻ phát giúp phân biệt trường hợp này. Dashboard không tự làm máy chủ nhanh hơn, nhưng cho biết nên kiểm tra ở đâu.
Nếu gặp trục trặc, trình tự hợp lý là xác định phiên bị ảnh hưởng, xem phương thức phát rồi đọc nguyên nhân chuyển mã, thay vì nâng cấp cấu hình ngay. Khi nguyên nhân nằm ở khả năng tương thích của ứng dụng phát, đổi cách phát hoặc chuẩn bị nội dung phù hợp có thể đáng cân nhắc trước khi mua thêm phần cứng. Đây là hướng xử lý có điều kiện, không phải bảo đảm mọi trường hợp đều giải quyết được bằng thay client.
Cũng không nên biến trạng thái Transcode thành một cảnh báo tuyệt đối. Chuyển mã có thể là yêu cầu cần thiết để người dùng xem được nội dung; điều cần đánh giá là nó có đi cùng vấn đề thực tế hay không. Một bảng điều khiển tốt nên giúp phân biệt nhu cầu bình thường với nút thắt, chứ không khiến người quản trị cố loại bỏ mọi phiên chuyển mã.
Lịch sử phát giúp quyết định bảo trì, nhưng cũng là dữ liệu riêng tư
Lịch sử phát có ích nhất khi phục vụ một quyết định cụ thể, chẳng hạn chọn thời điểm bảo trì hoặc kiểm tra nội dung còn đang được xem trước khi xóa. Jellydash ghi nhận hoạt động ở nền ngay cả khi không ai mở dashboard, cho phép tìm kiếm, lọc theo người dùng hoặc thư viện và xuất kết quả ra CSV.
Thống kê tổng hợp bổ sung xu hướng thời lượng xem, hoạt động thiết bị, ứng dụng phát và nguyên nhân chuyển mã. Dữ liệu này giúp nhìn vấn đề theo thời gian thay vì chỉ chụp lại một thời điểm. Nếu nhiều phiên khó phát cùng xuất hiện trên một nhóm client, đó là cơ sở để kiểm tra nhóm ấy trước, nhưng chưa đủ để kết luận mọi lỗi đều do ứng dụng.
Cần phân biệt lịch sử được thu thập với toàn bộ quá khứ của máy chủ. Jellydash bắt đầu ghi từ lúc chạy; lịch sử cũ có thể nhập từ bản sao lưu Playback Reporting của Jellyfin hoặc Emby theo các định dạng mà dự án hỗ trợ. Khả năng nhập dữ liệu Emby này không đồng nghĩa Jellydash hỗ trợ đầy đủ máy chủ Emby.
Với thư viện dùng chung trong gia đình, lịch sử xem cũng cần được đối xử như dữ liệu cá nhân. Không nên đặt một màn hình hiển thị tên tài khoản và nội dung đang xem ở nơi bất kỳ khách nào cũng nhìn thấy chỉ vì giao diện thuận tiện. Cùng một tính năng hỗ trợ vận hành có thể trở thành công cụ theo dõi không cần thiết nếu bật quá nhiều thông báo.
Tùy chọn loại trừ giám sát cho phép ngừng thu thập hoạt động mới của các tài khoản được chọn và ẩn chúng khỏi những mục theo dõi liên quan. Tuy vậy, dữ liệu đã có vẫn được giữ lại; đây không phải nút xóa lịch sử. Loại trừ thông báo cũng là một thiết lập riêng, nên tắt thông báo của một người không có nghĩa dừng ghi nhận hoạt động của họ.
Gom yêu cầu và lượt tải không có nghĩa thay thế từng dịch vụ
Giá trị của một trang tổng quan là giảm số nơi phải mở để biết hệ thống đang làm gì, không phải gom toàn bộ quyền điều khiển vào cùng chỗ. Kết nối Jellyseerr đưa yêu cầu nội dung và trạng thái của chúng lên dashboard; kết nối trình tải giúp phân biệt nội dung còn đang chờ với nội dung đã chuyển sang quá trình tải.
| Thành phần | Thông tin được gom về Jellydash | Giới hạn cần nhớ |
|---|---|---|
| Jellyfin | Phiên phát, lịch sử, thống kê và hoạt động máy chủ | Vẫn là dịch vụ phát nội dung, không bị dashboard thay thế |
| Jellyseerr | Yêu cầu nội dung cùng trạng thái | Cần kết nối dịch vụ Jellyseerr đang có |
| SABnzbd, qBittorrent, Transmission, Deluge, NZBGet | Công việc tải và kết quả gần đây | Jellydash đọc trạng thái; sửa hàng đợi trong trình tải |
Ranh giới chỉ đọc của phần tải về đáng được giữ rõ. Người quản trị có thể kiểm tra tiến trình từ màn hình tổng quan, nhưng khi cần thay đổi hàng đợi vẫn phải quay về ứng dụng chuyên trách. Vì vậy, không nên chọn Jellydash với kỳ vọng nó thay được qBittorrent hoặc biến toàn bộ chuỗi tải thành một dịch vụ duy nhất.
Phần thông báo hỗ trợ Telegram, Pushover, Discord webhook, ntfy, Gotify và Web Push. Thay vì bật mọi kênh, nên chọn nơi thực sự đọc và chỉ giữ các sự kiện đáng hành động, bởi thông báo mỗi lần ai đó bắt đầu xem rất dễ trở thành nhiễu. Việc có nhiều kênh tích hợp không tự động khiến một thiết lập nhỏ vận hành tốt hơn.
SQLite và tablet cũ hợp với máy chủ gia đình nhỏ
Với home lab nhỏ tại Việt Nam, ưu điểm thực dụng của SQLite là bớt một thành phần phải vận hành, chứ chưa thể quy đổi thành mức tiết kiệm RAM cụ thể. Cấu hình Docker Compose mặc định chạy Jellydash cùng MariaDB; lựa chọn SQLite chỉ chạy Jellydash và lưu cơ sở dữ liệu vào tệp cục bộ.
| Lựa chọn | Cách bố trí | Khi nào đáng cân nhắc |
|---|---|---|
| SQLite | Một container ứng dụng, dữ liệu ở ./sqlite-data/jellydash.sqlite | Cài đặt nhỏ, không muốn duy trì container cơ sở dữ liệu riêng |
| MariaDB | Ứng dụng đi cùng MariaDB theo cấu hình mặc định | Muốn dùng cấu hình mặc định hoặc đã vận hành MariaDB |
Cả hai lựa chọn đều tự tạo bảng cơ sở dữ liệu. Nếu bản MariaDB hiện tại đang hoạt động ổn định, không có lý do phải chuyển chỉ vì thấy tùy chọn nhẹ hơn. Giảm số container là lợi ích về cách quản lý, còn hiệu năng và dung lượng thực tế vẫn phụ thuộc dữ liệu được thu thập và môi trường chạy.
Máy tính bảng Android cũ có thể đảm nhiệm phần hiển thị bằng trình duyệt hoặc PWA, trong khi dịch vụ Jellydash tiếp tục chạy bên cạnh máy chủ. Tách hai vai trò này quan trọng: tận dụng tablet làm màn hình không có nghĩa phải chuyển Docker hoặc cơ sở dữ liệu sang tablet. Nó chỉ giảm việc phải mở máy tính mỗi lần muốn kiểm tra.
Chỉ nên dùng thiết bị còn chạy được trình duyệt phù hợp và còn đáp ứng yêu cầu bảo mật của mạng gia đình. PWA tạo lối truy cập giống ứng dụng, nhưng không biến phần cứng cũ thành thiết bị được hỗ trợ phần mềm vô thời hạn. Nếu dashboard chỉ được xem thỉnh thoảng, mở trên điện thoại sẵn có có thể hợp lý hơn duy trì một màn hình thường trực.
Mã nguồn Jellydash dùng giấy phép MIT và phần mềm được cung cấp miễn phí. Với người tự host tại Việt Nam, không có giá mua bản quyền ứng dụng phải quy đổi sang đồng Việt Nam, nhưng vẫn có chi phí máy chủ, lưu trữ và công bảo trì. Đây là khác biệt giữa miễn phí phần mềm với một hệ thống không tốn gì để vận hành.
Bật đăng nhập trước khi nghĩ đến truy cập từ xa
Một dashboard nhìn thấy tài khoản, lịch sử phát và kết nối tới các dịch vụ khác nên được bảo vệ như giao diện quản trị, không phải một trang thống kê vô hại. Jellydash mặc định tắt đăng nhập để dùng trong mạng gia đình tin cậy; tài liệu dự án yêu cầu bật xác thực khi đưa dịch vụ ra Internet và khuyến nghị Tailscale cho truy cập từ xa.
Biến AUTH_ENABLED=true bật cơ chế đăng nhập, đi cùng cấu hình tài khoản quản trị ban đầu. Bước này nên được thực hiện trước khi mở đường truy cập bên ngoài, thay vì công khai dashboard rồi mới tính cách giới hạn người xem. Tablet đặt cố định cũng cần được cân nhắc quyền truy cập vì sự tiện lợi thường đi kèm việc phiên đăng nhập tồn tại lâu.
Web Push yêu cầu dashboard dùng HTTPS. Với ntfy, quyền gửi vào một chủ đề chưa đủ để khiến nội dung trở thành riêng tư: cần giới hạn cả quyền đọc của người đăng ký. Nếu thông báo chứa tên người và phim họ xem, chọn kênh gửi là một quyết định về dữ liệu, không đơn thuần là sở thích giao diện.
Một điểm dễ gây hiểu nhầm khác là số CPU và RAM ở thanh bên được lấy từ máy đang chạy container. Nếu đặt Jellydash và Jellyfin trên hai máy khác nhau, không nên đọc các chỉ số ấy như mức sử dụng tài nguyên của máy chủ Jellyfin. Dashboard tập trung được giao diện, nhưng không làm hai máy trở thành cùng một hệ thống đo.
Jellydash đáng bổ sung khi thư viện đã có nhiều người dùng hoặc nhiều dịch vụ cần theo dõi, còn một máy chủ chỉ phục vụ cá nhân có thể chưa cần thêm lớp vận hành này. Lựa chọn hợp lý là triển khai vừa đủ, giữ lịch sử và thông báo trong phạm vi cần thiết, rồi dùng nguyên nhân chuyển mã để quyết định bước kiểm tra tiếp theo thay vì nâng cấp phần cứng theo cảm giác.
Nguồn tham khảo: Jellydash — tài liệu dự án trên GitHub, XDA-Developers
