Running as a service / automatic exports

[zarko-a]

Not an issue, rather a feature request and/or a question. Do you plan to add option to run Tablo Tools as a service in the background?

Expected Behavior

Having the ability to run Tablo Tools in the background as a service. Specifically to allow automatic export of new recordings. This can be a schedule where the episode catalog is refreshed on a specified interval, if new recording is detected it is exported and optionally deleted from Tablo.

This would help everyone who doesn't have a huge storage attached to Tablo but rather uses a NAS to store media.

Another feature that goes hand in hand with automatic exporting is notifications. Not to waste to much of your time developing something like this, it should be more than enough to just have a pre and post export hooks. Ability to call a script and passing on a couple of arguments, like the recording name and exported file path. That would allow lot of flexibility if some wants to post-process the file, like move it to a different folder or extract closed captions...

Current Behavior

Recording exports require manual action by a person.

Possible Solution

Ideally (my personal preference), Tablo Tools "service" would run as a docker container instead of systemd service. Not sure if AppImage supports running as a service. Generally, docker is gaining a lot of popularity in recent years, but especially in cord cutting community.

If you are interested in something like this, I might be able to provide some help in creating a docker conainer.

Steps to Reproduce (for bugs)

N/A

Your Environment

N/A

[dougK44883]

I don't believe tablo-tools is truly a "stand-alone" application running a process as you suggest. It appears to be a pre-packaged version of chromium browser, with great customization and of course tablo-api-js for tablo specific functions.

Then again jessedp is talented who knows what he'll come up with.

[jessedp]

I hadn't considered a docker image at that point, but I may very well take you up on that offer (or what I mention at the end).

I certainly have automatic exports in mind and it should be the next big feature. I think. Here's what I'm currently thinking/doing in preparation:

Saved Searches - I added these mostly with auto export in mind. I still need to build out managing them a good bit. Aside from your prettily-named search, there'd be at least be a cli-friendly slug (My Wayne Brady Search => my-wayne-brady-search).

CLI - I've done some PoC tests and it seems to work as without the browser, which means I can do almost anything with a tiny amount of extra lifting. And yes, that means we'll be running a 60+ meg binary with a who knows how ridiculous memory footprint.

Export Tracking - This isn't completely necessary, but the idea is to keep completely separate dbs of export/logging info so it would know/could show all the times you exported something, the full log for it, and whatever else seems to make sense.

Export Options - Overwrite Existing files? SomeFile before/after a Date (this is a Search Filter)? More? I might combine this with Saved Searches. Or it could have it's own slug and be used in combination/attached to a Saved Search. When added, it could also have options for data tracked by the Export Tracking.

So it could be:

# tablo-tools --saved-search my-wayne-brady-search

# tablo-tools --save-search my-wayne-brady-search --overwrite --after 20150213000000

# tablo-tools --saved-search my-wayne-brady-search --export-profile my-first-profile

Or a bevy of combinations/variations. For my sanity, I'd probably rather not make those available as individual options, but that should be okay since the slug-based version will be easily configurable in the UI (which you're going to have to use at some point somewhere). I'll probably put a ---rebuild option with some smartness, though.

My thought then was to of course show what should be the full proper command in-app to make it easier to schedule yourself in your typical system scheduler. Or try to figure out how to do that automatically via shell commands (probably not).

So the docker image is a great idea, especially for someone who know how to use it, and with CLI that should be completely possible. Aside from any network shares, it would also need access to all of the .cfg and .db files from the host fs - I guess mounting/replacing the ~/.config/tablo-tools/ directory with it. That could be weird and I may need to move files around to make it easier.

I'm definitely not terribly familiar with what would be optimal for keeping that updated. If it's more than instructions on the README, I can probably stick it somewhere in the build process and even publish somewhere it if that makes sense.

Finally, since I'm going to run the exact same binary for the CLI, it would certainly suffice to get an image working that simply installs/loads a current version of the app that you can pass (useless, test) arguments. If that binary starts to load and prints good stuff before it dies, it'll probably be good. No idea if the AppImage will work (chmod +x it) or the deb/rpm would be easier or smaller (base image+supporting libs+tablo tools). But if it works, optimization is always a possibility.

Wheeewww. All that said, I'm working on finishing the next release (mostly a more global selection system) - I should have betas ready in the next day or so. As I mentioned, this stuff should come after and I don't think it's more than a few days or work, but who knows.

[dougK44883]

If this can be run from CLI that means shell scripts! In turn scheduled tasks / from jobs which could somewhat negate a service.

If ttablo-tools lets me specify specific filenames (variables are great) form CLI bulk export, it could be ran nightly. Not everyone sort movies, sport, series or wants every show recorded in its own folder... or bother with the title of a sitcom in a filename

[jessedp]

v0.3.0-beta.1 has the first version of this to mess with