A Better Service Experience #29
Comments
|
It has extensions functionality which allow for it to be extended in many different ways, including a providing a tray icon. It is also planning several enhancement features which will improve security of the wrapped service programs. Also using a tray icon as a service host isn't recommended for several Windows environments, they tend to get disabled as their launching slows system operating speed down. Plus they only start when user is logged on, however if they are started from WinSW via an extension then it may not be as bad. Has inbuilt support for mapping SMB shares or other shares in a fashion which services can access. It has deferred file operation functionality which can be of extreme use to Jellyfin. This functionality allows for the possibility to defer the updating of files, while a wrapped program is running. winsw/winsw#439 The nsis installer can easily generate the required config file for the service as it is a form of xml document. This means you can have it create the file based on the users, choices run the appropriate service install action from installer afterwards. |
|
It also causes my anti-malware system to eventually evaluate the impact of the program running from a shortcut in startup group, or from registry in startup and operating speed. Running as actual Windows Service isn't evaluated as it doesn't have an impact on startup speed, also they run when user isn't logged on. |
|
Your current idea of using tray icons also can potentially be a source of problems if running on a host environment which is based around Windows Server Core (e.g. Windows Server 2012 Core, Windows Server 2012 R2 Core, Windows Server 2016 Core, Windows Server 2019 Core etc). As there's no tray area under this environment due not having a full desktop environment install currently. |
I'm sorry, what are you referring to here? I'll address the other comments shortly. |
I mean you can extend the functionality of WinSW with extensions as needed to add any needed functionality. |
|
@MrGrymReaper Okay, I see now that you are referring to WinSW. The way your comment was phrased didn't make this clear at first. Before we continue, let me explain my comment further. In the initial issue post:
Right now we're the unwilling victims of an FFmpeg bug where if FFmpeg is called by an application without access to a desktop environment, it will not be able to run with Hardware Acceleration. For reference, see:
This is why I don't recommend running it as a service, but we still provide the option. Hopefully we or FFmpeg can fix this soon.
Could you highlight what would be beneficial here? On the one hand, we want to move away from external dependencies as much as we can.
Apologies, I wasn't clear here. I'm not saying we will have a tray icon that launches the service, I want to use the code of the app to write a utility that launches Jellyfin in the background, to be used as a service. In practice, that's basically just these lines: Process p = new Process();
p.StartInfo.FileName = _executableFile;
p.StartInfo.CreateNoWindow = true;
p.StartInfo.Arguments = "--noautorunwebapp --datadir \"" + _dataFolder + "\"";
p.Start();
That's the goal here, to make sure it starts in all occasions in a reliable manner. We had thought of some alternatives before (jellyfin/jellyfin#1953), but as I've said, I want to get away from hacks and having to ship two copies of the executable (one that launches silently and one that doesn't). If we control the "launcher", then we can also have it share frameworks that are already in place (see #28). If you look at how WinSW is built (WinSW build.yml), you'll see they're using the same options we did when building the tray app (ref .csproj). We've had so many issues with Publish Single File, that I've had to make a dedicated issue about it (see #27, and I would link all the other issues and threads, but it's not worth it).
Is this referring to sharedDirectoryMapper, and winsw/winsw#538? I will agree that getting shares accessible by the account running the service is tricky, but again, I don't know about introducing a whole dependency for this. I would also want the concerns in 538 to be addressed (and winsw/winsw#439) for that matter.
Is this about automatic updating for Jellyfin? I want to make it super optional, and I've got another thread to talk about it: #30. The key point would be to have a notification first (which would probably be of best use in the server, with a notification/banner in the dashboard). Haven't thought about the mechanism to do it with yet. The automatic updating of WinSW, though potentially useful, would mean I'd have to recreate the config file based on settings, from the server, and potentially re-install the service. Not great.
Yes, but I also can run commands to do this directly with Windows, bypassing WinSW.
It's not, but you knew that. / That's how it's done now, which is why I want to improve this. But, that's only for the tray icon when not in service mode. / That's the goal, and how our current NSSM solution works now (though it's still not great).
As per above, I'm not planning to run a tray icon to run the service. I'm open to ideas, but hopefully this explains some of the motivation behind this, and also provides some understanding of the challenges we face making a software program that is both powerful, and developed in our spare time 😄 |
|
What version of ffmpeg is being used currently as a base for your build? Is it version of ffmpeg 4.1 or newer (preferably 4.2 or a spin off of the git) as the issue may have, been fixed there. Which you reference to in regards to DirectX 9 as practically every fairly new device's GPU now has at least DirectX 11 support present. |
We currently ship a customized FFmpeg for Windows, because it needed to include a fix for segment muxing, which we haven't been able to get upstream yet.
It's 4.2.1.
It hasn't. See https://trac.ffmpeg.org/ticket/7933 (which has a possible solution in comment 3).
GPUs do, but FFmpeg doesn't do that in Intel QSV init, which is the problem. See https://trac.ffmpeg.org/ticket/7511 again, specifically comments 8 & 9. Edit: I should note that GPU accel for nVidia and others seems to work, but QSV is likely to be used by a lot of people too. Edit 2: As per above, shares are tricky, and we've also had to help people debug it. That's why I labelled the service as "for advanced users" in the installer. |
|
Manually copying over the following DDLs (from the Windows Server Installation Media, Sources\install.wim file opened in 7-Zip, check in various single-number folders representing different versions until you locate the one with Desktop Experience, mine was 4) makes the Jellyfin Server work properly on Windows Server Core (2022 Insider Preview) installed as a service. Some might not necessarily be needed, but since it works now, I have no intention of experimenting anymore. System32 and SysWOW64 folders, each its own copies from the installation media (above):
|
Even though using Jellyfin as a Windows service is not recommended, we should take steps to improve this to be more robust for the future.
Improve the Service Host
Temporary Fixes
Improve Logging
This is part of a larger restructuring effort to improve the experience on Windows.
The text was updated successfully, but these errors were encountered: