[Feature Request] disable transcode on localhost and waking up remote machines
Kakoluz opened this issue · 3 comments
I've been using rffmpeg for a week or so on a jellyfin server running on a raspberry pi 400 (the one that is a keyboard) and it's been great being able to use a few remote pcs to transcode. But there is a few things i'd like to have added if possible natively to this so it can be used more widely.
I will start by having an option to differenciate betweeen a screen grabber and a full transcode, the screen grabber runs slow but fine on the pi itself, but trancode is impossible. it would be nice to default taking pictures to localhost and not enable transcode to happen on the server. instead of this if it is too hard to know if its just screen grabbing a feature to disable localhost as a backup, as i prefer having no video to the one being rendered on the pi.
The other thing that is a nice to have is (for me atleast) the remote servers on sleep mode, i edited the script adding a wakeonlan call to wake all the servers from sleep before selecting one. This works relatively fine, but waking every server is somewhat a burden as it may wake a server that is going to get no work.
dding a mac adress field to the config file and sending a magic packet to that machine before pinging for availability would be great (would write the code myself but i am a novice in python) it may also be needed a thread.sleep call to wait for the remote machine to fully wakeup.
Setting things up this way allows one to save on power consuption, noise and heat if running at home as i do. The drawback is that it may also include some troubles with the dead host remote marking procedures as i've encountered that sometimes a reboot needed on the pi as rffmpeg refuses to send thing remotely saying that it's not available, even if the remote machine is running at idle not even being on sleep.
Also, I have written a script that can be ran remotely to check if a machine is running ffmpeg and suspend it if its not, could be ran as a cancel encode procedure o as i do as a cronjob every x minutes
Edit: typos and text clarity
So I'm going to sound like a bit of a hardass, but I think this is getting a bit out of scope for the tool.
I'm pretty against option 1 because that gets into "doing stuff based off the ffmpeg arguments" which is just a rabbit hole I don't want the tool to go down; it will get extremely complex very quickly.
I have some sympathy for 2 as an option, but because I think you want it because of 1 I'm not sure it's really worthwhile except in some very very niche usecases, and it does have a lot of drawbacks. It might be better to just wrap rffmpeg's calls in another script, like
#!/usr/bin/env bash
check_if_remote_host_is_alive
if [[ $? -ne 0 ]]; then
wake_on_lan $remote_host
wait_for_alive
fi
/path/to/rffmpeg/ffmpeg $@
Though keep in mind that this will seriously delay the start-of-playback time for any media you play, since if we're talking about a physical machine it could take anywhere from 10 to 60 seconds for it to boot and get ready. This is probably the biggest drawback of this idea, and you're going to end up powercycling the server a lot if there's ever more than one user using it. I did debate adding WoL functionality much earlier on, but decided against it for this reason - it just ends up being not worthwhile to deal with the added complexity and logic for what is a pretty niche usecase (see below for why I think so).
Your setup seems to me to be a bit of an X-Y problem. Running Jellyfin on a Pi is fine, but the "not powerful enough to transcode" is pretty much it's big drawback; generally we just say "if you use a Pi, pre-encode your media in a format that your clients can use and direct play it", thus avoiding on-demand transcoding alltogether. rffmpeg isn't really meant - at least for the reasons I created it - to mitigate that issue; it can as a nice side effect, but it really assumes that the remote machine is just always on and ready to go, which as you mention negates the power savings of running Jellyfin on a Pi. For a bit of context I made it to offload hardware transcoding from a VM to a GPU-enabled always-on server I use as a virtual desktop, because my hypervisor setup won't easily support passing a GPU into the VM. It scratches that particular itch of mine, and the fact it helps so many other people is just a happy accident :-)
If you really want on-demand transcoding and low power usage, what I'd really recommend instead is to just get a low-power x86 machine with a decent iGPU (i.e. any relatively recent Intel-based box or an AMD APU) and use that machine for Jellyfin. Something like a NUC, LattePanda, UDOO, TinyMiniMicro, etc. You'll still get great power savings (using only a few to a few tens of watts of power) and be able to actually transcode on-machine, no rffmpeg required. And you could just WoL it whenever you want to watch and shut it down later when no one is watching, assuming that it's just for Jellyin (careful or you'll start self-hosting more stuff!)
I hope that makes sense and doesn't come off as too mean - I empathize with the situation but it definitely seems like a lot for rffmpeg to do.
The other thing that is a nice to have is (for me atleast) the remote servers on sleep mode, i edited the script adding a wakeonlan call to wake all the servers from sleep before selecting one. This works relatively fine, but waking every server is somewhat a burden as it may wake a server that is going to get no work. dding a mac adress field to the config file and sending a magic packet to that machine before pinging for availability would be great (would write the code myself but i am a novice in python) it may also be needed a thread.sleep call to wait for the remote machine to fully wakeup.
Setting things up this way allows one to save on power consuption, noise and heat if running at home as i do. The drawback is that it may also include some troubles with the dead host remote marking procedures as i've encountered that sometimes a reboot needed on the pi as rffmpeg refuses to send thing remotely saying that it's not available, even if the remote machine is running at idle not even being on sleep.
Also, I have written a script that can be ran remotely to check if a machine is running ffmpeg and suspend it if its not, could be ran as a cancel encode procedure o as i do as a cronjob every x minutes
Any chance of sharing this? I believe this is a fundamental requirement of such an application. Most clients on a LAN will natively play Jellyfin streams. It’s only really the Apple devices, and devices which are located outside of the network, which will require transcoding services. There’s no point powering a transcoding server 24/7 for a few outliers.
this would be useful
if remote is only in S3 sleep WoL wake can be very fast - a few seconds