(Due to Eroscript upload limitations, high-quality videos cannot be uploaded, so a compressed version is included here. You can find the original video and full materials on Patreon and the newly launched landing page.)
This update focuses on making everyday playback smoother, smarter, and more customizable — especially for larger media libraries and no-script content.
Highlights
Random fallback strokes (No-script support)
Playback now stays usable even when no script is available.
Updated core dependencies (React / Vite / Electron)
Verification
tsc --noEmit
vite build
Windows / Linux builds verified
Runtime testing completed
Thanks for supporting ScriptPlayer+
A new Patreon page (for support) and a landing page have been launched. You can find higher-quality videos and more detailed information on those pages.
I tested it in the current version by loading subtitles, and they were displayed correctly. The subtitle file must match the video title, and some subtitles may not be recognized. If a subtitle is not detected, you can right-click to manually load the subtitle file.
am i allowed to post my fork that has extra features i implemented for myself that i think people may find useful? i understand if you do not agree but i figure i mind as well let others use what i made.
We do not restrict free forking under any circumstances, as intended by the license. However, using the fork for commercial purposes is strictly prohibited.
I just wanted to be sure it’s OK that I post it here. Thanks. I will do post it and link to this as well, I have modified the readme to reflect that I am maintaining a fork.
I don’t pay too much attention to forks, but I still believe it’s better if you provide feature feedback instead. When I release a new version, I usually include a large number of features, so even if you fork the current version and add a few features, the difference between the two will grow significantly within a few days.
From a user’s perspective, it’s also better to use a program that continues to receive stable updates. For simpler features, they are usually implemented and applied within 1–2 days anyway.
I also receive bug reports on a daily basis, identify new issues, and fix them quickly with hotfix releases. Because of this, it may actually be more helpful if you provide feedback on new feature improvements or report bugs directly here.
I’ve already done that, however it was rejected and I was not trying to wait to get the things I wanted implemented to be released. So I changed the fork to suit my needs. I have had no issues with the process I have had, and I am not likely adding any extra features that ibhave not already, if you implement the ones I have done then I will use those. I also noticed you closed Issues which were feature requests and did not implement them, so forgive me but I don’t believe you, but from what I’ve seen, I won’t give feedback if it’s not being implemented.
Don’t get me wrong, I agree with the stable updates being better for the users. But I also have features that I think are far more useful, and should be apart of a player from the beginning and I felt it was a priority, so I decided to do it myself.
Feel free to look at what changes I did in my repo to see what features I wanted and how it was implemented for ideas.
Sorry, but the content you mentioned has already been suggested through issues and has either been implemented in previous releases or is already applied.
As for the reason why the PR was not accepted, as I mentioned before, making large-scale changes that only focus on what is visible can lead to irreversible bugs and issues later on. I recently attempted to update the builder and dependencies, but as expected, simply changing dependency versions caused the build to fail entirely. Because of this, I had to design a completely new build workflow. However, AI-generated PRs do not mention or account for these kinds of underlying changes at all, which is why I do not rely on AI for full PR contributions.
Additionally, all work must be implemented one at a time, and every change must be verified to ensure there are no issues with basic functionality or the build before being applied. If that PR had been merged, it is highly likely that it would have introduced a large number of critical, unrecoverable bugs into the project.
Of course, not every suggestion can be accepted. While some features may be useful to certain users, they can also cause broader issues across the player or negatively impact performance and optimization. For this reason, it is not possible to accept all suggestions. I am continuously improving the project by fixing bugs on a daily basis as new features are added.
Forking this project for personal modification and uploading it to GitHub is fine. However, if you distribute it with an introduction or promotional post, there can be potential licensing issues. The source must be clearly credited, it must not create confusion with the original project, it must not include monetization elements tied to the fork, and it must not use the same project name.
again, i understand the cause for the PR denial, i was not talking about the PR. i also dont see how #5 was implemented at all in any version. but thats fine thats why i made a fork, you can look at the fork to see if it violates anything before i post it here, if you look at your forks, my github is technomooney. i have, as far as i can tell, made it clear that my fork is not the same as the original. feel free to tell me if i need to change something before i post as a new thread on ES. i already saw the license and i wouldnt be asking for money for anything i make at this point anyways, regardless if it was 100% coded by me or not.
also as far as i could see after my modifications and before your latest update, local builds worked fine, it was the GitHub actions/workflows that were failing, i was working on that as well to update it but then you fixed it before i had time to fix it. from what i could see the workflows were using an old way of doing things which was fixed on the newest build. which i appreciate. i was not even looking at the gitgub actions when i did that pr as i had never used it before, after you denied it i went back to look and see why i was not getting any releases even when i triggered the workflows. i was working on other projects till today.
in regards to performance i am unsure what you are talking about there with this app, its essentially a web app, at least with performance related metrics. so i dont really know what you are trying to say there. i know if this was a large scale project that had hundreds of micro-services then yeah i would be far more careful and more atomic with my changes and tests. so i am unsure if you are targeting raspberry pi level specs or something but i would appreciate a bit more information on your performance requirements and tests.
anyway, i think our the designs for the features i suggested are very different. i encourage you to look at my fork and see what i meant with some of them, plus this is just a hobby for me and due to running Linux on everything now i cant use the tools i used to, so ive been making my own based on existing projects. if i can help others with what i make then i would like to do so.
i will try to add translations for the parts i added as well.
i wont be able to respond anytime soon, i need to get to bed, i am 5 hours past my bed time! XD