Updated: November 13, 2024
The problem you're facing is quite innocent and yet annoying. In VLC, audio and video files play normally. But, with audio files, when you jump to a different timestamp, there's a playback delay, say 1 second. Furthermore, the playback supposedly jitters a tiny bit behind the intended mark. So you jump from say 0m34s to 1m22s in a song, and VLC then briefly starts playing, reconsiders, and goes back to 1m21s. Happened to me.
I have no idea why the problem suddenly manifested itself. I never had such issues with VLC before, but they are now present in the media player in my Kubuntu 22.04 on my Slimbook Executive. Now, considering I've encountered a whole range of issues with this machine lately, mostly due to buggy kernel updates and bugs with the Plasma desktop, I wouldn't be surprised if VLC isn't another collateral victim of the problem. Luckily, you can work around this relatively easily, so let me show you.
Solution
What we need to do is change the caching value for Input / Codecs. This is similar to the prefetch value problems I've had with Samba share streaming. Open VLC preferences, then click All. In the search field, type caching (or similar). In the sidebar results below, select Advanced > Input / Codecs. Then, on the right, scroll down to the section called Advanced (yes, multiple Advanced fields).
Here, the first entry will be File caching (ms). For me, the default value was set to 1000ms (1s), and this neatly corresponds to the jitter/jump that occurs when you seek. Not sure WHY the problem manifests all of a sudden, but that's something we should solve another time - or not, and let the people who develop the code, player, desktop environment and distro figure it out as part of their QA, right.
I decided to play with the value, to see what gives. Reducing the caching from 1000ms to 100ms renders desirable results. There's no more delay and/or jump, or if there is, it's not noticeable. I am aware that this potentially might introduce playback problems for network-streamed files, but for now, I've not encountered any side effects. VLC now delivers, as it should.
Conclusion
This sure isn't the year of the Linux desktop. And I guess, given the casual, disdainful approach to usability and the philosophy of finished products, it never will be. As long as software is developed as a higher goal unto itself, with no regard to the core functionality, i.e., giving users what they need rather than being a fun thing for the people who write code, the end user will always be at risk. Whimsicality, zero accountability. That's software. Engineers build bridges, something goes wrong, they go to jail. Programmers write code, something goes wrong, no one cares. We could blame VLC, but the issue does not happen in Windows.
But do not let my great disappointment spoil your day. After all, I'm writing this article on the back of a whole mountain of issues and problems in the Linux desktop stack, and all of them happening in just the last few months. This is a silly, unnecessary problem. It's also something I've never seen before, and has to be a pointless bug. Well, there you go. A pointless problem, and a pointful workaround. Take care.
Cheers.