osc.lua: display seekbar hover time as property for other lua scripts

[ghost]

right now mpv osc does not make time of mouse hovering on seekbar accessible by other scripts, this change Adds functionality to mouse hover time in seconds to be used by other scripts using a property, useful for thumbnail creation scripts.

from now on people can use this property
${user-data/osc/hover_mouse_time}

it will give hover time in seconds when mouse is on seekbar otherwise none when mouse is outside seekbar

if this property user-data/osc/hover_mouse_time is approved then people don't need to use outdated osc.lua from thumbfast script as it lacks many updated features of original osc.lua of mpv

and i have made this thumbnail script simple_thumb_v1a.lua, just save it to scripts folder and thats it, it works on my system, windows 11 latest as of today,

https://github.com/xdev23/mpv-scripts/blob/main/simple_thumb_v1a.lua

it works similiar to the thumbfast by spawning a hidden mpv process, but works with latest updated osc

edit: fixed issues from last failed commit

i made a mess during commit as it is my first pr on github, i just did without knowing, maintainers sorry for that

[N-R-K]

llyyr | someone tell them they can force push instead of deleting and restoring a branch

[ghost]

llyyr | someone tell them they can force push instead of deleting and restoring a branch

it is my first time using PR so i was just checking, i should not have done all these, i was learning but it all became mess, sorry

[N-R-K]

I do not like this. The UI script should have control over where to draw the thumbnail, this makes it the thumbnailers job to draw as well.

For practical example, on mfpbar I draw a (configurable) border around the thumbnail. The thumbnail position also needs to be adjusted based on whether the video has a chapter or not.

[avih]

I do not like this. The UI script should have control over where to draw the thumbnail, this makes it the thumbnailers job to draw as well.

The way I see it, the point of this PR is to remove this concern from the UI's responsibility, and onto a 3rd party script which can use this info and expose its own configurability over this matter.

Without understanding fully what such interface might be (where the UI controls if, where, and how to place the thumbnail), I would think that this PR is a strict subset of it. I.e. any such interface would have to include a way for a script to know which time-pos is being hovered at the UI.

So this PR provides only this part, while leaving other aspects of this more-complete interface to be defined (and implemented!) in the future, and without obvious conflicts that I can think of between what this PR does, and what a full interface would do.

Don't you agree?

EDIT:
To clarify, the value I see in this PRs approach is that it allows 3rd party scripts to start do useful things right now, it integrates trivially at the osc, and doesn't put any maintenance burden on the osc maintainers.

This is indeed a very loose interface, but it has both pros and cons. The main pro is that it's trivially simple to add to the osc and to use by 3rd party scripts. The con is that the OSC has no control over what 3rd party scripts might do with it, which might interfere with the osc somehow, or suffer from loose integration otherwise.

But the flip side of that con is also a pro - scripts are not bounded by interface implementation and limitations at the osc. Any new feature which a script wants to add, like bouncing baloons around the thumbnail - they can do right now, without having to wait for the osc maintrainers to agree that bouncing baloons should be part of the interface, and then enhance the interface to support it, and add the user configurability via the osc, etc.

It really decouples these concerns from the osc, while providing the asolute minimum which a 3rd party script needs in order to start doing useful things with thumbnails.

[avih]

@xdev23 thanks for the PR. I think it's interesting, and potentially useful.

Mandatory question: did you write the code yourself? can you comfortably edit it yourself to address review comments?

For instance, the way it's placed currently at the code is not ideal IMO. It's placed between the comment which describes the title-on-hover code - and the code itself which implements it.

Second thing, it duplicates the whole title-hover code skeleton, but this new code runs unconditionally and without user control - unlike the title-hover code.

Thirdly, if we're to accept this PR, then these two things need to be merged somehow (the PR code and the existing title-hover code) while reducing duplication to minimum.

And finally, an interesting concern came up, where apparently this PR increases the render() function duration by about 10%, where most of this time is spent at setting the user-data/osc/hover_mouse_time property.

Any alternative measurement numbers are welcome.

So except the last performance issue, can you address these concerns on your own?

[ghost]

@N-R-K

i know both of your questions are valid, i did thought of having to add border and chapter titles below thumbnails but i don't think that is possible to do directly with osc, as it is already too complex,

i am requesting property ${user-data/osc/hover_mouse_time} in osc because we can use mouse-pos to draw thumbnail and the border and chapters can be easily managed by that but important thing is to get the value of seek hover-time from image, whenever we are on seekbar time is shown with mouse but it is not exposed like time-pos my idea is to just get that hover-time, that's it, that is exactly the property i am requesting to add,

now to answer @avih question i did use ai to understand what/where exactly i need to change otherwise to understand what ae or se are will just take too much time

i don't know much about performance problem but i think calling mp.set_property_number blindly in render() is spamming and can cause that 10% lag you talked.

i have pushed an update

I merged the property into the existing title-hover block. i did not have any video with chapter so could not check it, but i tested there was issue, but it should be working as excepted now, my script what i am using for testing with this property simple_thumb_v1a.lua

I added a last_hover_possec variable to internal states. now, the property is only updated if the hover time changes by more than 0.1 seconds, and it clears the property to none once when the mouse exits seekbar area. so i don't think there should be any more render() function slow down.

i also added mp.set_property("user-data/osc/hover_mouse_time", "none" in line 3047 so mpv doesn't show error instead of none when file is loaded

[avih]

@avih

i know both of your questions are valid, i did thought of having to add border and chapter titles below thumbnails but i don't think that is possible to do directly with osc, as it is already too complex,

I never asked anything about border or rendering of anything at the OSC.

I was talking about where the code is positioned.

Before the PR the code looked like this:

• Comment about the chapter-hover.
• Code for chapter-hover.

But the PR added the new code just between those parts, which made it:

• Comment about the chapter-hover.
• New code of the PR.
• Code for chapter-hover.

But what I did ask first, very very clearly, and which I do expect you to answer is:

Mandatory question: did you write the code yourself? can you comfortably edit it yourself to address review comments?

can you address these concerns on your own?

I asked specifically who wrote the code, and whether you could address these issues on your own.

Did you do that on your own?

I also point you to the contribution guidelines which have this section:

mpv/DOCS/contribute.md

Lines 264 to 268 in f9190e5

	AI-assisted Contributions
	-------------------------
	If you have used an AI/LLM for your contribution, you must disclose this in the
	PR description. Such contributions are not forbidden, but the submitter takes

[ghost]

now to answer @N-R-K question i did use ai to understand what/where exactly i need to change otherwise to understand what ae or se are will just take too much time

i did use ai help, and i have disclosed , sorry i made wrong mentions n-r-k asked about border and chapters, and you asked about this ai and performance things

[avih]

i did use ai help, and i have disclosed

I might have missed it, but I've read your first comment few times and I can't see it.

Where did you disclose it? How much of it is AI, and how much did you write or fix on your own?

Also, you still didn't answer my question of whether you can do these fixes on your own - without AI.

[ghost]

come on bro @avih , read this #17510 (comment) i have mentioned everything here

your question

Where did you disclose it? How much of it is AI, and how much did you write or fix on your own?

i have written in #17510 (comment)

i did use ai to understand what/where exactly i need to change otherwise to understand what ae or se are will just take too much time,

my reply meant that i have used ai to understand the osc code, but i did write code on my own, i used ai to know what existing variables do, are they what i need, i have also read the code myself to verify that what ai said is right, it is more than 3k like of code, without ai it will probably take 2-3 days to understand it

next question

Also, you still didn't answer my question of whether you can do these fixes on your own - without AI.

yes i can do changes on my own without ai,

[ghost]

@N-R-K

since you are using my simple_thumb_v1b.lua script then i assume that you are using osc.lua with my PR saved in scripts folder

you see i have changed a hell lot of things in my thumbnail script without affecting osc.lua
i hope now you understand that the problems you were describing were nothing at all,

download the script again simple_thumb_v1b.lua

you can't use fixed preview height if it is not top or bottom bar it will use mouse-pos y coordinates then add 60 offset, you will know when you try

my script creates ${user-data/osc/hovered-time} property from osc.lua then it can be easily used with mp.observe_property() and it will do all the work

i haope maintainer @avih and @kasper93 push my pr to master and we will be able to delete the osc.lua from scripts folder and any new update from community to osc will be available unlike outdated osc.lua of thumbfast script,

2026-03-07.21-57-41.mp4

[avih]

@xdev23 I'm not worrying about the code because even if there are issues, they would be simple to fix.

The discussion is about which approach is best here.

Your PR suggests to expose only the hover-time-pos, and let other scripts do the rest.

The other approach is that the OSC should control most of the things, and specifically the position, while the script should mainly be responsible to do the actual thumbnail.

And maybe there are other approaches which would be good.

So it's about deciding which approach is best, while trying to take important considerations into account, and also think what are the implications of each approach for the future.

For some reason there were a lot of misunderstandings in this PR, and that didn't help. It also doesn't help that we don't actually know how experienced and capable you are with writing code on your own and making informed decisions. Maybe you're great at those, but it didn't show up so far.

So it happens that someone else opened another PR with the same goal but a different approach. There's also a lot of discussion there.

Again, the issue is deciding what we want to do, and you're welcome to participate in this discussion.

Once we decide that, and we actually know what we want to do, then writing the code will not be a problem. The code will be simple with any solution. The hard part is deciding which solution is best.

[llyyr]

@xdev23 You're fundamentally misunderstanding the point NRK is making. With your proposed API, the thumbnailer script is responsible for positioning the thumbnail preview which is simply not feasible across every single layout out there.

If we're going to make an official API for this, it should be good enough to work with any layout or OSC script, not just the ones blessed by your script.

[ghost]

@avih

ok now i understand the issue from #17510 (comment)

Approach 1: my approch is open a property ${user-data/osc/hovered-time} and let customs scripts decide what to do instead of osc,

Approach 2: it is to let osc control all settings of other scripts and let those scripts be free,

i will stick with my approach, because osc is already to big, there are already too many controls, if someone were to decide they want to create some script, so would you add settings of that 3rd party script to osc, hell no, this doesn't make sense at all, as it will only make osc more crowded, it is not sustainable at all

why do you even want to add settings of a 3rd part script to osc, if user doesn't use that script that code in osc is useless

you must open key features as property like i requested for ${user-data/osc/hovered-time} so they can be accessed by other scripts, and let other developers do whatever they want,, it is a very practical approach,

[avih]

you must open key features as property like i requested for ${user-data/osc/hovered-time} so they can be accessed by other scripts, and let other developers do whatever they want,, it is a very practical approach, why do you even want to add settings of a 3rd part script to osd, if user doesn't use that script that code in osd is useless

There's no "must" here, and there's more than one valid opinion, and there are pros and cons to both sides, and, as noted, there might even be other approaches which we didn't consider yet.

This is why we're discussing it. We're trying to find the best solution.

[ghost]

@llyyr

you are wrong with my api, with my api everything will be done by my script not by osc,

i don't care about 3rd party layouts, i like and use default osd.lua of mpv, and my thumbnail script simple_thumb_v1b.lua already works with these layouts: box, slimbox, bottombar, topbar because it have full control, if i want to change any thing i won't have to touch osc.lua if maintainers just add my proposed property ${user-data/osc/hovered-time}

i think you guys are confused about my new approach , you must read this #17510 (comment) then my reply #17510 (comment)

you will understand i am not wrong at all,

[na-na-hi]

So it's about deciding which approach is best, while trying to take important considerations into account, and also think what are the implications of each approach for the future.

Is there any viable approach without thumbnailer knowing hover-time-pos? If not, then this PR is in the correct direction no matter what approach is taken. Other information can be added later.

[afishhh]

why do you even want to add settings of a 3rd part script to osd

Because logically the thumbnail is very much part of the osd. If thumbnail layout is handled by a non-osd "3rd party script" then that 3rd party script must support your osd configuration or it will look out of place. So if I decide to make an osd with a red background for the seek bar and want to have the thumbnail preview have a matching border then (with your approach) this osd depends on the thumbnailng script supporting this layout/styling functionality.

However if we instead move layout to the osd implementation (by providing the thumbnailer with the destination rectangle, or imo even better do what the script kasper93 mentioned here does) we now have layout consistently done by a single script. This means the osd can remain coherent irrespective of the thumbnailer implementation. (side note: why does thumbfast not use the "pass file path" approach? is it just due to it making things more complicated?)

This is basically a question of "should the osd share layout information with the thumbnailer or should the thumbnailer share thumbnails with the osd".

Personally the second approach seems more natural and involves sharing less state between scripts. Though of course equivalently the thumbnailer could just implement every customization option under the sun and effectively function as a sort of "UI component library" but that could just be a thing on top of the base thumbnailer API and doesn't feel right as any sort of "official API".

Is there any viable approach without thumbnailer knowing hover-time-pos?

It has to know the time to thumbnail but it can be provided as an event instead of a property (which seems to better match the problem but maybe there's a reason thumbfast uses a property it uses a script-message).

---

Maybe I'm making too many assumptions but https://github.com/occivink/mpv-gallery-view/blob/4a8e664d52679fff3f05f29aa7a54b86150704bc/scripts/gallery-thumbgen.lua just seems like a much better direction? Please correct me if I'm wrong.

edit: @N-R-K pointed out on IRC that thumbfast's API when using the thumbfast-render mechanism is basically what I want. Maybe we should figure out a subset of what already works and implement support for that in the OSD?

[ghost]

@avih

you guys are maintainers, in the end choice will be yours, implementing a api or property is easier then to maintain code for others, which will only increase your burden instead you could add new features in mpv

the confusion between choices is maybe because i am the first person who actually asked to create a property inside osc.lua,

i hope you understand that i am not making a invalid request,

creating a property like ${user-data/osc/hovered-time} is important too if we want to get correct image preview of a timestamp where mouse is hovering

i do hope that my PR is merged😑, right now i feel like i am asking for something that everyone is against but they know they need it but taboo to ask

[avih]

Is there any viable approach without thumbnailer knowing hover-time-pos? If not, then this PR is in the correct direction no matter what approach is taken. Other information can be added later.

I've said several times, in very similar words to yours, that I'm on the side which thinks that the approach in this PR is viable as a first step, and we can enhance it in the future as new needs reveal themselves.

The fear with this approach (which I don't share) is that it leaves too much freedom to the script, but without enough knowledge to ensure the script can use it safely and reasonably, and therefore it's a bad interface.

So if some maintainers (defined loosely, you're included for that matter) insist that it's not a viable first step, then it's worth further discussion to see if we could find a solution which more people are happy with.

[ghost]

freedom to the script

@avih
can you elaborate this line freedom to the script and viable first step

if i understand correctly you mean, that other scripts affect osc.lua, and you might have to implement some weird things.

look at my script simple_thumb_v1b.lua i am using overlay-add, overlay-remvoe, mp.create_osd_overlay(ass-events) these are parts of mpv not osc.lua.

i am drawing my own osc overlay for thumbnail preview which is not affecting osc.lua at all, all my script needs is a hovered-value using ${user-data/osc/hovered-time} from original osc.lua, and this is what all my PR is just make hover value a property

if in future when mpv updates and thumbfast script with its custom osc.lua stops working, then to show thumbnail you will need hover time property from main mpv's osc.lua that my script needs right now, my script simple_thumb_v1b.lua don't need any custom osc.lua as long as maintainer allows a hover time property ${user-data/osc/hovered-time} with my PR, so my PR is a future safe PR too, i am only contributing to community

i am not making unreasonable request,

i don't know why people are so concerned even though i have explained everything clearly

[avih]

can you elaborate this line freedom to the script and viable first step

The discussion is about how much freedom mpv should give to scripts, and how much it should try to control.

If it's too much freedom or too little information which scripts can use, then it can result in scripts which actualy interfere badly with mpv, but if it's too little freedom, then it limits what scripts can do.

The "trick" is to find a balance which is great for everyone. And it's not always easy.

As for "viable first step", it means I think this PR is OK.

i am drawing my own osc overlay for thumbnail preview which is not affecting osc.lua at all, all my script needs is ...

Yes, it's fine for YOUR script. But the code which we add in mpv should be good for everyone. Not just you.

And in this case, I also agree with others that this much freedom on its own can result in bad interference with mpv. Because the script cannot know where the OSC is. Even if it wants to be responsible and behave nicely and not draw over the OSC - it just cannot do that, because it doesn't know where the OSC is on screen.

if in future when mpv updates and thumbfast script with its custom osc.lua stops working, then to show thumbnail you will need hover time property from main mpv's osc.lua that my script needs right now,

You care about what your script needs right now. We care about what is good for mpv and for mpv users now and in the future.

The reasons we're discussing this subject is because we think it has potential to be good for mpv and the users too. Maybe not exactly what you need right now, but we hope to find a solution which will be good for mpv and users and you too.

But it takes time and discussions to find a solution which is good for many people.

i don't know why people are so concerned even though i have explained everything clearly

You explained clearly enough, but it doesn't mean that everyone has to agree with you. It's OK, sometimes people disagree.

[kasper93]

So it's about deciding which approach is best, while trying to take important considerations into account, and also think what are the implications of each approach for the future.

Is there any viable approach without thumbnailer knowing hover-time-pos? If not, then this PR is in the correct direction no matter what approach is taken. Other information can be added later.

I don't think hover-time-pos should be broadcast or observed by the thumbnailer script. Thumbnail drawing should be imperative from the UI/OSC. hover-time-pos does not need to be known by any external script, when image is not requested. It should be the OSC's decision to request and draw an image at any given point.

Imagine the situation that you move the mouse to different place on timeline, but OSC for whatever reason decides that image shouldn't be drawn at this point in time. Should it not update hover-time-pos? Should it unset hover-time-pos? We don't know, because it depends on the implementation detail of external script how hover-time-pos is consumed. It's is just bad interface, a hack, that suites certain implementation. There is no clear module separation, no clear API definition, just a hover-time-pos broadcast into the air, and hope that things magically happen.

See also, for the part one: #17518 (comment)

[ghost]

@avih @N-R-K @kasper93 @na-na-hi

you guys are misunderstanding everything about my PR so read it completely, then say anything

my PR is creating a property in osc.lua to announce pre-calculated values of mouse hover time of seekbar so that other scripts can use that time value. default osc.lua already does this but it lacks a property which makes external scripts very limited, i only added that property it was lacking in this PR but you guys are thinking i am doing something nuclear

if it had that property many scripts like thumbfast could work directly with mpv's osc.lua without needing a custom osc.lua by thumbfast, if it had a property ${user-data/osc/hovered-time} scripts like thumbfast and my simple_thumb_v1b.lua could know where and what time user is hovering mouse on seekbar so it showed correct preview but you maintaiers misunderstood this

when you hover on seekbar this property will write hovered-time, once you leave seekbar it becomes null as shown in video here #17510 (comment), its a simple concept, but none of you watched this video

a external script like my script gets that hovered-time value using mp.observe_property() and handles image and thumbnail on its own, but you guys are thinking it is doing something to osc.lua even though i have explained so many times

this PR aims to solves a complex problem just by creating a new property and it only have benefits and no problems but you guys don't understand it, i have explained the problem many times but you guys failed to grasp that problem so how can you even understand the purpose of this PR, creating a property that i am requesting doesn't cause any problems you are listing.

i even added images and video clips #17510 (comment) so that everyone understand what this PR is, but you guys ignored all of that, and even blame me for being hard to understand #17510 (comment)

communicate with this guy, copy pasting same reply

yes, i may be selfish but i have told you guys the purpose of my PR so many times, but instead of trying to understand what i mean, you guys are listing tons of unrelated problems in my PR and now everyone thinks my PR is bad

what a great community we have

everything you guys are talking about freedom to scripts, to what not endless problems unrelated to my PR are useless

The fear with this approach is that it leaves too much freedom to the script

if my pr was about counting easy 1 to 10 then you guys made it hard counting millions to billions,

soul of my PR is gone, and i am too tired to explain anything anymore, because instead of just merging so everyone can benefit from a new property, you guys will just list more of your imaginary problems.

[avih]

@xdev23 we see many of your posts multiple times. For instance your last posts appeared more than 10 times.

If you know why it happens, or if you can do something about it, please try to fix it. Thanks.

[ghost]

we see many of your posts multiple times

@avih
i don't know why it is happening but i hope you did read this once #17510 (comment) so you know what my PR is, because there seems too much confusion

[ghost]

@avih @N-R-K @kasper93 @na-na-hi

if you guys don't want to accept my PR no problem, i don't care anymore and i don't think you guys also care about this anymore, but still read this #17510 (comment) maybe you will understand

i would also like to request artifacts for this pull request once, is it possible?

[kasper93]

if you guys don't want to accept my PR no problem, i don't care anymore and i don't think you guys also care about this anymore, but still read this #17510 (comment) maybe you will understand

That's a valid assessments. I couldn't care less about thumbnails, just posted few thoughts on the topic.

I also understand. But at the same time I think solutions that are merged to upstream (here) should be well thought out and not focus on fixing use of specific script. That's why I propose to design better interoperability API for thumbnailing, that may be reused by other UI scripts too.

I personally don't think OSC should broadcast it's timeline hover position, this makes everyone feel like this is the goto solution for implementing features. However, since the changes are not intrusive, if others agree on introducing such interfaces, I don't mind too. It just feels like it will be quickly either discarded by other scripts or replaced with different solutions, which makes us keep stop gap interface for next two mpv releases at least.

[ghost]

@kasper93 since you want to discuss then lets disscus your ways

our goal, whether or not broadcast time of hover in seconds when mouse is on seekbar,

lets take this image for our goal

hover-time is in seconds,

kaspar you say

I personally don't think OSC should broadcast it's timeline hover position, this makes everyone feel like this is the goto solution for implementing features.

i think there will be 2 cases to make thumbnail preview in mpv possible-

CASE 1: implement everything within osc.lua

you will have to directly add thumbnailing to osc.lua which increases its codebase and many more settings for osc.conf. like thumbnail size, border, chapters support and what not, (it is possible but if it is missing features it only increases more PR)

CASE 2: broadcast the hover position using property

in image mouse is at position 10:18 so property writes 618 in seconds, any thumbnail script reading this property with mp.observe_property() can now show image of 618sec of video in preview either by using hidden mpv instance or using ffmpeg, this also happens to be this PR goal

this property can be used with custom scripts, works will all mpv osc layout size or seek bar, whether it is full screen or not, works without any issues, as long as mouse hits seekbar, hover-time will be correctly broadcasted using property, example in video (users can do everything to their liking, chapter, border or anything else, for example my script simple_thumb_v1b.lua)

[ghost]

@avih @N-R-K @kasper93 @na-na-hi

i tested the compiled artifact exe file of this PR from https://github.com/mpv-player/mpv/actions/runs/22795569076#artifacts

using the new property ${user-data/osc/hovered-time} with script simple_thumb_v1b.lua or any other script that people make in future with property ${user-data/osc/hovered-time} makes it possible that we won't need any custom osc.lua that we need from thumbfast

maintainers as much as i understand that you guys wanna implement thumbnail logic directly in osc.lua because you think it is what osc.lua should do, get ready you might need to add like 500 lines of code, and make them configurable using osc.conf. this property is way better then implementing directly in osc.lua, full reasoning here- #17510 (comment)

if you think instead of directly adding thumbnail logic in osc.lua, you can create a serperate thumbnail.lua, you will still need this ${user-data/osc/hovered-time} property i requested, right now there osc.lua doesn't tell hovered-time.

i don't understand why you won't add a important property that only improves its functionality and make things difficult for yourself, wasn't this why mpv uses lua and is configurable but one day you will realize i am right, there was a lot of drama in this PR, but i explained everything again properly here - #17510 (comment)

i will move my focus on something else now -

video showing results if this PR is approved

future thumbnail scripts can use ${user-data/osc/hovered-time}, example: simple_thumb_v1b.lua

2026-03-08.19-19-46.mp4

video when thumbfast is used with its custom osc.lua,

if this pr not approved new users use osc.lua from thumbfast.lua, that may have future compatibility issues and you are also missing new osc.lua features

2026-03-08.20-50-01.mp4

[ghost]

hey @xdev23

your idea is good

it could be very helpful to me, i am actually a script writer for videos, and i have to watch a video multiple times and create story line, so i have multiple mpv open at same time for playing video at different times, if i can get this hover time then i can use a ipc server to seek in another mpv window very quickly [not like thumbnails you are showing but full mpv window], this is very very helpful for me, i won't have to open many mpv windows, just 2 will be enough [one main and 2nd for quick seek], it won't be of much use in longer videos but for upto 20-30 min it is

you offended mods but i am actually very interested, i downloaded your osc.lua with pr change but it is not working and i don't want to use exe you showed in video, i am trying to create another script so i can make it work for my usecase

how do i make it work xdev23

i do hope mods do something

[ghost]

@xdev23

my bad,
your osc works, my mpv.conf is quite big, i created osc=no at top but there was a duplicate osc=yes at bottom, which caused problem

[ghost]

hey @avih @N-R-K @kasper93 @na-na-hi

i don't think this PR will ever see its day, even if i close it, it will stay in this repo, can you guys remove it entirely, i don't want to feel bad because even if i used ai help, i still did a lot of research, i told about using ai in my early comments, it was not easy to figure out that just by creating a property in osc.lua we can fix a big problem

i saw how you guys talked in irc chat as if i undermined you, so i request you to delete this PR, maybe someday in future will try again

in the mean time i will still use mpv, because it just that good,

[kasper93]

@xdev23: Stop posting, tagging everyone and deleting messages. You can edit if needed. This is first and last warning.

[ghost]

can you delete this pr

[Traneptora]

can you delete this pr

You can close it if you wish, but PRs stay in the repository history.

[avih]

@xdev23

Yes, we know it works. It's simple code, and we understand it, and we know it can work. You don't need to convince and show us that it works, again and again, because we already know it.

While I think this PR is OK, it looks like the majority of mpv members prefer the approach in the other PR - #17518, so this PR will probably not get merged.

For this reason, I'll close this PR now.

Thanks again for this PR.

If the other PR gets merged, then I hope you could still use it with yout thumbnail script, because the other PR also adds the hover-timepos as a property (but it also does more things which other people think are important).

[ghost]

@avih
if you have implement the property using another pr, thanks, i wasn't againt you implementing my pr but its feature

anyway, a lot of thing happend on my side, i have created a custom script that doesn't need hidden mpv at all, uses ffmpeg dlls that mpv is based on, it is slow right now but i am sure you might want to have a look at this as this can be implemented using mpv's ffmpeg dlls

if NRK doen't mark my comment off topic in #17518 i am willing to share my findings

i am sure it will help a lot

[avih]

You're welcome to share anything you want, either here (people can still read comments here even if the PR is closed), or at the other PR.

Just... try to post each sharing only once, without posting it many times and then deleting it... :)

Thanks.