brenekh / encodarr Goto Github PK

This was likely caused by the change to the job parameters. It should be a simple fix since it was already fixed in the Library queue modal.

The Controller should perform some sort of health check to make sure runners are still running their jobs. It could be as simple as recording the last time they checked in and seeing if it was over an hour ago (the exact time would be configurable).

Would generate graphs and provide insights on the type of media in the monitored library. Things like video codecs, audio channels/codecs, and whether or not have subtitles are likely candidates for information to show.

This isn't an issue in Docker as long as restart: unless-stopped is set, but it isn't a particularly good idea to crash when requesting a new job is a perfectly acceptable action to take.

IMO, the complete signal portion of the API (POST /job/complete) is a bit clunky.

Certain elements can be computed server-side (datetime completed, and filename). And the nested json may have been nice for the Python version, but the Go version doesn't make it nearly as easy.

Just a simple on/off toggle for adding a stereo audio track, if none exists.

Add some way to modify settings such as file system check interval and tv show optimized queue.

This is probably easiest done as another section to the Web UI (Settings or something) and a matching /config/config.json storage file.

It would be advantageous to build a runner docker image that doesn't rely on a package manager to download FFmpeg.

A possible source of these binaries could be https://johnvansickle.com/ffmpeg/, but the licensing needs to be looked at. I assume it'd be fine to download using curl or wget and put into a docker image, but I'm not 100% on that just yet.

Instead of completely skipping a file that has the same modtime, it should only skip running mediainfo on the file. This also means that the files table needs to be updated to cache the mediainfo data.

Making this change means that the user can change the requirements (target codec and stereo audio) and the Controller will instantly start queueing files instead of waiting for the modtime to change.

One issue to keep in mind with this is cross-platform support. run-script-os can help solve this though.

The normal Node API can recursively copy files, there's no need for run-script-os.

Things like copying would be helpful to know

If the Controller stops or restarts during a file transfer, not only is the job eventually redone, but the Runner errors out completely.

This isn't super necessary, but it could be nice for diagnostic purposes.

Not sure how to make sure only the Runner that owns the job can cancel it, but it would be nice to allow Runners to cancel their job to allow resources back to the system. The Controller would just appendleft it back into the queue.

I'm thinking a button that brings up a modal of the queue is a good way to show it in the Web UI, instead of displaying it in the Libraries tab directly.

One possible solution is to setup allow an env var to set the Runner Name that will then be displayed as Runner: RUNNER_NAME under the stage in the web UI.

The file system check can take multiple minutes and shouldn't start if there is one that is currently running, but there is currently no check to make sure that that requirement is met.

It could be nice to send notifications when a file is queued and when a file is started/finished.

Essentially, if a Runner disconnects from the Controller, that new job request will still be handled and the job will have to be cleaned up by the Runner health check before it can be worked on.

Nuff said

Plugins could have the ability to rename the file, which would allow for a plugin to replace outdated codec info stored in the filename with more up-to-date data, or strip it out completely.

Runner modes would allow users to set what jobs a runner does based on media information.

I need to investigate more, but it seems that the last_updated value in the dispatched_jobs table isn't getting set and then the health check invalidates the job.

Selectable codecs should include:

• H.265(HEVC)
• H.264(AVC)
• AV1
• VP9

This will be in-place of a proper plugin system, until said plugin system is actually completed.

Whether it's [Logo] Encodarr or [Logo]ncodarr, the logo should a part of the header.

This is definitely down the line (when plugins get implemented), but it would be nice to import a Handbrake preset file and make the runners convert using those exact specifications. The only issue I foresee currently is detecting when a media file is already compliant with the preset.

Currently, headers are a combination of x--prefixed and rc/redcedar-named. The new convention should be all first-letter capitalized, with RedCedar (or whatever the name ends up being) being the first word in the header name.

I think it would look nice and be pretty informative if the icons used in the queue were also on the running job card. I'm thinking probably stacked on top of each other to the right of the filename.

FFmpeg's default output gives a lot of information about copyright and the media that the Runner needs to parse through before getting to the stats we care about. The arguments -hide_banner, -loglevel warning, and -stats should give a more parseable output.

The README needs a big overhaul so that it reflects the current state of the project.

For some reason I never actually implemented the prioritization to the job dispatching code, so that should probably be done so that priority actually does what it's supposed to.

This is more of a mental note than an actual issue, but both the Controller and the Runner should be available as docker images, but the Runner should also be available as a standalone binary (maybe even a GUI).

Go version 1.16 adds the ability to embed files into the final executable using the //go:embed directive. This is a fantastic option for the web interface resources so that they don't need to be extracted with an installer.

Currently, the Runners have to be attached to the storage media in a similar manner to the Controller, but that can cause weird permissions issues among other problems. A much more robust solution is to go with the original plan and send the files to the Runners.

If a Job that is running is replaced with a new file(for example, the file is upgraded), Encodarr will still copy the completed file even though it is not relevant.

The problem is detecting this kind of change. A hash could be computed when the Job is dispatched/generated and checked again when the file is ready to be copied back. This only works for files named the same, but some file existence checks could supplement that as well.

Whatever the solution, it probably should be an option for the user.

This would help prevent re-dispatching jobs after a Controller restart.

https://github.com/goccy/go-json is a project that claims to significantly increase the speed of encoding and decoding json.

This may be useful because we have database data that is stored as a slice of bytes because SQLite doesn't support serializing them. One such operation is the scanning of the filesystem (reading and writing to the files table mostly), which does seem to take some time to complete.

Things like the media_info for a job just don't need to be sent usually.

Could be as simple as a Triangle for encoding to HEVC and a pair of headphones for downmixing audio to stereo.

Currently, the job queue prioritizes TV Shows over Movies, but other options should be available such as prioritizing only stereo audio track over any encoding to HEVC.

Previous versions of RedCedar would sometimes leave larger files than what it started with. When only adding a stereo audio track, some size increase is to be expected, but if the file is being converted to HEVC, then the goal is for the file to be smaller not larger.

The history.json entries need to be reversed or sorted by datetime

Include:

• Controller version
• Web API and Runner API supported versions
• License Info This project is licensed using the GNU Public License v2 (or whatever I end up choosing)
• Link to the project GitHub

This would also need some manipulation of the path displayed in the URL bar without refreshing the page

Basically would cut a clip the user selects to the length they specify and then send it to a Runner and see what happens. Would be very beneficial for testing things like Codecs and Container formats, but also isn't necessarily necessary since a user could do it on their own.

The current idea is for the Controller to advertise which API versions it supports and then the Runner can determine which to use.

I need to investigate further, but something about the move to Go broke the saving to dispatched_jobs.json. I think that the problem might be more recent and possibly related to the introduction of the options package.

It's not super obvious when a library is being scanned, so some indication in the libraries tab would be nice.