Why does (command line) VLC open files for writing?

[Lomax]

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?

[Rémi Denis-Courmont]

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.

[Lomax]

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

Code: Select all

... Sep 7 01:10:20 panorama incrond[4432]: PATH (/home/station/films) FILE (film_one.mp4) EVENT (IN_CLOSE_WRITE) Sep 7 01:10:20 panorama incrond[4432]: (root) CMD (film_one.mp4) Sep 7 01:10:20 panorama launch.sh[22793]: libva info: VA-API version 1.4.0 Sep 7 01:10:20 panorama launch.sh[22793]: libva info: va_getDriverName() returns 0 Sep 7 01:10:20 panorama launch.sh[22793]: libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so Sep 7 01:10:20 panorama launch.sh[22793]: libva info: Found init function __vaDriverInit_1_4 Sep 7 01:10:20 panorama launch.sh[22793]: libva info: va_openDriver() returns 0 Sep 7 01:10:20 panorama launch.sh[22793]: [00007f2f60fdaa00] avcodec decoder: Using Intel i965 driver for Intel(R) Gemini Lake - 2.3.0 for hardware decoding Sep 7 01:14:57 panorama incrond[4432]: PATH (/home/station/films) FILE (film_two.mp4) EVENT (IN_CLOSE_WRITE) Sep 7 01:14:57 panorama incrond[4432]: (root) CMD (film_two.mp4) Sep 7 01:14:58 panorama launch.sh[22793]: libva info: VA-API version 1.4.0 Sep 7 01:14:58 panorama launch.sh[22793]: libva info: va_getDriverName() returns 0 Sep 7 01:14:58 panorama launch.sh[22793]: libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so Sep 7 01:14:58 panorama launch.sh[22793]: libva info: Found init function __vaDriverInit_1_4 Sep 7 01:14:58 panorama launch.sh[22793]: libva info: va_openDriver() returns 0 Sep 7 01:14:58 panorama launch.sh[22793]: [00007f2f60c39c30] avcodec decoder: Using Intel i965 driver for Intel(R) Gemini Lake - 2.3.0 for hardware decoding ...

Using this bash script:

Code: Select all

#!/usr/bin/bash FILES=/home/station/films VIDEOS="" start() { for video in $FILES/*.mp4 do VIDEOS+=" ${video}" done DISPLAY=:0 cvlc --loop $VIDEOS } stop() { pkill vlc } case $1 in start|stop) "$1" ;; esac

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...

[Rémi Denis-Courmont]

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...

[Lomax]

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...

[Rémi Denis-Courmont]

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

[Lomax]

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:

Code: Select all

$ strace -f vlc --loop /home/station/share/film_one.mp4 /home/station/share/film_two.mp4 27315 execve("/usr/bin/vlc", ["vlc", "--loop", "/home/station/share/film_one.mp4", "/home/station/share/film_two.mp4"], [/* 41 vars */]) = 0 ... 27315 clone(child_stack=0x7fe8e773ffb0, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0x7fe8e77409d0, tls=0x7fe8e7740700, child_tidptr=0x7fe8e77409d0) = 27316 ... 27316 clone(child_stack=0x7fe8d08affb0, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0x7fe8d08b09d0, tls=0x7fe8d08b0700, child_tidptr=0x7fe8d08b09d0) = 27435 ... 27435 open("/home/station/share/film_one.mp4", O_RDWR) = 23

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?


.

[Lomax]

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.

[Lomax]

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...

[InTheWings]

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

[Lomax]

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:

Code: Select all

3580 <... mprotect resumed> ) = 0 3580 mprotect(0x7f41b8cca000, 49152, PROT_READ|PROT_WRITE) = 0 3580 mprotect(0x7f41b8cd6000, 40960, PROT_READ|PROT_WRITE) = 0 3580 mprotect(0x7f41b8ce0000, 4096, PROT_READ|PROT_WRITE) = 0 3580 mprotect(0x7f41b8ce1000, 4096, PROT_READ|PROT_WRITE) = 0 3580 mprotect(0x7f41b8ce2000, 4096, PROT_READ|PROT_WRITE) = 0 3580 mprotect(0x7f41b8ce3000, 4096, PROT_READ|PROT_WRITE) = 0 3580 mprotect(0x7f41b8ce4000, 4096, PROT_READ|PROT_WRITE) = 0 3580 mmap(NULL, 8392704, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 0x7f41aa53d000 3580 mprotect(0x7f41aa53d000, 4096, PROT_NONE) = 0 3580 clone( <unfinished ...> 3587 set_robust_list(0x7f41aad3d9e0, 24 <unfinished ...> 3580 <... clone resumed> child_stack=0x7f41aad3cfb0, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0x7f41aad3d9d0, tls=0x7f41aad3d700, child_tidptr=0x7f41aad3d9d0) = 3587 3587 <... set_robust_list resumed> ) = 0 3580 rt_sigprocmask(SIG_BLOCK, [INT QUIT PIPE TERM], <unfinished ...> 3587 futex(0x7f41b8c3a97c, FUTEX_WAIT_PRIVATE, 1, NULL <unfinished ...> 3580 <... rt_sigprocmask resumed> [HUP INT QUIT PIPE TERM CHLD], 8) = 0 3580 clone( <unfinished ...> 3588 set_robust_list(0x7f41c733b9e0, 24 <unfinished ...> 3580 <... clone resumed> child_stack=0x7f41c733afb0, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0x7f41c733b9d0, tls=0x7f41c733b700, child_tidptr=0x7f41c733b9d0) = 3588 3588 <... set_robust_list resumed> ) = 0 3580 rt_sigprocmask(SIG_SETMASK, [HUP INT QUIT PIPE TERM CHLD], <unfinished ...> 3588 futex(0x7f41b8c05b2c, FUTEX_WAIT_PRIVATE, 1, NULL <unfinished ...> 3580 <... rt_sigprocmask resumed> NULL, 8) = 0 3580 write(8, "\1\0\0\0\0\0\0\0", 8) = 8 3576 <... poll resumed> ) = 1 ([{fd=8, revents=POLLIN}]) 3580 write(8, "\1\0\0\0\0\0\0\0", 8 <unfinished ...> 3576 read(8, <unfinished ...> 3580 <... write resumed> ) = 8 3576 <... read resumed> "\2\0\0\0\0\0\0\0", 16) = 8 3580 open("/home/station/share/video_one.mp4", O_RDWR <unfinished ...> 3576 poll([{fd=8, events=POLLIN}, {fd=9, events=POLLIN}], 2, 467 <unfinished ...> 3580 <... open resumed> ) = 23 3580 fstat(23, {st_mode=S_IFREG|0664, st_size=34766242, ...}) = 0 3580 mprotect(0x7f41b8ce5000, 4096, PROT_READ|PROT_WRITE) = 0 3580 fstat(23, {st_mode=S_IFREG|0664, st_size=34766242, ...}) = 0 3580 lseek(23, 34762752, SEEK_SET) = 34762752 3580 read(23, "T\336m\3\353\316\316!\362\177\327\274\311\202\302\35\"\22B\270/y\26\364\225\352\203\244\245#\220\266"..., 3490) = 3490 3580 lseek(23, 0, SEEK_SET) = 0 3580 fstat(23, {st_mode=S_IFREG|0664, st_size=34766242, ...}) = 0 3580 lseek(23, 34762752, SEEK_SET) = 34762752 3580 read(23, "T\336m\3\353\316\316!\362\177\327\274\311\202\302\35\"\22B\270/y\26\364\225\352\203\244\245#\220\266"..., 3490) = 3490

Perhaps some clues in there?

[Rémi Denis-Courmont]

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

[Lomax]

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...

[Rémi Denis-Courmont]

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.

[Lomax]

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

[Lomax]

I'll answer that myself:

Code: Select all

# mv /usr/lib/x86_64-linux-gnu/vlc/plugins/meta_engine/libtaglib_plugin.so /usr/lib/x86_64-linux-gnu/vlc/plugins/meta_engine/libtaglib_plugin.so.disabled

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!

[unidan]

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

[Lomax]

Thanks for confirming unidan!