It is due a misuse of the undocumented filesystem::get_canonical_path() API. My plugin which use a filesystem subclass, was returning true in this function. It happens that in some cases (dropping the directory in a playlist is one of them) foobar core calls this function (from filesystem::g_get_canonical_path()) even if filesystem::is_our_path () or file_system::supports_content_type() returns false. That API indeed isn't properly documented, I'm sorry for that. I wasn't really expecting third party components to try to reimplement it. Thanks for bringing this to my attention though, I will provide better documentation with the next SDK update. Anyway, get_canonical_path() is called without is_our_path() checks because it has to accept local filesystem paths without the file:// and turn them into proper file:// strings. You should perform checks for the path being something that you recognize on your own (as you can figure out from filesystem::g_get_canonical_path() code).Curiously since services seems to not be initialized in the same order between foobar runs, sometimes my filesystem impl was registered after the legit file:// impl and there was no bug. This is by design. Order of services is undefined and randomized on each startup. Otherwise you could end with DLL loading order always giving you the scenario not triggering service order dependency bugs on your system and never notice anything wrong or be unable to reproduce problems reported by users. Some components that were in circulation long ago did exactly that, sometimes even without the author knowing that there was something wrong ("works for me").I have another question related to opening files. This plugin defines an input_entry subclass as well as a filesystem subclass. The only filesystem subclass purpose is to allow on upnp:// items the same file operations than http, namely copying remote files. The file operation dialog uses the item path to know what is the file extension for the copied file. I don't have any extension in my upnp:// paths so the copied files would be without extension. To overcome this I added the correct extension to my upnp:// path but in that case, when playing an upnp:// item in most case input_entry::open() was called but to my surprise in other cases it was filesystem::open(). In the case filesystem::open() was called it would then turn to later call the open() function of the http input_entry, which obviously don't work. So it seems the behaviour is different if a path has an extension or not. In my case I'd like it to have an extension to make file operations find the extension, but the call to filesystem::open() gets in the way in normal decoding. Any idea or workaround to solve that issue ? I'm sorry but I can't think of any way to deal with this right now. This is an inherent negative side effect of the custom input trick. I suppose you could provide a custom context menu command to download files instead and get rid of the filesystem service entirely. I'll consider adding some other way for the File Operations component to determine target file extensions.