intro-skipper
intro-skipper copied to clipboard
jumoog
Segment Editor Graphical UI
Hey, there is another Jellyfin Tool and plugin called Media Analyzer with quite the same functionality but with an additional feature, a visual segment editor. But the whole setup process for this plugin is quite complicated since you have to use a custom Jellyfin instance, which is not so easy if you have a perfectly configured instance already set up. Your plugin is working with an API too, so my question is if you could increase this functionality to enable compatibility with this segment editor?
I just saw you already have more endpoints than documented in your API docs. At least I think so, I'm not experienced in C# development. So are there already suitable endpoints to use with the editor?
One of the common misunderstandings is that Jellyfin Vue makes that UI possible. It is not the plugin generating it out of thin air. While we do plan to improve the UI, we actually have to create it.
Sorry? I'm afraid I don't really know what you are talking about. I never mentioned Jellyfin Vue in any way. The only idea I tried to suggest was to add more endpoints to this plugin to allow using it with (a forked and adjusted) segment editor by endrl.
I think you may have misread my statement or didn't check the requirements for the plugin you're referencing.
I have installed two instances rn. One normal one and one with the media analyzer. I thought that the media analyzer, JF Vue and the segment editor are three different projects. So that the segment editor (ghcr.io/endrl/jellyfin-se:latest) is a standalone container which creates a web interface to connect to the media segments API? That's how I came to this idea to keep this plugins functionality and just add the endpoints to add and delete segments and then using it with the SE Web editor?
The container you have with the editor is built on top of Jellyfin Vue.
But it's still a standalone container, right? So when one would adjust it to possible endpoints for this plugin and spin the container up, it should work in my theory, or not?
It's been modified. We'd either have to change all of our code to match the renaming done to media analyzer (and toss all of the additional functionality we have over it) or break down the container and modify it to fit our plugin. Either way, it is a lot of excess work on our end and on the end user's because now everyone is stuck running that container.
Yes, that's what I thought about. Adding an API here to allow viewing, which is already possible I think, adding and deleting segments. Then adjusting the SE to match your API endpoints. In the API, you should be able to write the services to match the current functionality of this plugin. The segments are stored somewhere anyway, right? So the API could just allow adding etc. them. In theory there shouldn't be too much editing in the SE necessary, since overall it's just a frontend interacting with an API, or do I miss sth?
The short version is that trying to modify that container to work with this plugin is a waste of time. The only thing it will solve is having a visual editor just a tiny bit sooner.
And the long version? Don't get me wrong, I'm just interested in combining these two projects somehow. And wdym with “bit sooner”? Is there a visual editor planned here?
While we do plan to improve the UI, we actually have to create it.
The long version is that it's not a viable solution for the average user. It's a shortcut to save time that will end up being a source of bugs and instability. It relies on an experimental UI that most have no reason to install otherwise. I could give a whole elaborate explanation, but is that really going to be the best use of time? Wouldn't it be better spent working on the UI?
Okay I didn't know that, then it surely makes no sense to adapt the SE. Is there roughly an ETA?
I'm going to close this feature request for now, as it won't be interesting until the segments arrive.
