Messages

@dfort:

Ok--here we go. I posted a build for the 5D3.113 which is what I believe most people are using for 2.5k movie files.

Thank you so much. Always wanted to play with adtg_gui!!!
Usually I'm compiling ML in linux but never tried other branches or merging them. Have not gotten to that point ever

Just quick recorded center cropped x264 ...

bb

redownloaded binaries. yeah they dated 02/20/16 . after checking, can admit, that applies exactly the same what I've been talking about in 2 earlier messages.

@g3gg0

I already did

http://www.magiclantern.fm/forum/index.php?topic=13152.msg162572#msg162572

Has anything changed since then?

It's not crashing but, as you said, unusable in real situations because of the standard output log slowing it down so much.
Could not manage to stress it so to see some exceptions.

Passthrough related things are in my message above.

bb

C'mon guys!

I was desperate user of 7D since 2009 and if not g3gg0's hack for dual digic I'd sell it right away long time ago despite nice photos I shot with it. Just 2 things keep me using my 5d3 - glass and ML (Thanx so much to devs and all the comunity here). Canon makes fun of users of XXXXD/XXXD/XXD series. Look at the ridiculous 80D innovations and then look at sony A6300 for 1K USD. It's a lot more advanced peace of hardware than even 1D series canons ever been or will be... ehh... It's aa... I just wanted to let the steam out... sorry

bb

can you redownload from the same URL and test again?
it also contains debug info that will slow down the tool.

With previous no debug version of mlvfs binaries:
Under the root dir (e.g. mount point Z:\ or whatever) where MLV virtual folders are - no file/dir operations possible
Under virtual MLV folders - only directory creation is possible (no subdirs), .MLD created in the orig mlv folder

With last posted debug version of mlvfs binaries:
Under the root DIR - possible: creating dir/file, copying dir/file, not possible: delete created dir/file (as expected)
Under any virtual MLV folder - nothing's possible! no file/dir creation/copying/moving/deleting, hence no MLD directories appear in the orig mlv destination

BTW Am I supposed to see the .IDX .M01 .M02 files in the root dir along with the virtual .MLV folders? They are there in last debug version.

bb

@g3gg0, dmilligan

This exeption 0xC0000005 - generated as far as I understand on "segmentation fault"/"access violation" (accesssing virtual/physical memory - the state of wich is not allowing that access) - occurs when you are stopping and starting playing dng sequence in premiere or resolve. It is similar to the situation when you are copying files and then suddenly canceling it. As g3gg0 mentioned above this randomly was ending by a crash (after printing this exeption as I've seen).

x86 version gives a little bit different numbers:
mlvfs_wrap_read(1505 <- is it line number or what?) and surely another virtual address.

E:\MLVFS_x86>mlvfs_x86.exe Z: --mlv-dir=E:\MLV
mlvfs_wrap_read(1505): caught exception 0xC0000005 at address 0x6A70D72E

In short mlvfs completely crashes very rearly, but exeption is generated almost on every play/stop while prog goes on runnig-hickup-running.

Unfortunatelly I'm not a c/c++ dev in any way.

bb

MLVFS_x86 or MLVFS_x64 to be used with dokan 1.0-rc -> DokanSetup.exe

@g3gg0: Great, Thanx!
Can you look at the creating .MLD folder bug? e.g. make passthrough mode normally work on win.

edit: Exceptions (at 2 addresses) below caught while maniputating DNGs in Premiere Pro, e. g. stoping starting, scrubing back and forward and changing "lumetri color" parameters. MLVFS does not stop entirely just hickups and running while prevew freezes in premiere. It seems MLVFS does not like random file access very much

E:\MLVFS_old>mlvfs_x64.exe Z: --mlv-dir=E:\MLV
mlvfs_wrap_read(1512): caught exception 0xC0000005 at address 0xBED5C877
mlvfs_wrap_read(1512): caught exception 0xC0000005 at address 0xBED5C877
mlvfs_wrap_read(1512): caught exception 0xC0000005 at address 0xBED5C877
mlvfs_wrap_read(1512): caught exception 0xC0000005 at address 0xC476FD74
mlvfs_wrap_read(1512): caught exception 0xC0000005 at address 0xBED5C877
mlvfs_wrap_read(1512): caught exception 0xC0000005 at address 0xBED5C877
mlvfs_wrap_read(1512): caught exception 0xC0000005 at address 0xBED5C877
mlvfs_wrap_read(1512): caught exception 0xC0000005 at address 0xBED5C877
mlvfs_wrap_read(1512): caught exception 0xC0000005 at address 0xBED5C877
mlvfs_wrap_read(1512): caught exception 0xC0000005 at address 0xBED5C877
mlvfs_wrap_read(1512): caught exception 0xC0000005 at address 0xBED5C877
mlvfs_wrap_read(1512): caught exception 0xC0000005 at address 0xC476FD74
mlvfs_wrap_read(1512): caught exception 0xC0000005 at address 0xBED5C877
mlvfs_wrap_read(1512): caught exception 0xC0000005 at address 0xBED5C877

bb

@dmilligan: Thanx for comprehensive explanation

@dmilligan

What the log file in the virtual mlv folder does? As I see it's always empty.

bb

just symlinked:

MLVFS-DIR\dokan.dll -> DOKAN-RC1-DIR\dokan1.dll
MLVFS-DIR\dokanfuse.dll -> DOKAN-RC1-DIR\dokanfuse1.dll

and "mlvfs_x64" works again

@dmilligan

Thanx for your attention. Yes on my hakintosh AE works well. Have to look to the mounted folder.

just try to copy some file not ending in DNG or WAV into the mount

That's exactly what I'm trying to do. Passtrough does not work under win. (I think g3gg0 already mentioned this)
In file explorer: copying file - no error but file is not there (no any .MLD). Making new dir or new file results in error message "file/folder name you are creating is too long" and I have not even input the file name yet.

edit: I'm kinda big fan of the "FAR manager" and using it many years and  just checked copying with it. Can not copy/create file, BUT... can create DIR and MLD appears in mounted folder (can not be deleted after that though, mkdir command does the same). Hmmm... strange and unpredictable behavior. (Bugs! Bugs are everywhere )

bb

and this doesnt happen when all files are in one directory on your HDD?

Yes. Correct

any files being created in that directory?

Nope

After Effects tries to change the dng file metadata but alas...

Z:\M28-1253.MLV>fc /b M28-1253_000000.dng D:\DEST\M28-1253_000000.dng
Comparing files M28-1253_000000.dng and D:\DEST\M28-1253_000000.DNG
00000004: 08 00
00000005: 00 48
00000006: 00 40
FC: D:\DEST\M28-1253_000000.DNG longer than M28-1253_000000.dng

1st real file on HDD changes, others not

bb

Oh! meanwhile Dokan 1.0.0-RC1 has arrived ~20 hours ago! (didn't know it, dev have just told me)

No more experiencing problems with CloneDrive! but ....

@g3gg0: They changed/fixed lots of things and also related to dokan_fuse and dokanfuse.dll default location. Think you have to take a look at it.

edit: all dll and lib names changed so none of the versions of mlvfs work. Situation definitely needs your attention

bb

Don't know. Have not tried any for a while.

SemiOffTopic info

Bad news for windows users using SlySoft's great image mounter "Virtual CloneDrive". Dokan 1.0-BETA driver conflicts and renders useless that mounter. after dokanctl /r d (removing driver) and rebooting things are sorting out. No problem with Dokan 0.8 though (0.8 version has it's own issues, and with latest version of mlvfs I'd recommend 1.0)

bb

robocopy no threads

new builds:
2:35 mlvfs_x64.exe
2:36 mlvfs_x64_avx.exe
2:36 mlvfs_x64_avx2.exe

old builds:
2:37 mlvfs_x64_noavx_nopar.exe
2:38 mlvfs_x64_avx_nopar.exe
2:37 mlvfs_x64_avx2_nopar.exe

Don't even know what to say I guess 4717 files are not sufficient to measure the good difference and I'm too lazy to test it with 15K
In real usage prog is quite snappy and rearly crashes. Used with resolve and it's fine.

Weekend is coming! Will test on my haswell 4790k 4.5ghz in premiere and after effects at home tomorrow.

Thanx g3gg0
bb

u r welcome again

Returned to Dokan v0.8, did tests with x64_avx2_par and x64_avx2_nopar versions ubraptly terminating copy process with ESC. Par version crashed more often.
Once printed "mlvfs_wrap_read(1497): caught exception 0xC0000005 at address 0x7F64C85B" but still running!
Once OS rebooted?!

Installed Dokan 1.0 again, did same tests (also copying to the not cleaned dest dir) par version crashed several times.
Once printed "smlvfs_wrap_read(1497): caught exception 0xC0000005 at address 0x2627C85B" but still running. 
Nopar never crashed.

Switched to x64_noavx_nopar version. Several times ran 3 copy processes simultaneously from the same source to the same destination (file overwrite on) and terminated with ESC or mouse (X) click. No crashes.



bb

Yup, my bad 3 seconds

Windows 10 standard copy:


robocopy time was 2:18. In both cases max rate was at 158-162mb/sec and min rate 75-85. Rate rise at the beginning ~30sec I guess is a cache effect then it normalizes with some spikes. There are 5 mlvs (under 1gb, under 2gb, under 3gb, under 4gb and more than 4gb). Disk usage in resource monitor shows that 3 or 4 MLV files are open simultaneously for reading by mlvfs process.

bb

@g3gg0: u r welcome

Just did copy same files with microsoft tool "robocopy /MT:8" 8 threads turned on. mlvfs_x64_avx2_nopar vs mlvfs_x64_avx2_par -  2:17min vs 2:14min accordingly.
Result is 3 milisecond difference

bb

@g3gg0

I think every binary performance is about the same. Par versions are just CPU hogs (would be nice to test them in random or parralel DNG file access mode). Anyway it is nice to have native 64bit binary and avoiding WOW64
Forgot to mention, test was performed with mlvfs default parameters.

bb

@g3gg0

Machine: cpu Xeon E3-1245 @ 3.4ghz, mem 16gb, 2x 120 gig kingston ssds <- they are no highend ones but not so bad anyway
Folder with MLVs reside on one ssd, mounted to drive Z: -> copied to second ssd.
Copied 19,852,533,609 bytes, 4717 files, 5 folders

Without runing mlvfs:
Result of sequential copy of a large file from 1st to second gives ~220mb/sec.
Result of sequential copy of a dir with a real DNGs of the same size gives ~175mb/sec.

results are below (orange line - mlvfs cpu usage):
























regards
bb

Good point. We'll see... happy bright future is almost over here! Not only for MAC users

Just kidding, have 2 old hackintoshes myself. But love doing/testing video/audio things under win or linux.

If you got 32bit versions and still have an error message then something messed up in your system with ms c++ redistributables.

yes it's linked against debug version of dlls.

get 2 files below and drop to the saem dir with mlvfs.exe:
http://www.dll-files.com/dllindex/dll-files.shtml?vcruntime140d
http://www.dll-files.com/dllindex/dll-files.shtml?ucrtbased

oh forgot to mention get 32bit versions