dusk-labs / dim Goto Github PK

When the API returns a relative url to a backdrop or a poster, the webui prepends library to the path before fetching it.

We are currently using stoppable_thread to wrap the thread that parses ffmpeg's stdout, however this is now useless and no longer needed as the Session logic is decoupled from the TranscodeHandler (should be rename to FfmpegStdoutParser).

We should add a feature which either pins metadata to media automatically or manually, this can make scanning a library more efficient in the future because we can essentially cache all the correct metadata onto the file itself.

It will also make manual rematches effectively persistent unless overwritten, for large libraries this could be a life saver.

src/routes/general.rs is getting quite hefty and ngl ugly. It needs a bit of a touchup, especially the /dashboard routes.

on the experimental branch fix-video-streaming I get playback halting it looks like its just buffering on the UI side but if you check out the server stderr I see panics in nightfall

Mar 24 21:35:10.404 INFO request, uri: "/api/v1/stream/9c374e3a-4d2e-4388-9dbd-38185ee28c60/data/5.m4s", method: Get
try wait, ffmpeg died, killing
thread '<unnamed>' panicked at 'called `Option::unwrap()` on a `None` value', /home/mental/.cargo/git/checkouts/nightfall-b84a4513de79ba91/9ade607/src/lib.rs:177:53
Mar 24 21:35:38.464 INFO response, status: 500 Internal Server Error, route: GET /api/v1/stream/<id>/data/<chunk..> [2] (get_chunk)
try wait, ffmpeg died, killing
thread '<unnamed>' panicked at 'called `Option::unwrap()` on a `None` value', /home/mental/.cargo/git/checkouts/nightfall-b84a4513de79ba91/9ade607/src/lib.rs:177:53
Mar 24 21:35:38.473 INFO response, status: 500 Internal Server Error, route: GET /api/v1/stream/<id>/data/<chunk..> [2] (get_chunk)

If you try to play a video for more than 3mins the player will crash with a QuotaExceededError. The issue doesnt occur with the v4 alpha of dash.js.

we are both dim

• Add ability to specify an arbitrary timeout when fetching chunks at manifest creation. This could be useful for players that do not retry fetching a chunk if the chunk route returns 102 (such as mpv).

For the executable file, company name and so on

Some people mount their tmpfs to 10TB drives, others (like me) have it at a few gigabytes. when the cache fills up playback perpetually fails until the cache is empty.

We should clean the streaming cache on a playback exit.

Investigate why audio streams crash around this mark. Its something to do with processes being paused but mark as not paused.
This most likely has something to do with how we calculate the current chunk being transcoded.

As a temporary solution disabling timeouts for audio streams seems to fix the issue.

Currently video.js is very picky about streams. Streaming with nightfall works fine in MPV and Vlc, however its partially broken in browsers and more specifically video.js.

This is because video.js is very strict about segment continuity. Because of this seeking doesnt work, and hard timeouts (ffmpeg getting killed after a timeout instead of being issues a SIGSTP) have to be disabled. On further inspection video.js crashes because when ffmpeg is restarted with a new timestamp offset, the fragments it outputs also have a timestamp offset that is reset to 0, and because init.mp4 is never reloaded by videojs automatically video.js thinks that the segment requested is actually older than it is, thus it tries to fetch the next segment infinitely until it gets a valid segment timestamp offset.

We can fix this two ways, either we patch video.js to be more lenient, or when we seek in a non-transcoded region we restart video.js and reload the dash manifest (this needs to be paired with soft-timeouts for transcoding sessions).

When streaming from docker the stream crashes because the init fragments for sessions is placed in the dim root and not the streaming cache directory.
I think this can be fixed by including a full path when passing the segment name to -hls_fmp4_init_filename

• Create one library with a file path and set its media type to movies (name this "xxx")
• Wait for indexing to complete
• Create a second lib with the same file path as "xxx" but the media type is set to "Tv Shows"

Expected behavior: Instantly indexed due to already being indexed before so the results should be cached.

Actual behavior: Indexing never starts.

The activity page is a page meant for administrators to see information about their server, what users are doing in Dim, if there are any transcoding sessions, the admin can see info about the stream, progress, performance and other information.

In some cases mediafiles may not get matched because of weird naming conventions. In these cases we still need to display the files in each library somehow so a user can manually match them.