zedfrigg/zoobox
1
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity Actions

Expand rough design document

Browse source
This commit is contained in:
Reinout Meliesie 2025-03-14 18:36:44 +01:00
parent 43688aa8ed
commit 130de753db
Signed by: zedfrigg
GPG key ID: 3AFCC06481308BC6
1 changed files with 46 additions and 4 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

50
documentation/design.md
View file

@ -1,8 +1,11 @@
# Design # Design
- There will be two SQLite databases that complement each other. - The integrated hardware + software solution will be called "Zoöbox".
The Linux application that can also be used separately will continue to be called "Zoödex".
- `$XDG_DATA_HOME/zoodex/shared.sqlite` will be downloaded over HTTP from `kernelmaft.com` and contain information about the films and series themselves, their bittorrent magnet links, and what files and tracks within each torrent to use. - There will be two Zoödex SQLite databases that complement each other.
- `$XDG_DATA_HOME/zoodex/shared.sqlite` will be downloaded over IPv6 + HTTPS from `kernelmaft.com` and contain information about the films and series themselves, their bittorrent magnet links, and what files and tracks within each torrent to use.
- `$XDG_DATA_HOME/zoodex/local.sqlite` will be created locally and contain information about what films and series the user has watched. - `$XDG_DATA_HOME/zoodex/local.sqlite` will be created locally and contain information about what films and series the user has watched.
This can be extended to allow the user to create a personal collection, i.e. a subset of all media available of their own choosing. This can be extended to allow the user to create a personal collection, i.e. a subset of all media available of their own choosing.
@ -28,10 +31,49 @@
The bittorrent hash here is provided by `sources.bittorrent_hash` in the shared database. The bittorrent hash here is provided by `sources.bittorrent_hash` in the shared database.
The file path here is provided by `sources.file_path` in the shared database. The file path here is provided by `sources.file_path` in the shared database.
- The video track that will be played for a piece of media will be within this file, but otherwise determined by LibMPV. - The video track that will be played for a piece of media will be within this file, but otherwise determined by limpvv.
- The audio track that will be played for a piece of media will be within this file, and its track number is given by `sources.audio_track` in the shared database. - The audio track that will be played for a piece of media will be within this file, and its track number is given by `sources.audio_track` in the shared database.
- The subtitle track that will be played for a piece of media can be within this file, or if present an additional subtitle file. - The subtitle track that will be played for a piece of media can be within this file, or if present an additional subtitle file.
Its track number is given by `sources.subtitle_track` in the shared database. Its track number is given by `sources.subtitle_track` in the shared database.
We rely on the assumption that when we provide LibMPV with a file and an additional subtitle file, all the combined subtitle tracks will always have the same track numbers. We rely on the assumption that when we provide libmpv with a file and an additional subtitle file, all the combined subtitle tracks will always have the same track numbers.
- We may need to store additional information about the progress of the bittorrent transfers depending on the library.
- Should Zoödex manage the input of local system configuration such as for wifi and VPN, or should that be a separate application?
- Similarly, should we manage the storing of local system configuration ourselves (read: in the local database), or leave it to systemd?
- We need hardware that supports hardware-accelerated decoding of at least H264, H265, VP8 and VP9 under NixOS.
Depending on the window manager we end up using we may also require 2D OpenGL or Vulkan acceleration.
This will more likely hinge on the availability of drivers than on the hardware itself.
- As a window manager we can consider Niri, Sway or even Cage.
- Controlling the UI will be done via a remote-like smartphone app.
We can connect over wifi or bluetooth.
Wifi is probably easier for the user but we'll need to figure out a way for the two hosts to find each other on the network.
Bluetooth makes conceptually more sense here but is more work for the user to connect.
- We can extend the functionality later by also providing built-in Youtube streaming and a web browser.
- The system will run NixOS, and the system image expression will not have any configurable parameters.
All configuration will be local and considered mutable state by Nix, i.e. it doesn't concern itself with it.
- We need to figure out the best way to remotely deploy updates to Zoöboxes in a reliable and non-obtrusive way.
We will most likely need to pre-build and provide binaries through a Nix binary cache, because noone wants their set-top box compiling its own update for hours.
If we end up going with ARM64 hardware this will mean cross-compilation which is an additional piece of complexity.
- Downloading system updates should happen in the background.
- If we can use an LTS kernel reboots should rarely be required, but whenever they are we probably should do it when the user turns the box "off".
Under normal circumstances this will suspend Linux, but if a reboot request is pending the box will reboot (thus fully applying the update) and then suspend.
- We need some way for the user to be able to turn the box back on from the smartphone app.
Investigate what options we have in Linux when we're in the suspend state, maybe WoL?
- For the other hardware of the Zoöbox we will need a big but cheap HDD and some set-top looking case.
Onto that case will of course go a snazzy "Zoöbox" decal.
- For remote troubleshooting key auth only SSH should be fine.