Is there any way we can remove the delay between mouse wheel clicks?

[xecus922]

First I have to thank you for this incredibly useful plugin. And also especially for adding other button options like mouse wheel click which VLC does not natively allow you to use as a hotkey for some stupid reason when every other media player I've tried does. I like to use scroll wheel up/down to move forward and backward in a video and wheel click to play/pause.

But is there any way to reduce or remove the delay between clicks? There definitely seems to be a delay of about a second but sometimes we need to play/pause in rapid succession while trying to catch the perfect moment in a video as we're moving forward and backwards but this delay just ruins that and makes it much more difficult.

[nurupo]

But is there any way to reduce or remove the delay between clicks?

Nothing I can do to remove the delay as the delay is coming from VLC. If you click on the mouse wheel shortly after you have already clicked on it, VLC simply doesn't tell the plugin about that second (third, fourth, etc.) click, so the plugin has no way of learning that you clicked again. VLC starts telling the plugin about mouse wheel clicks only after some delay has passed. This doesn't happen with left/right clicks, just the mouse wheel.

sometimes we need to play/pause in rapid succession while trying to catch the perfect moment in a video as we're moving forward and backwards

Depending on what you are doing, you might find the "next frame" key shortcut useful (seems to be "e" by default). There is no "previous frame" shortcut in VLC though.

[nurupo]

Interesting enough, if you move the mouse, VLC propagates the middle mouse click to the plugin without a delay.

[xecus922]

Interesting enough, if you move the mouse, VLC propagates the middle mouse click to the plugin without a delay.

Nice find! I just tried that and you're right! Moving the mouse in between wheel clicks removes the delay! This is hilarious, I would've never expected that. But a very pleasant surprise and just what I needed. I can do that as a workaround, thank you for seriously looking into this and actually experimenting with it yourself to discover this workaround, very much appreciated and I'll be making a donation as soon as I can, you have my word on that.

[nurupo]

I had a chance to debug this issue today.

The way it works, your mouse events are captured by Qt and then relayed to VLC. When you do two mouse wheel clicks in a rapid succession, Qt tells to VLC that the following events are happening: mouse wheel press, mouse wheel release, mouse wheel double-click, mouse wheel release. However, VLC doesn't tell plugins about any double-clicks that are not a left mouse click. With just the double-click being ignored the even sequence would become: press, release, release, but VLC also ignores passing repeated press/release events to plugins, so it becomes: press, release. So effectively VLC doesn't propagate the last two events to plugins, making mouse wheel double-click and the following release non-existent.

I could modify VLC so that the events are propagated and thus could be handled by my plugin, but I think that a patch allowing mouse wheel double-clicks might raise VLC developer's eyebrows. I doubt they will be willing to change how mouse clicks in VLC 3.0.x are handled, but I could try submitting a patch for VLC 4.

[nurupo]

Speaking of submitting the patch for VLC4 -- looks like this is not an issue on VLC4, every mouse wheel click gets registered there.

I was writing a bug report to the VLC bugtracker, citing the VLC3 code lines I have provided in my previous comment here, but noticed that in VLC4 the mouse handling got reworked and no longer filters out mouse wheel double-clicks -- all double-clicks get unconditionally passed to plugins. I have tested the latest nightly VLC4 and can confirm that my plugin receives all the mouse wheel click events and pauses on them correctly, without any delay.

Here is a plugin I just built off the current master branch in case you want to try it with VLC4. I assume you use Windows, otherwise you should be able to build the plugin yourself following the instructions in the README. Just note that VLC4 is still in development, it hasn't released yet, so you might encounter bugs. The zip contains a download link to the VLC4 that the plugin was built against. Depending on the ABI compatibility, it might or might not work with other VLC4 builds.

• vlc-4.0-64bit-win.zip

Will see if VLC developers are open to accepting the patch into 3.0.x.

[nurupo]

Here is the patch https://code.videolan.org/videolan/vlc/-/merge_requests/4284

I have initially made a patch that passes double-clicks as double-clicks to plugins, but that might break some plugins (it did break mine, for example), so I decided against that in favor of this more simpler patch of passing double-clicks as regular mouse button presses.

[xecus922]

Speaking of submitting the patch for VLC4 -- looks like this is not an issue on VLC4, every mouse wheel click gets registered there.

I was writing a bug report to the VLC bugtracker, citing the VLC3 code lines I have provided in my previous comment here, but noticed that in VLC4 the mouse handling got reworked and no longer filters out mouse wheel double-clicks -- all double-clicks get unconditionally passed to plugins. I have tested the latest nightly VLC4 and can confirm that my plugin receives all the mouse wheel click events and pauses on them correctly, without any delay.

Here is a plugin I just built off the current master branch in case you want to try it with VLC4. I assume you use Windows, otherwise you should be able to build the plugin yourself following the instructions in the README. Just note that VLC4 is still in development, it hasn't released yet, so you might encounter bugs. The zip contains a download link to the VLC4 that the plugin was built against. Depending on the ABI compatibility, it might or might not work with other VLC4 builds.

* [vlc-4.0-64bit-win.zip](https://github.com/nurupo/vlc-pause-click-plugin/files/12686063/vlc-4.0-64bit-win.zip)

Will see if VLC developers are open to accepting the patch into 3.0.x.

Wow you already did it.

I'm always paranoid about anything I download, past betrayals and things like that so please don't take it personally (I know, you might be thinking how could you think I might do such a thing when I'm helping you!) but I scanned the zip/new plugin with virustotal and one vendor detected a Trojan.win64.crypt?

And there was no detection on the official plugin so that also worried me.

If you could ease my mind about that or maybe there is a way to fix that for other paranoid people like myself?

Here is the patch https://code.videolan.org/videolan/vlc/-/merge_requests/4284

I have initially made a patch that passes double-clicks as double-clicks to plugins, but that might break some plugins (it did break mine, for example), so I decided against that in favor of this more simpler patch of passing double-clicks as regular mouse button presses.

I assume we have to wait for them to approve it before anyone can use it? My first time ever doing anything like this.

EDIT: Also just made that donation I promised, I'm a man of my word and I have so much respect for you seeing how seriously you take what you do here and working so hard going above and beyond to help myself like with this question and others.

[nurupo]

Must be a false positive, it's just 2/70 of antiviruses that detect anything. Nothing I can do to fix that since I don't know what triggers them.

The good thing though is that you don't have to trust my binaries as you can build them yourself -- you can find the instructions on how to do that at packaging/windows/docker. The build process downloads things only from Docker (the Debian image) the Debian package repository and the VLC website (VLC SDKs), so you have to audit just the plugin source code and the buildscript, both of which are short.

I assume we have to wait for them to approve it before anyone can use it? My first time ever doing anything like this.

It would need to get approved, merged, and a new version of VLC including that patch would need to get released, for example VLC 3.0.19 (though as long as it's merged you could use the nightly build without having to wait on the new version release).

[xecus922]

Must be a false positive, it's just 2/70 of antiviruses that detect anything. Nothing I can do to fix that since I don't know what triggers them.

The good thing though is that you don't have to trust my binaries as you can build them yourself -- you can find the instructions on how to do that at packaging/windows/docker. The build process downloads things only from Docker (the Debian image) the Debian package repository and the VLC website (VLC SDKs), so you have to audit just the plugin source code and the buildscript, both of which are short.

I assume we have to wait for them to approve it before anyone can use it? My first time ever doing anything like this.

It would need to get approved, merged, and a new version of VLC including that patch would need to get released, for example VLC 3.0.19 (though as long as it's merged you could use the nightly build without having to wait on the new version release).

Okay I see, yeah I'll just skip all the building and use the new dll, I was mostly sure those are false positives, it's just two providers no one has really heard of, usually the case with the false positives.

Also, just something totally off topic but do you do any kind of 'commissions' for small VLC projects? For years now I've been losing my mind over how VLC handles it's recent files, it seems to only show an extremely limited list of recent files and then if lose power, PC restarted for whatever reason while you had a lot of videos open there's no way to really figure out what those videos were that you had open. For someone who is sorting hundreds of videos a week this is infuriating when it happens.

And there doesn't seem to be any kind of plugin yet available to solve these problems, we don't yet have a true comprehensive history option. Then there's the bookmarking not actually allowing people to bookmark favorite videos. But one thing at a time of course, if you're open to it at all, the history one would be most important to me and I will happily pay for it upfront. Lemme know, we can discuss more in private messages wherever if you're up for it and don't think it would be too complicated or time consuming.

[nurupo]

Sure, I can do a commission if it's something I think that can be done within the plugin system of VLC.

Funny how you mention playback history and restoring files that were opened when your PC is shutdown. I have extended mpv to support both of those. I wrote a history script for myself a couple of years ago. It records the date-time, the video title and the file path/URL of when a file/URL was opened and closed. I also have a handy-dandy python script which analyzes this history file, looking for files that were opened but never closed -- the files that were open when I shutdown my PC, and re-opens them. So if I had some video/audio files or youtube/twitch videos/VODs open on shutdown, I can easily restore them.

Something like that could be added to VLC too, likely even via its LUA scripting support without a need to build a dll.

[xecus922]

Sure, I can do a commission if it's something I think that can be done within the plugin system of VLC.

Funny how you mention playback history and restoring files that were opened when your PC is shutdown. I have extended mpv to support both of those. I wrote a history script for myself a couple of years ago. It records the date-time, the video title and the file path/URL of when a file/URL was opened and closed. I also have a handy-dandy python script which analyzes this history file, looking for files that were opened but never closed -- the files that were open when I shutdown my PC, and re-opens them. So if I had some video/audio files or youtube/twitch videos/VODs open on shutdown, I can easily restore them.

Something like that could be added to VLC too, likely even via its LUA scripting support without a need to build a dll.

So happy to hear you do commissions, made my day.

Funny you mention mpv! As I was typing that up, mpv was the very thing I was thinking about, I was gonna say it doesn't even need to be anything that blows me away visually, it can just be text in a list on the video player to scroll through like a script for mpv I was using before.

Oh man, this is beautiful, I want everything you just mentioned there, I really like the sound of that python script for re-opening files that were opened but not closed. Yeah I definitely need all of that.

MPV I really liked a lot for how snappy it is, easily the king when it comes to speed of loading files but for some things you might want to do like having videos load at a specific location of your screen and a certain size, it would take a lot of trial and error for days for someone who isn't an expert at tweaking code and messing with geometry values and even the documentation couldn't save you when trying to make mpv do certain things which I could just click on one option to do in VLC. But I did enjoy learning new things through that trial and error, it felt almost like you're creating your own video player as you mess with the code and immediately see the changes to customize it how you see fit. And so many interesting and amazingly useful scripts from people out there.

But I think the main reason why I came back to VLC is just I had a bad feeling that I might be looking at long term damage to my file system/storage media when I would see that some mp4 videos wouldn't play at all with mpv for some strange reason, thumbnails wouldn't load for them either from what I remember but the biggest concern was that pretty common video file types just couldn't play with mpv at all. And I think I read something about mpv not having some kind of speed limit that other video players have which leads to some kind of risk down the line. So I decided to just come back to what's safest and what I'm used to, do more research to figure out how I can deal with VLC's many shortcomings which has paid off now that I met you!

You're taking years of stress and frustration off my shoulders man, I can't thank you enough.

[nurupo]

Oh man, this is beautiful, I want everything you just mentioned there, I really like the sound of that python script for re-opening files that were opened but not closed. Yeah I definitely need all of that.

Cool, feel free to use those mpv scripts, the MIT license on them is rather permissive!

But I think the main reason why I came back to VLC is just I had a bad feeling that I might be looking at long term damage to my file system/storage media when I would see that some mp4 videos wouldn't play at all with mpv for some strange reason, thumbnails wouldn't load for them either from what I remember but the biggest concern was that pretty common video file types just couldn't play with mpv at all. And I think I read something about mpv not having some kind of speed limit that other video players have which leads to some kind of risk down the line.

mpv can't damage your files as it's just reading them, it doesn't write to them. Also, mpv uses ffmpeg for playback, which should be to handle pretty much everything you can throw at it. It could be that it can't play some files that VLC can, and vice-versa, though that should be rare. No idea what speed limit you are talking about and how that can be a risk to anything.

[xecus922]

Oh man, this is beautiful, I want everything you just mentioned there, I really like the sound of that python script for re-opening files that were opened but not closed. Yeah I definitely need all of that.

Cool, feel free to use those mpv scripts, the MIT license on them is rather permissive!

Ah I'm trying to avoid going back to MPV, as much as I was enjoying it. I'm praying it's possible to do this on VLC, let me know.

But I think the main reason why I came back to VLC is just I had a bad feeling that I might be looking at long term damage to my file system/storage media when I would see that some mp4 videos wouldn't play at all with mpv for some strange reason, thumbnails wouldn't load for them either from what I remember but the biggest concern was that pretty common video file types just couldn't play with mpv at all. And I think I read something about mpv not having some kind of speed limit that other video players have which leads to some kind of risk down the line.

mpv can't damage your files as it's just reading them, it doesn't write to them. Also, mpv uses ffmpeg for playback, which should be to handle pretty much everything you can throw at it. It could be that it can't play some files that VLC can, and vice-versa, though that should be rare. No idea what speed limit you are talking about and how that can be a risk to anything.

I was just mainly concerned about possible 'collateral damage' stemming from the player struggling to play/process certain video files. Because for some strange reason, it refused to load some of my MP4 videos that are perfectly fine on VLC. So I'm thinking what the hell, why would it play some MP4 files but not other MP4 files. Then I'm wondering if it's because the file is too long or too big but it would play other videos of the same video type (MP4) of similar lengths and size. So I just didn't like that inconsistency. And I'm working on hard drives that are running 24/7, a lot of write operations going on, ambient temperatures aren't the greatest sometimes though I do have good cooling so I try to just eliminate anything that could ever have any potential of degrading the hard drives even more. Really strange bugs exist sometimes and hardware and software behave in ways we would never expect sometimes. Like I once had a refurbished hard drive die right after I ran one of the drive commands to scan it or attempt to repair it.

And I had already been observing how their team interacts with users and I would see them being pretty harsh with users at times, pretty 'elitist' and just overall insensitive making little inside jokes with one another when a user was requesting something rather than staying professional and mature at all times so that also bothered me and made me feel like these might not be the kind of people I want to download software from and be using on a daily basis.

The speed limit thing I think was something related to how they process something(s) and it was basically saying that mpv doesn't have that limit which is a good thing but at the same time a little risky. I'll link to it if I manage to find it again but I might be buried far away somewhere.

[nurupo]

Figured out what was triggering 2/70 antiviruses on VirusTotal -- apparently they don't like PayPal and Bitcoin donation links. If they are both removed, then they no longer flag the binary, but as long as one of them stays they will flag it.

Specifically the lines 171 and 173 in:

https://github.com/nurupo/vlc-pause-click-plugin/blob/67a00e676fc808d2bf32d127f57cbd901ee37ee1/src/pause_click.c#L171-L173

• Plugin for VLC 4.0 64-bit with these lines present:

  • VirusTotal reporting 2/70
  • vlc-4.0-64bit-win.zip

• Plugin for VLC 4.0 64-bit with these lines absent:

  • VirusTotal reporting 0/71
  • vlc-4.0-64bit-win.zip

These donation links are a new addition, there were no donation links in previously released versions of the plugin. I don't want to remove them just because some antiviruses misinterpret them as something malicious.

[nurupo]

I'm closing the issue since it's a bug in VLC.

As mentioned before, since it was quite easy to fix, I have sent VLC a patch for it. It still hasn't been merged yet.

If you want to discuss something not related to the mouse wheel clicking issue, feel free to send me an email. The discussion in here has already veered off-topic.

[nurupo]

Just a heads-up that this is now fixed in the latest nightly build -- https://artifacts.videolan.org/vlc-3.0/nightly-win64/20231028-0220/

[xecus922]

Just a heads-up that this is now fixed in the latest nightly build -- https://artifacts.videolan.org/vlc-3.0/nightly-win64/20231028-0220/

Oh thanks for the heads up. But sadly the nightly build seems pretty buggy for me. I would hit the side button on my mouse and the whole video just closes out of nowhere. So I've just been doing the workaround you found with 3.0 for now.

And I will be contacting you in the coming days about the history plugin and maybe a rate one too because VLC's current increase/decrease 'rate' (increasing/decreasing speed of the video) is terrible, very unreliable and unstable. Just got a nightmare going on IRL at the moment.

[nurupo]

I would hit the side button on my mouse and the whole video just closes out of nowhere.

Huh, unable to reproduce this. Clicking on the Page Back and Page Forward side buttons of my mouse doesn't do anything in VLC, while the scroll wheel tilt buttons -- tilt left and right -- make the video jump back and forward by 2-3 seconds without any crashes. You should probably file a bug report with VLC if the crash doesn't happen for you in the release version but does in the nightly, as the nightly will become the new release later on.

[xecus922]

I would hit the side button on my mouse and the whole video just closes out of nowhere.

Huh, unable to reproduce this. Clicking on the Page Back and Page Forward side buttons of my mouse doesn't do anything in VLC, while the scroll wheel tilt buttons -- tilt left and right -- make the video jump back and forward by 2-3 seconds without any crashes. You should probably file a bug report with VLC if the crash doesn't happen for you in the release version but does in the nightly, as the nightly will become the new release later on.

Maybe it's fixed in this latest nightly build that I assume was just released within the last few days. This happened to me about a week or two ago while trying out the nightly build with your plugin version that removes the delay. And I'm starting to think it may be something that only happens with certain mouse models. But I'm using a Logitech G Pro Wireless, pretty popular gaming mouse but maybe it works in some way that VLC doesn't know how to deal with properly or something like that.

Another reason why I'm wondering this now (if it's an issue where VLC just doesn't know how to deal with certain mouse models) is because I noticed that recently some other very strange behavior is happening only with VLC media player which is that my side buttons to increase/lower playback rate is no longer working in version 3.0.1.9. Yet when I go to the hotkey page and try pressing the mouse side button, just outside of the box that says "Press the new key or combination for Faster" for example, you hear the OS error sound of when you click outside of a window you need to close first. But it ignores the side mouse button when attempting to assign it as a hotkey for anything at all if you do press the side button within this box.

The side buttons still work fine in any other video player like MPV for example and still works fine as Page Back and Page Forward buttons in my browser.

I didn't get to see what happens in the nightly build after actually attempting to assign the side buttons to increase/lower rate but I was just over it and removed it after seeing all the strange behavior it was displaying. Like when I would start a video using the nightly build there would be some kind of outline of a square in the middle of my screen for a second or two then it just crashes from me simply pressing the mouse side button so I just didn't want to bother with it anymore, I figured the same crash would happen if I go and try to assign that button as a hotkey.

I might mess with this latest nightly today and see if it's still happening with that version but at this point I have little to no motivation to file bug reports because it's just ridiculous seeing what's going on even in the release version, the silliest things that never happen in much less popular and less known video players out there like the mouse side button just ceasing to function out of nowhere while it's fine in other video players, the increase/lower rate option that the video player does a very bad job of handling properly to the point of the video just freezing altogether if you increase/lower the rate too often and this rate switching bug has been an issue for years.

EDIT: Looks like the side button issue is also happening on an old mouse I have, will try on older versions of VLC later and see what happens. Very strange bug.

[nurupo]

VLC 3.0.20 just got released, it contains the fix, so you don't have to use the nightly anymore. Looks like the website still links to 3.0.19 download though, so it might take some time for the website to get updated to link to the new version.

This happened to me about a week or two ago while trying out the nightly build with your plugin version that removes the delay.

Oh, that must have been VLC4 nightly then. VLC4 is still WIP and prone to bugs, including crashes. So I wouldn't be too surprised if it crashed on you if you looked at it funny. This time around I was linking to VLC3 nightly, which is supposed to be more stable. Not that this is relevant anymore now that 3.0.20 with these fixes included is released.