VLC doesn't play video with Dokan about dokany HOT 29 CLOSED

filesystem debug: opening file `K:\[HorribleSubs] Fate Stay Night - Unlimited Blade Works - 25 [720p].mkv
filesystem error: read error: Invalid argument 

I guess you have a read issue.
You should print CreateFile arguments and see the return of it.

from dokany.

[CreateFile()] \[HorribleSubs] Fate Stay Night - Unlimited Blade Works - 25 [720p].mkv, Access: Read, Share: ReadWrite, Mode: Open, Options: None, ID: 459
[GetFileInformation()] \[HorribleSubs] Fate Stay Night - Unlimited Blade Works - 25 [720p].mkv, ID: 459
[ReadFile()] \[HorribleSubs] Fate Stay Night - Unlimited Blade Works - 25 [720p].mkv, Buffer Length: 1024, Offset 0, ID: 459
[GetFileInformation()] \[HorribleSubs] Fate Stay Night - Unlimited Blade Works - 25 [720p].mkv, ID: 459
[ReadFile()] \[HorribleSubs] Fate Stay Night - Unlimited Blade Works - 25 [720p].mkv, Buffer Length: 512, Offset 1024, ID: 459
[GetFileInformation()] \[HorribleSubs] Fate Stay Night - Unlimited Blade Works - 25 [720p].mkv, ID: 459
[ReadFile()] \[HorribleSubs] Fate Stay Night - Unlimited Blade Works - 25 [720p].mkv, Buffer Length: 512, Offset 4151, ID: 459
[GetFileInformation()] \[HorribleSubs] Fate Stay Night - Unlimited Blade Works - 25 [720p].mkv, ID: 459
[ReadFile()] \[HorribleSubs] Fate Stay Night - Unlimited Blade Works - 25 [720p].mkv, Buffer Length: 512, Offset 338605090, ID: 459
[GetFileInformation()] \[HorribleSubs] Fate Stay Night - Unlimited Blade Works - 25 [720p].mkv, ID: 459
[Cleanup()] \[HorribleSubs] Fate Stay Night - Unlimited Blade Works - 25 [720p].mkv, ID: 459
[CloseFile()] \[HorribleSubs] Fate Stay Night - Unlimited Blade Works - 25 [720p].mkv, ID: 459

OS calls create file, that calls get file information and returns 0.
After that, OS calls get file information and returns 0;
After that, OS calls read file and receives the requested buffer and so on
until the cleanup and close functions.

I want to stress that the video file DOES play with Media Player Classic.
It just won't play with VLC.

Thanks!

from dokany.

Calls does not seems to be specials, are you sure of the data returned by your implementation ?

from dokany.

Yes. As I said, it does work with a different player. Just not with VLC.

UPDATE:

Sometimes, this error pops up:

core debug: no art finder modules matched
core debug: art not found for [HorribleSubs] Fate Stay Night - Unlimited Blade Works - 25 [720p].mkv
core debug: using access module "filesystem"
core debug: Using stream method for AStream*
core debug: starting pre-buffering
filesystem error: read error: Invalid argument
core error: cannot pre fill buffer
core debug: removing module "filesystem"
core warning: cannot create a stream_t from access
core debug: finished input
core debug: dead input
core debug: changing item without a request (current 0/1)
core debug: nothing to play
qt4 debug: IM: Deleting the input
...
mkv error: cannot load some cues/chapters/tags etc. (broken seekhead or file)
...
mkv error: cannot find any cluster, damaged file ?
...
es error: cannot peek
...
core error: no suitable demux module for `file/any:///K:/%5BHorribleSubs%5D%20Fate%20Stay%20Night%20-%20Unlimited%20Blade%20Works%20-%2025%20%5B720p%5D.mkv'

from dokany.

Still looks like a read error.
It can happen that some softwares ask to read a offset/size but expect to read a different size.
This could be the case.

I do not think it is a dokan issue and I do not have your code, so I cannot help you more :(

from dokany.

The problem is that there is no error \ exception in the code. The OS doesn't request an offset that exceeds the file's size or receives something smaller than the size of readBytes..

The question is, whether there is some metadata that the OS requests but Dokan doesn't supply to the OS? Can there be a callback that is needed in this situation, but Dokan doesn't implement at all?

from dokany.

Nop,
Metadata are gotten by the read function.
As an example, when you see the preview of a picture or the icon of a exe, it is explorer.exe that open every files of the directory and extract informations with read.

from dokany.

Yeah, I know that the explorer process requests FindFiles for the directory, and then GetFileInformation for each file & also ReadFile to get the thumbnails.. and it works.
Only VLC fails to work for some reason :( :( :(

UPDATE:
Here's a link to an "API Monitor" log file.
The log file was created with API Monitor.

Also, I just noticed that when you try to customize a folder and change it from "General items" to "Pictures", explorer.exe crashes.
Does it happen to you guys?

from dokany.

On my filesystem, I noticed that VLC choked and failed to play the file properly if the contents are not given to it fast enough. Is that your case? In my app, I fetch contents from a remote site, but cache them. After the contents are cached, VLC is happy (from the network is too slow in some videos at least). If your filesystem can't be very fast, try with a video with a very low resolution and bitrate, so it needs to read as little as possible. Just to confirm.

from dokany.

Hi!
You might be right :)
For small files, at first, VLC prints the same error.
After I hit play, VLC prints the error several times and then starts the movie!
It might be a latency problem..
I also use a caching mechanism (Redis), but with big video files, I guess it's still not enough.
What kind of caching do you use?

Thanks!

from dokany.

Well, my filesystem "just" maps remote files locally, but when it is downloaded, it is saved in a cache, so next access to the same file is much faster. If you were doing some kind of filesystem where you (for example) show the contents of compressed archives as a tree, then you probably don't have caching as an option, because it could duplicate a lot of data.

from dokany.

@shlatchz

Also, I just noticed that when you try to customize a folder and change it from "General items" to "Pictures", explorer.exe crashes.
Does it happen to you guys?

I have made a test with last Dokan/Mirror release on Win8.1 and It worked :(

There is a big chance that @suy is right 😃 !
We probably should add good practice to the documentation to explain such case of failure.
Suy, did you faced other case like this ?

from dokany.

@Liryna , I'm using Win7 64bit.
@suy, even when I map a local file to the ReadFile request, instead of fetching it from a remote server,
VLC won't play it.

public int ReadFile(string filePath, byte[] buffer, ref uint readBytes, long offset, DokanFileInfo info)
{
    using (BinaryReader reader = new BinaryReader(new FileStream(@"E:\Downloads\[HorribleSubs] Fate Stay Night - Unlimited Blade Works - 25 [720p].mkv", FileMode.Open)))
    {
        reader.BaseStream.Seek(offset, SeekOrigin.Begin);
        readBytes = (uint)reader.Read(buffer, 0, buffer.Length);
        if (readBytes == 0)
        {
            return DokanNet.DokanError;
        }
        reader.Close();
        reader.Dispose();
    }
    return DokanNet.DokanSuccess;
}

(Drive E is local).

from dokany.

Mapping at every call of ReadFile does not make it faster, it even make it slower.
You should map the file in CreateFile, keep it somewhere and clean it on close.

from dokany.

I tried that as well:

BinaryReader reader = new BinaryReader(new FileStream(@"E:\Downloads\[HorribleSubs] Fate Stay Night - Unlimited Blade Works - 25 [720p].mkv", FileMode.Open));
public int ReadFile(string filePath, byte[] buffer, ref uint readBytes, long offset, DokanFileInfo info)
{
    lock (reader)
    {
        reader.BaseStream.Seek(offset, SeekOrigin.Begin);
        readBytes = (uint)reader.Read(buffer, 0, buffer.Length);
        if (readBytes == 0)
        {
            return DokanNet.DokanError;
        }
    }
    return DokanNet.DokanSuccess;
}

and it didn't help :(

from dokany.

@shlatchz

Please try using the mirror.exe and your video file. If you still fail please provide the video file and tell us which version of vlc player you use.

If you don't fail using the mirror, you can investigate what you are doing different.

from dokany.

I just noticed that the DokanNet repository was updated.
I will try using the newer version and will keep you posted!

from dokany.

Everything works with the new version of DokanNet! Hurray!

from dokany.

I'm using Dokan 0.7.3 on Windows 10, and I'm having the same issue. I can play a song using Windows Media Player but VLC gives an error message. I can view a photo using Paint and Windows Photo Viewer but VLC gives an error message. Please give me some insights, thanks a lot

from dokany.

from dokany.

But plays with windows media player. This is with the new Dokan 0.7.3 RC4, on Windows 10. But it plays on VLC on windows 8.1. What could be the issue? Thanks in advance

from dokany.

VLC logs should help you.

from dokany.

I have just tried it with mirror, it also fails with VLC, but succeeds with windows media player

from dokany.

@Liryna I think there's something new in Windows 10 that you need to investigate. Because even mirror has the same issue. At your own time, test mirror on Windows and try playing media

from dokany.

@bryanbabel you need to investigate on this discussion and special about how shlatchz have resolved it.
Mirror have no issue, it purpose is to stay clean and simple. We will add not advanced reading feature in it. But I agree that making a new sample for such case could be helpful.

from dokany.

Overlapped read problem?

from dokany.

I encountered the problem too, with the latest Dokany and DokanNet. Any solutions?

from dokany.

I had the same problem this week (I was using 1.4.0.1000 and 1.5.1.1000 on Windows 7). An mkv file would sometimes play in vlc, but usually failed (other types like mp4 played ok, but not an mkv file). sysinternals Process Monitor showed INVALID_PARAMETER on ReadFile.

The mirror sample worked.

In the mirror sample, CreateFile returns NotADirectory if you try to open a file as a directory, but my code did not. Adding this check to my code seems to have resolved the problem.

from dokany.

I had the same problem this week

from dokany.