Is it possible to have the CLI version of Handbrake added to SageTV docker

[wayner]

This would facilitate running transcoding jobs from SJQ without having to install the SJQ client on other computers.

Perhaps a folder could be added under /appdata/sagetv just like there is for comskip.

This pakcage can be found here: https://launchpad.net/~stebbins/+arc...brake-releases

[EnterNoEscape]

Originally Posted by wayner

This would facilitate running transcoding jobs from SJQ without having to install the SJQ client on other computers.

Perhaps a folder could be added under /appdata/sagetv just like there is for comskip.

This pakcage can be found here: https://launchpad.net/~stebbins/+arc...brake-releases

That should work. It would seem like a bit of nonsense to create a specialized SJQ docker for each task you want to do with SJQ, so I like this approach to that end. I'm not sure how the docker authors intended to work with containers that in themselves can be quite modular like SageTV and SJQ which is a plugin for SageTV that is modular itself. One container running the SJQ client with it's own /appdata/sjq_client would probably also be a perfectly sane solution.

[Fuzzy]

You can likely drop the handbrake cli into a subfolder of \\TOWER\appdata\sagetv, which persists. I don't think we should be adding much to the sagetv docker itself that doesn't have to do with core sagetv functions.

[Tiki]

Originally Posted by EnterNoEscape

That should work. It would seem like a bit of nonsense to create a specialized SJQ docker for each task you want to do with SJQ, so I like this approach to that end. I'm not sure how the docker authors intended to work with containers that in themselves can be quite modular like SageTV and SJQ which is a plugin for SageTV that is modular itself. One container running the SJQ client with it's own /appdata/sjq_client would probably also be a perfectly sane solution.

I think we need to install an instance of Docker inside the Sage Docker container, then we can have dockers inside dockers inside dockers...

But seriously I do get your point.

[Fuzzy]

Though, honestly, I think we might want to look into the true desire here. SageTV already has a conversion system. I think if the current system (Ministry) is lacking in something, the ideal solution, now that it is open source, is to determine how it is lacking and improve it.

[stuckless]

Originally Posted by Tiki

I think we need to install an instance of Docker inside the Sage Docker container, then we can have dockers inside dockers inside dockers...

But seriously I do get your point.

You joke... but rather than the docker inside docker, each of these independent "services" are meant to be in a separate container. In an enterprise model where you have an app server and database, as an example, each of these are in a separate docker container, and then they are composed into a solution. unRAID doesn't support "docker compose", but I still think that these types of single purpse solutions should be in their own container and started up if you are using them. Comskip was difference, since it runs in the sagetv space, but SJQ is something that can run in a remote server and be managed completely separate from SageTV.

I don't intend to add handbrake to the SageTV container... but, someone can fork it and add it if they want, but I don't think it something that used enough to warrant it being part of the "core" install.

Something else that people can consider... Handbrake can be created as a plugin and installed via the plugin system (ie, like comskip did/does). So it doesn't need to be in the docker system... but instead, just another plugin.

[Fuzzy]

Originally Posted by stuckless

You joke... but rather than the docker inside docker, each of these independent "services" are meant to be in a separate container. In an enterprise model where you have an app server and database, as an example, each of these are in a separate docker container, and then they are composed into a solution. unRAID doesn't support "docker compose", but I still think that these types of single purpse solutions should be in their own container and started up if you are using them. Comskip was difference, since it runs in the sagetv space, but SJQ is something that can run in a remote server and be managed completely separate from SageTV.

I don't intend to add handbrake to the SageTV container... but, someone can fork it and add it if they want, but I don't think it something that used enough to warrant it being part of the "core" install.

Something else that people can consider... Handbrake can be created as a plugin and installed via the plugin system (ie, like comskip did/does). So it doesn't need to be in the docker system... but instead, just another plugin.

And really, if someone WAS going to go through the effort of forking the docker image and creating one with handbrake in it, they'd be just as well creating a sjq client container on it's own that includes the tools sjq is likely to use. With SLQ already existing in a cilent/server archetecture, this just makes sense.

[Taddeusz]

The Handbrake Docker available through Community Applications has a watch folder. It seems to work pretty well. I think it could use a change to get the watch folder out of appdata.

I can imagine you could add both the watch and output folders to SageTV and create a script to create a symbolic link to the original video in the watch folder.

[wayner]

Originally Posted by Fuzzy

Though, honestly, I think we might want to look into the true desire here. SageTV already has a conversion system. I think if the current system (Ministry) is lacking in something, the ideal solution, now that it is open source, is to determine how it is lacking and improve it.

I haven't looked closely at the SageTV conversion system in a while - has it been updated recently or is it still using old versions of ffmpeg? In an ideal world you would want something that could handle more modern codecs, like H.265, and also take advantage of things like Intel QuickSync, although I don't know if QuickSync is supported in Linux yet.

I did used to use the internal SageTV conversion but I moved away from it several years ago but I can't remember why. I will try using it again on my unRAID server. It may not have had the flexibility that I wanted which is to move the files to folders specific to the names of the show. For example after Micky Mouse Clubhouse is recorded I want it transcoded to mp4 and saved in /videos/Kids' Shows/Mickey Mouse Clubhouse/Mickey Mouse Clubhouse - Mickey Gets a New Car - 123456.mp4. I think the way that things work now is that you may have to hard code the path every time you set up a favorite and then have it use the show name as the destination folder. It would be nice if you could use concepts from the SageAPI, like ShowTitle and EpisodeTitle to generate the new filename - sort of like destination folder and file is "/videos/Kids' Shows/$ShowTitle - S $SeasonNum E $EpisodeNum $EpisodeTitle $AiringID.mp4. That is essentially what SJQ allows you to do.

[wayner]

Originally Posted by Fuzzy

You can likely drop the handbrake cli into a subfolder of \\TOWER\appdata\sagetv, which persists. I don't think we should be adding much to the sagetv docker itself that doesn't have to do with core sagetv functions.

That is likely what I will do is the built-in conversion doesn't do everything that I want.

[Taddeusz]

The built-in ffmpeg is sorely in need of modernization. SageTV as a whole needs to be brought up to modern standards. The Miniclient server should be updated to support a wider range of resolutions, including HD, as well as H.264 compression. Bring it more in line with other solutions.

I find it interesting that if your Android TV device, like the Mi Box, supports HEVC the Android Miniclient will play it. But because ffmpeg is so out of date SageTV itself doesn't recognize the video codec.

[wayner]

We are starting to get way off-topic but I would really like to see Placeshifter be able to properly play all content. It is SO much easier to run PS than a full client install as you don't have to futz around installing some, but not all, plugins, configuring Fanart, etc.

[Fuzzy]

Originally Posted by Taddeusz

The built-in ffmpeg is sorely in need of modernization. SageTV as a whole needs to be brought up to modern standards. The Miniclient server should be updated to support a wider range of resolutions, including HD, as well as H.264 compression. Bring it more in line with other solutions.

I find it interesting that if your Android TV device, like the Mi Box, supports HEVC the Android Miniclient will play it. But because ffmpeg is so out of date SageTV itself doesn't recognize the video codec.

There's no technical reason the built in converter needs to use ffmpeg at all - Ministry could likely be extended to be able to import a list of scripts or other options as jobs as well. It could very well be made to use handbrake if desired.

The ffmpeg issue is just that no one has bothered to go through and make all the changes that were made to customize ffmpeg's use to sagetv to the newer codebase (which is drasticly different than it was back then, it's far beyond simply applying a patch). Some of the custom things may actually be already handled in the new ffmpeg, albeit in a different way that sage would have to be reprogrammed to use. Some things could likely be added to the main ffmpeg distro (like a SageTV mediaserver input/output option to use stv:// urls that sage uses).

[Fuzzy]

Changing placeshifter to use higher resolutions is not difficult, and it's only a few lines to be changed in the code to support it.

[KarylFStein]

Originally Posted by wayner

We are starting to get way off-topic but I would really like to see Placeshifter be able to properly play all content. It is SO much easier to run PS than a full client install as you don't have to futz around installing some, but not all, plugins, configuring Fanart, etc.

+1!

I use PS on all the family laptops/desktops because it's easier to set up and can be used remotely. It getting to be usable again now that I've decided to post-process everything, but sometimes the kids want to watch something live/near-live. I do think it's a benefit to the SageTV ecosystem.

[bialio]

Regarding the builtin conversion system with ffmpeg (which did get SOME updates if I'm reading Narflex right) - all I'm missing is the ability to time limit when it starts conversion tasks.

I've used it to convert mpeg2 recordings to h264 mkv (1/2 the size, same resolution), and it's been pretty flawless so far. But I'd like for it to just run conversion tasks after hours, so to speak...

SJQ is cool, and I now it can do this, but the time factor is really all that I'm missing in the default conversion system. KISS right?

[wayner]

Originally Posted by bialio

SJQ is cool, and I now it can do this, but the time factor is really all that I'm missing in the default conversion system. KISS right?

I still think it would be nice to have more flexibility around renaming files and/or paths for transcoded and archived shows.

Can the default conversion do H.265? That is more of a nice to have than have to have today, but that may change in a couple of years.

[stanger89]

Originally Posted by stuckless

I don't intend to add handbrake to the SageTV container... but, someone can fork it and add it if they want, but I don't think it something that used enough to warrant it being part of the "core" install.

If someone really wanted it "in" SageTV, could they not just make a SageTV plugin that pulls in the executable?

[Fuzzy]

Originally Posted by bialio

Regarding the builtin conversion system with ffmpeg (which did get SOME updates if I'm reading Narflex right) - all I'm missing is the ability to time limit when it starts conversion tasks.

I've used it to convert mpeg2 recordings to h264 mkv (1/2 the size, same resolution), and it's been pretty flawless so far. But I'd like for it to just run conversion tasks after hours, so to speak...

SJQ is cool, and I now it can do this, but the time factor is really all that I'm missing in the default conversion system. KISS right?

I've seen this request before - I'm wondering where the desire to run it during off hours comes from? Not that I'm against that being implemented as an improvement to ministry, just wondering what purpose it serves.

[bialio]

The CPU on the server is pegged at 100% when transcoding. I don't have a warm @Fuzzy with that while recordings are going on....