Taking inspiration from the current Nephos, create a class of maintenance jobs and make it so that it is easy to add new maintenance jobs in future.

Possibly...
Separate classes for each type of job, and then run command of all jobs in a single maintenance.run()

Currently, we manage all the jobs in a single jobstore. This should be
separated to avoid failure of everything in case a jobstore malfunctions.

We can improvise on the current mail sending model by making a derived class from SMTPHandler of the logging module.

It can have multiple functions and can be done at the end and embedded into the system seamlessly.

Store Wiki as PDF in the docs directory. Currently, the docs are available as md files.

Currently the uploader is run only once each day; this should be changed to
allow user to add as many times as they want nephos to run.

This can be done by allow entries under time and then parsing them and adding
as many scheduler jobs for uploader as the time.

Currently we do not check if nephos has been initiated before the user gives
start command. A check should be established for this.

This issue has multiple options such as we can create nephos as a service, or
create a shell script and add it to cron with @reboot timing parameter.

Drive provides allows different levels of access to emails the data is shared
with. For Nephos, editing access doesn't look good since once the file is
uploaded we barely need to edit it.

Currently, we give all access to read and download the file. Should the user be
allowed to set this while adding share entities?

I don't see a point in storing logs in a database but if this is ever required, it can simply be done by making a class of SQLLogHandler in the logger.py file.

We currently do not display debug logs, but store them in the log file. Maybe we should provide the user with an option to allow viewing these in the terminal itself.

Due to multiprocessing, logs are not working properly inside processes.

Due to adopting a new method of adding upload timing, the old jobs aren't removed; find a way to remove them.

Error handling is an important part and hence each module will have a errors.py which will be called in cases of errors such as not able to authenticate with google or low storage.

They in trun will log the error and even push email if the error is critical.

Use inspiration from the following link.

https://pagure.io/python-daemon/

Currently we depend on a user for authentication; this may be removed by using
a service account and then authentication can be done using email and pass.

Channels are marked down but are never marked up again even if they are good
now.

We should have separate logs for each recording with the output of CCExtractor,
ffmpeg etc and it should be uploaded to drive along with the other processed
files.

Currently, user input can break the program, and hence these errors need to be caught at the moment.

Also, more exception handling is a requirement and should be completed before final submission.

Currently we load nephos files directly and also all the configuration files
are copied only at the runtime. This poses the problem that user can't update
config without running it the first time.

We can change this by separating first_time() from other function.

Currently we do not store the size of the file (can be easily queried using
ffprobe, which we already use) to be processed and hence it has no factor in
how the files go into preprocessing pool. There is no apparent benefit of
taking file size into consideration but it's worth a try to see if there is
improvement in speed.

https://github.com/boennemann/badges

Currently, the module has minimal logging commands. More need to be added at appropriate places.

Functions such as grab_shr_list, grab_ch_list can be aggregated into one.

Currently, after recording a channel and processing it, only .ts file is removed. We should remove .aux files as well, preferable post recording since they aren't used anywhere in pipeline.

Give a warning for wrong email addresses.

Keep templates for jobs, channels and share list and allow the user to load them into the Nephos database using API.

We should upload the logs till now with each uploading job and remove the old log.

Currently, we maintain separate logs for each module; should this remain the same or we maintain a unified log?

This should be done in order to make separate parts of code independent. For eg., we can have a command to edit basic config, and another command to add a job.

A main command will init the main application and keep it running while the other commands will interact with database and other side stuff.

Check if there is any job left in the channel folder, and then remove the
channel when the channel is removed.

Currently when adding a job time has to be specified in "HH:MM" format; change
this to "HHMM".

Move the path of client secrets to the nephos_dir/.client_secrets

Currently, everytime maintenance configuration is changed, nephos needs to be restarted. There is room for an upgradation to loading on the go here with leasing on the resources a bit.

Currently, nephos fails to send critical emails behind a proxy.

Currently This can be seen on the redhen server. This needs to be corrected to work

It would be very helpful to developers if the docstrings are exported as HTML file(s).

Currently, we put the status of the newly added channel as "up" until the next test, this can have repercussions and hence, we should reconsider this.

Currently we do not check if the env variables for set or not, check for this.

The command for setting tag to "processing" and, in exceptions, to reverting it
back to "processed" is not working.

Currently we have to build Drive API everytime a thread is initiated. Find a
way to use already authenticated Drive service.

Currently, the recording module loads it's configuration independent of the
Config handler. This is not an issue but to main uniformity, refactoring should
be done and a class should be made to incorporate loading by Confighandler.

On the failure of a task, task is removed but the folder created for it's storage is not removed. Best would be to make sure that folder is created when the processing script is invoked and it is deleted afterwards on failure.

Currently, get_data() using the pydash package has been defined in many places. We can make this efficient by defining it at a single place and then importing it.

The method of storing processed jobs currently has chances of clashing. It should rather be chan-jobname-date

The wiki has been started and shall be maintained every week, writing down the working of the Nephos.

Currently the imports are not grouped according to their types, we should be
doing it.

Currently, the module doesn't allow addition of single time jobs and repetition
days must be specified for the jobs.

We can allow adding single time jobs, if need be, by changing the insert_jobs
function.

This is a critical bug and needs to be fixed: recordings get terminated at less than 5 minutes even when they are scheduled for longer durations.

Just after recording a stream, check if it's size is greater than zero, if it's not then make that channel down and remove it's recording instead of adding it to task queue.

Currently we rely on the failure of the subprocess command to check if the
recording was successful or not. Instead, we should check the exit code
returned from the command and unless it is 0, do not move further in the
particular method.