Good health probes should be determined for the Kubernetes deployment.

Liveness and readiness can be the same since the pod doesn't receive any inbound traffic.

Currently, djmarinara pulls files down into its working directory when preparing to render them. This has led to a complex cleanup system requiring a manifest file to ensure djmarinara cleans up after itself even if it has crashed previously.

Instead of this mess, ensure that files are only ever downloaded to a path under /tmp and that when djmarinara starts up, it cleans up anything sitting around from its previous run.

Suggest path: /tmp/djmarinara

Per issue title. Not doing this causes djmarinara to wait at times when it shouldn't, causing crashes in the ffmpeg loop.

djmarinara should be accompanied by an example TOML configuration file covering all of the current startup parameters, as represented in the djmarinara module's constructor.

Additional configuration should be added to this file going forward.

Propose config.toml as the filename.

djmarinara can currently find songs to play if they are contained in ZIP files. If the file chosen from the playlist found at the playlist URL has a .zip extension, the archive is pulled down, extracted, and any candidate songs are identified and one is chosen at random to play.

This functionality should be enhanced to also support:

• .tar.gz/.tgz archives (tarballs)
• .7z (7-zip)
• .lha
• .ace
• .rar
• .bzip/.bz2

The availability of this functionality is contingent on Python support or ease of algorithmic implementation in Python. Let's not rewrite any of these from scratch if it would require a lot of work.

Currently, the playlist URL djmarinara pulls down is expected to consist of URLs that it will play at random.

Add a TOML configuration option for djmarinara to allow playing the playlist URLs in order.

Music modules (mod, it, xm, s3m, etc.) don't convert to AAC very quickly. It's likely there is a good native PCM format they convert best to initially, and that should be used first to reduce CPU load/conversion time and to prioritize conversion to AAC for the video rendering step.

A couple small issues with the new logging changes:

• Console display only occurs for WARNING and higher. It should default to INFO, or at least have an option in main.py for that.
• The location of the log file is not clear. This may be more of a documentation issue, or it might be useful to actually log the location explicitly when the script starts, and ensure that is displayed in the console, too.

Since djmarinara is conducive to using massive playlists of songs that may not have been fully vetted ahead of time, it's desirable to put some basic constraints on what may be contained in song metadata.

1. Choose a reasonably complete list of slurs and/or profane words.
2. Allow configuration for whether the censor is enabled and whether such words should be censored, or whether a song whose metadata contains any of them should be discarded completely.
3. Implement text replacement for censored words.

I'm still roughing out what I want this for, but it comes down to effective cache management.

Every time a song is rendered, a running average should be calculated for how much disk space is being used per second of video. This should be kept around as a djmarinara object member.

I have a few use cases in mind for it, just need the number to exist first! Expected calculation is bytes per second. An integer is fine.

Whenever it starts up, djmarinara should go through any existing songs in the media path and add them to the gas tank, so gas tank calculations will make sense.

(djmarinara doesn't crash very often, but this is still useful to account for.)

The formula used to handle text scrolling in the rendered videos works pretty well, except that songs with a lot of text (hundreds of lines) tend to scroll very quickly. It would be ideal to rework this formula to scroll text at a constant rate over time, regardless of frame rate or text length.

There are occasions where videos get rendered that have no text displayed on them. I assume something is amiss with the text encoding or there is some other issue related to the source text. Better validation is needed here, and to either fix the malfunctioning text or discard songs whose text data can't be salvaged.

Currently the ffmpeg-streamer-deployment.yaml only explicitly supports YouTube. Examples should be made for:

• Twitch
• Restream.io
• Facebook
• Periscope

These should use sensible defaults as appropriate for each service.

Dense lines of scrolling text covering half the screen or more tend to compress very badly and look like garbage under the existing quality settings. See what can be done to fix this without sacrificing rendering speed.

Use the Python logging module to handle logs for djmarinara instead of print statements. Make those logs follow the principles of the 12 Factor App: https://12factor.net/

Currently, djmarinara pulls files down into its working directory when preparing to render them. This has led to a complex cleanup system requiring a manifest file to ensure djmarinara cleans up after itself even if it has crashed previously.

Instead of this mess, ensure that files are only ever downloaded to a path under /tmp and that when djmarinara starts up, it cleans up anything sitting around from its previous run.

Suggest path: /tmp/djmarinara

djmarinara and ffmpeg have limited means of communicating with one another. djmarinara queues up an infinite playlist of pre-rendered videos, while also trying to keep the cache of said videos to a reasonable size. However, if ffmpeg laps the existing playlist set, it crashes and will restart with whatever the oldest video still available in the cache is.

Example:

• the queue has playlist0.txt, playlist6.txt, playlist7.txt, and playlist8.txt
• playlist8.txt points to playlist9.txt, which djmarinara has not finished rendering
• ffmpeg crashes when it tries to access playlist9.txt, so it restarts on playlist0.txt, which follows up with playlist6.txt, and onward

It would be better to know exactly what ffmpeg has already played so that the cache and queue management done by djmarinara can simply clean up already-played videos and their accompanying playlists, as well as to configure playlist0.txt to pick up exactly where ffmpeg left off before the last time it crashed.

This issue requires some research, hence the lengthy explanation.

The current ffmpeg-bootstrap setup is probably not needed anymore. It should be evaluated for one of the following outcomes:

• Remove it altogether
• Handle adding the desired files programmatically via djmarinara itself (already handled via the sanity check but make sure it works in a pod configuration)
• Handle adding the desired files via configmap/secret instead, eliminating the need for an init container at all

djmarinara currently has a single visualization profile, which uses the ffmpeg showcqt filter, horizontally flipped, with song metadata as scrolling text from bottom of the screen to top, along with a fade from/to black at the beginning/end of a song.

ffmpeg offers numerous visualization options that haven't been tried out with djmarinara yet. The objective for this issue would be to parameterize the visualization options for ffmpeg pre-rendering and offer 10 different presets.

A file format for the presets will have to be established and those presets will have to be included with djmarinara and built into its Dockerfile.