The VideoLAN Forums

I added this to another thread (specifically in reference to the media library) But got no response - now another version has been released and this still makes playlists media libraries and MRLs unusable.

Again the problem is that if you add a Directory it adds *everything* not just extensions VLC knows. When it tries to read metadata from these files (desktop.ini is a big culprit) we get a crash in libavformat_plugin.dll at 0x130cf all for the simple cost of checking the last 3 letters of the filename.

So far I only know this appears on win32 but given the number of crashes reported with "large directories" this is a likely culprit since the probability of at least 1 file not being a recognised media file will tend to 1 as the size of the folder increases.

Any chance of a fix by 0.9.8 on win32?

Oh my, we surely will not discard filename based on extensions. That's so Microsoft thinking.

FFMPEG/libavformat should learn not to crash when reading desktop files.

Whilst I understand your reasoning, the file extension pre-dates most MS OSes with the possible exception of those running MS Basic. I remeber using them in CP/M which pre-dates zDOS.

They were introduced for good purpose and an be considered a basic form of metadata. Which given win32s lack of mimetype attributes or other advance meta properties would be suitable for use even if libav is the source of the crash I don't want 30 desktop.inis sitting in my playlist/media library anyway check them some way and root them out first.

At the moment crashes are caused by any file which is not a recognised format. Spreadsheets, text files, ringtones - all things which should be being ignored.

VLC is NOT a Windows(-only) program. And then we have no list of "supported extensions" anyway, since this depends on what plugins where built or installed separately, and changes over time.

VLC is NOT a Windows(-only) program. And then we have no list of "supported extensions" anyway, since this depends on what plugins where built or installed separately, and changes over time.

I never said VLC was A Windows only program, not only that I intend to use it with the OSX and linux machines in my houseif it prove suitable which it curently isn't. Its also not an OSX only programme or Linux only programme but the OSes do support extensions on filenames and most mediafiles have them added already - even if the extension does not reveal the specific variation of the codec - thats wu we have genaralied extensions for container formats rather than for each individual codecs.

I have a lot of media files mixed together with other files such as OSX .DS_Store and windows desktop.ini files and I'm sure I'm not alone in this.

Don't the plugins identify which codecs/files they can decode - if not are you litteraly sending the media file to every plugin until one is actually able to read it - that must slow it down no end.?
of

Don't the plugins identify which codecs/files they can decode - if not are you litteraly sending the media file to every plugin until one is actually able to read it - that must slow it down no end.?
of

That's what we do anyway.

OK so as I understand it this will crash every version of of Vlc where a plugin can't cleanly parse metadata and there's no automatic soloution? How about a manual one then? an optional regexp in the options box that allows us the ability to filter what gets added - we can then edit it to remove the dross and retain the media files. A regexp would be better than a simple extension filter as we could filter names of files that a particular plugin can't handle.

We do have the ignore-filetypes option, you know.

That's the opposite of what I was asking for - there were potentially 47000 different extensions back in the days when it was 3 letters - let alone today. Using a media library to scan all my drives would find perhaps 150 "ignore" filetypes and 20 "include" filetypes.
Either an "include" filetype list or again a regexp would better achieve this.