The VideoLAN Forums

I have a simple bash script which launches VLC with a playlist of files pulled from a particular directory. These files can change at any time, so I'm watching the directory with inotify/incrond in order to trigger a restart of my script when this happens. The problem is, it turns out VLC itself opens any file it's playing for writing, which leads to an IN_CLOSE_WRITE event being triggered when the video ends.

As you can imagine, this leads to the script being restarted every time the first video finishes, which means the playlist never progresses beyond the first item. If I remove the write permission from the folder and its contents VLC still plays the files without issue, and of course no longer triggers any IN_CLOSE_WRITE events, but I need write to be enabled in order to update the video files. What's worse, I must run VLC under the user account that owns this folder, so this obvious work-around is not an option.

TL;DR: Why does VLC open video files for writing, and is there some way to get VLC to open the files as read only, short of marking them as such?

VLC opens files with the following flags O_RDONLY | O_NONBLOCK | O_CLOEXEC when it plays them. You can check for yourself with strace. It does not open for writing.

Ok, then how come I see this in syslog (when tracing incrond):

Using this bash script:


There's nothing else going on which might trigger these IN_CLOSE_WRITE events, and they always happen exactly when a video has finished playing in VLC. I'm not saying you're wrong - you seem to know what you're talking about - but I'm pretty sure I'm not either...

Look if you don't believe me, you can check strace -f vlc for yourself that it does not open files for writing... But if VLC did open for writing, it would not be able to play files without write permission or on a read-only file system...

I'm not saying you're wrong (of course you aren't) - I am asking for help. I mean I can actually see the IN_CLOSE_WRITE events happening right there, so for some reason they are being triggered when VLC moves from one file to the next. Since nothing else is touching those files...

I am afraid that this is really not the right venue for inotify development questions.

This isn't a question about inotify - it is a question about VLC. But thanks for bringing up strace; I'm no expert on its usage but is seems VLC spawns a thread, which spawns another thread, which in turn does open the video file RDWR:



So yeah. AFP. I'll repeat my question: Why does VLC open files for writing? And more importantly: how can I stop this from happening?


.

Look if you don't believe me, you can check strace -f vlc --loop video_one.mp4 video_two.mp4 for yourself that it does open the files for writing.

Unfortunately I must get to the bottom of this, and do not have the option of walking away. Trust me, I can think of many many things I would rather do than argue with arrogant developers. I actually, genuinely, wish that Rémi had been right and some other component was causing this behaviour - I am not here to score points but to solve a problem. I could then have directed my query towards a friendlier community (most of them are), while he could carry on with the all-important task of crushing newcomers. But alas, the issue does appear to lie with VLC or some part of it, and so I must persist in the hope that there's someone here who knows something about it. Could it have something to do with the fact that I'm queuing up multiple files? Or some module, like subtitles, or metadata? Any suggestions how I could narrow things down further? This is a stock install of VLC 3.0.8 so I don't think it's unique to the two systems I've tested on...

Could it have something to do with the fact that I'm queuing up multiple files? Or some module, like subtitles, or metadata? Any suggestions how I could narrow things down further? This is a stock install of VLC 3.0.8 so I don't think it's unique to the two systems I've tested on...

On a recent Linux system, you should see openat(), not simply open() on that file.

I wouldn't be surprised by something like metadata library.
try --no-auto-preparse

Could it have something to do with the fact that I'm queuing up multiple files? Or some module, like subtitles, or metadata? Any suggestions how I could narrow things down further? This is a stock install of VLC 3.0.8 so I don't think it's unique to the two systems I've tested on...

On a recent Linux system, you should see openat(), not simply open() on that file.

I wouldn't be surprised by something like metadata library.
try --no-auto-preparse

Thank you, interesting and promising, sadly I still get a O_RDWR at the same point. Here's a bigger chunk of the strace output:



Perhaps some clues in there?

TagLib opens files for writing, falling back to read-only mode only if the earlier fails.

TagLib opens files for writing, falling back to read-only mode only if the earlier fails.

Ah, that must be it - thank you very much Rémi! All is forgiven, and I'm sorry if I got a bit grumpy there I can see both a "reader" and a "writer" listed in the plugins; is there any way to disable the writer, short of building VLC with --disable-taglib? I had a look around but could not find any suitable command line switches, nor anything in the preferences...

It's not the meta writer. TagLib just always opens files for writing if it can, even for reading.

You need to patch TagLib or remove the TagLib plugin entirely.

Ok, so is there any way to remove or disable "meta reader", short of building VLC with --disable-taglib?

I'll answer that myself:



Crude but effective; VLC seems to work just fine without it, and I'm no longer seeing any O_RDWR events on the video files in the strace log. Unless there is a more elegant way to achieve this, you can consider this case closed. Many thanks to Rémi and InTheWings for helping me get to the bottom of this!

Hi, this is ok for disabling taglib, it will remove the probe of the module completely without risk of crash.

Thanks for confirming unidan!