1. Reenable multiarch build
2. As we know github actions pretty limited, either killed OOM or 6hrs timeout

In this PR we do old way, build everything separately, then gather and push manifest. Some issue is the currecnt Dockerfile can't be used for this, as we will build js out side docker, and only build dim in container. I thought create Dockerfile.ci for this use case. Technically still like master Dockerfile but with UI build disabled.

Build proof : https://github.com/martadinata666/dim/actions/runs/2565143979

Thoughts?

This relates to issue #213 that I opened. I have modified the Docker image workflow to support building images for multiple architectures (amd64, arm64 and armv7). Unfortunately I was not able to add RISC as an architecture, as it is not supported by Node.

I also fixed the Dockerfile such that it won't be necessary to manually add the ffmpeg binaries to the project root in order to build the image. This way, the workflow will build.

Todo

• [x] request coalescing
• [x] write new TMDB client
• [x] cache eviction policy
• [x] client-side in-flight request limiting
• [x] proper error propagation

Notable types

struct TMDBMetadataProvider

TMDBMetadataProvider is the main type used to provide a centralized store of the response-cache, the shared reqwest Client type, and the API key.

TMDBMetadataProvider does not implement ExternalQuery or ExternalQueryShow since it is a unified cache and so the media type being searched for must be provided explicitly.

However since the ExternalQuery trait does not allow passing this in the method arguments we have another type MetadataProviderOf<K> which is used to parameterise the search type. TMDBMetadataProvider::movies and TMDBMetadataProvider::tv_shows will each produce MetadataProviderOf<Movies> and MetadataProviderOf<TvShows> respectively. and these are the types for which ExternalQuery is implemented on.

struct TMDBClient

This is a private type that is the API wrapper for the TMDB REST API, it only contains a reference to a provider instance for access of the API key, and nothing else. It has associated methods which each correspond to some kind of TMDB API endpoint/operation.

Example

let provider = TMDBMetadataProvider::new("API_KEY");

let breaking_bad/* : ExternalMedia */ = provider.tv_shows().search("breaking bad", None).await.expect("I am the one who panics.");

let el_camino/* : ExternalMedia */ = provider.movies().search("El Camino: A Breaking Bad Movie", Some(2019)).await.expect("this is the way.");

// only one http request will be made. the rest of the futures will wait on the shared result of the first one.
let _ = futures::join!(
    provider.movies().search("baby driver", None)),
    provider.movies().search("baby driver", None)),
    provider.movies().search("baby driver", None)),
    provider.movies().search("baby driver", None)),
).await;

When I first tried Dim, I had a hard time figuring out how to add media, because the check boxes that you need to click to select a folder in the file browser don't appear until you hover over them, so I didn't realize there even were check boxes. I kept clicking on folder names, which just shows their contents. I saw a comment on reddit from a user who had the same confusion I had. This PR rearranges the UI of the "new library" file browser to improve the user experience here.

Here are some screen shots comparing the before and after with some notes about what's changed.

Before

Initial state

• The prompt "select folders containing media" is combined with the number of folders that are selected, with no explanation of what the number in parentheses means.
• The check boxes are not visible.
• The current path is not shown.
• The back button is hard to notice at the bottom.

Within a subfolder with a folder checked

• Only after hovering over a check box and clicking it does it stay visible.
• The check boxes are aligned to the right and it can be a little difficult to see which row each check box corresponds to.

After

Initial state

• Help text is added to explain the function of clicking a check box vs. clicking a folder name.
• The back button doesn't appear, because you can't go back from the root.
• The current path is shown and the label clarifies that the directories shown are being viewed but are not selected.
• All the unchecked check boxes are visible and aligned to the left where it's easy to see which row each one corresponds to.
• The number of folders currently selected has a dedicated label explaining what the number means.
• The number of folders selected and the toggle actions are moved below the browser.

Within a subfolder with a folder checked

• The back button appears at the top, where a user is likely to expect it based on its default position in web browsers and operating system file browsers.
• The checked and unchecked check boxes and their corresponding items are clearly distinguishable.

Hey there,

First of all thanks for all the amazing work.

It's been a while since the latest GitHub release. v0.3.0-rc6 being released in October of last year. How far along is dim on the road to an rc7, or a 0.3.1 for example?

The dev tag for Docker is updated regularly, might it be a good idea to publish weekly, or monthly tags as well, or when a certain milestone is hit?

Thanks!

I can see that you have chosen the GPLv2 license, but that you're also pulling in an Apache 2.0 licensed lib (https://github.com/launchbadge/sqlx) (EDIT: Dual licensed, so ignore).

Unfortunately, to my limited knowledge (and research), those licenses are not compatible and you may, in fact, not distribute the final product under the GPLv2 license.

Have you considered other licenses? GPLv3 is compatible with Apache, but may also be more restrictive than GPLv2.

Another thing is that your web UI seems to be licensed under GPLv2 as well and if you ever plan on using the web UI in a web wrapper for iOS or other stores (smart TVs etc.), you may run into issues. The iOS app store is for instance not compatible with GPL at all.

dim's UI is broken, its stuck in an infinite redirect loop loading the main and login page. It only happens on firefox, not chrome.

The docker-compose logs keep showing this:

dim-dim-1  | Oct 19 16:02:03.046 INFO GET, mod: warp, route: /api/v1/dashboard/banner, status: 401 Unauthorized, ip: 192.168.50.20:35194, duration: 215, duration_tag: us
dim-dim-1  | Oct 19 16:02:03.167 INFO GET, mod: warp, route: /login, status: 200 OK, ip: 192.168.50.20:35182, duration: 198, duration_tag: us
dim-dim-1  | Oct 19 16:02:03.452 INFO GET, mod: warp, route: /static/css/main.f6c4e38b.chunk.css, status: 200 OK, ip: 192.168.50.20:35172, duration: 224, duration_tag: us
dim-dim-1  | Oct 19 16:02:03.455 INFO GET, mod: warp, route: /static/js/2.75e9e814.chunk.js, status: 200 OK, ip: 192.168.50.20:35182, duration: 599, duration_tag: us
dim-dim-1  | Oct 19 16:02:03.474 INFO GET, mod: warp, route: /static/js/main.d55f75db.chunk.js, status: 200 OK, ip: 192.168.50.20:35186, duration: 356, duration_tag: us
^Ccanceled

Describe the bug When you change your username, subsequent requests fail and the old username is displayed.

To Reproduce

1. Start brand new install of Dim with a fresh database
2. Register an admin account
3. Go to "Preferences > Profile > Username" and change username.
4. A PATCH request is made to /api/v1/auth/username and it returns status code 200.
5. Running SELECT * FROM users; in sqlite shows the new username.
6. A GET request is made to /api/v1/auth/whoami and it returns status code 200. The response body contains the old username, e.g.:

   {"picture":null,"roles":["owner"],"spentWatching":0,"username":"oldusername"}
   

7. Refreshing the page and clicking "Profile" shows the old username in the UI.
8. Two GET requests are made to /api/v1/user/settings and both return status code 500 with this body:

   {"error":"DatabaseError","messsage":"A database error occured: DatabaseError(RowNotFound)"}
   

9. Sticking some dbg! statements in dim::routes::settings::get_user_settings and hitting /api/v1/user/settings via curl reveals this error in the server logs:

   [dim/src/routes/settings.rs] &User::get(&mut tx, &user.0.claims.get_user()).await = Err(
       DatabaseError(
           RowNotFound,
       ),
   )
   

   Perhaps the authentication token used by the client is not being updated after changing usernames?

Expected behavior The new username should be reflect in the UI after reloading the page, and API requests should not return status code 500.

Device and browser including versions: Firefox 95.0.2.

Describe the bug I am getting hundreds of these messages while using the Dim website. They appear in pairs every few seconds. They are:

"Connection to the server lost, some actions might not work"

immediately followed by:

"Connection to the server has been restored"

To Reproduce Steps to reproduce the behavior:

1. Log into the website
2. Wait

Expected behavior No error messages

Screenshots

Device and browser including versions: Desktop on firefox stable v95.02 (flatpak) - Running on Fedora Silverblue

Additional context Running in podman using the following command: podman run --privileged -dt -p 8005:8000/tcp -v $HOME/dim-config:/opt/dim/config -v /media:/media:ro --name dim ghcr.io/dusk-labs/dim:dev

Howdy,

Running the dev docker image of dim (but I noticed this on non-dev as well).

When clicking on "Play S1 E1" on Dim, the file browser shows no files, but if I click into the show the files are there and will play.

Just wanted to report this. This occurs on any show I try, and happens on Chrome as well as Firefox. Logs didn't show any sort of error or anything like that. If there's anything else needed for troubleshooting, please let me know.

Leaving Dim to run on idle tends to lead to one thread absolutely pinning a core on my machine at 100%, we should investigate the cause and fix before the next release.

Describe the bug When I connect to http://[server ip]:8000 the browser return a 404 error

To Reproduce Steps to reproduce the behavior:

git clone https://github.com/Dusk-Labs/dim yarn --cwd ui/ && yarn --cwd ui/ build mkdir utils && ln -nfs $(which ffmpeg) utils/ffmpeg && ln -nfs $(which ffprobe) utils/ffprobe cargo run --features vaapi --release

It build apparently without major errors, but when i go to the adress http://[server ip]:8000 :

Error 404

The port 8000 is open, and the terminal send me connection log. (ex : 2022-12-11T13:40:47.348811Z INFO dim::logger: GET route="/" status=404 ip="192.168.1.43:34514" duration=510 duration_tag="us")

For info, it work fine with Docker at the same ip adress (exept i can't find a way to the directory structure of my server, but it's for another day ^^)

Expected behavior Land on the homepage (or another, depending on the address)

Device and browser including versions: Server OS : Debian 10 Client OS : Ubuntu 22.04.1 LTS Client browser : Brave Browser 108.1.46.140

Additional context There is a pastebin with the output of the last command (cargo run --features vaapi --release) : https://pastebin.com/nK7hmGm0

I'm running it from sources.

Maybe the problem is between the chair and the computer ^_^'

Thank you for your feedback :)

Describe the bug Can't upload a profile picture. Receiving Database error. (500 in network)

To Reproduce Steps to reproduce the behavior:

1. Go to System preferences
2. Click on Profile
3. Select a new picture as avatar
4. click "save as new avatar" button
5. (No UI reference to error is shown). Nothing happens

Expected behavior Expect to save new image, or at least show that an error ocurred.

Screenshots

Device and browser including versions: Chrome Version 107.0.5304.110 (Official Build) (arm64)

Also sorted the hunk of dependencies in cargo.toml in ascending order. Had to update notify code to 5.0 this means we gotta test the new fs notification feature.

Describe the bug

cargo run --release can't create account and login. document needed?

To Reproduce Steps to reproduce the behavior:

1. Go to 'cargo run --release'

Expected behavior first login for create account or something can follow to create user/login

Screenshots If applicable, add screenshots to help explain your problem.

Device and browser including versions: macos && chrome

Additional context Add any other context about the problem here.

Before the PR was made there was a problem with the padding on the settings menus on the Video Player, the positioning of the menus was not appealing to users and the gaps between the menu and the overlay was too big.

After the PR:

• The padding on the menus has been fixed.
• The gaps are also fixed making it look more appealing to users