WIN 10 64 bit - App starts process but slow to presents GUI

[motioncircus]

Downloaded and installed autoEdit-3-1.2.7.exe

Ran the exe (with Admin Rights), which started a Digital Paper Edit app (32 bit) process in Task Manager

To Reproduce Steps to reproduce the behavior:

1. On a 64 bit WIN 10 Pro N machine, download the latest Pre-Release version
2. Run the EXE
3. Check Task Manager to see process Digital Paper Edit app (32 bit)
4. Notice there's no application presenting

Expected behavior The App GUI to appear

Desktop (please complete the following information):

• OS: WIN 10 Pro N - 64 bit - Version 10.0.18363 - Build 18363
• Chrome -
• Version Version 81.0.4044.138 (Official Build) (64-bit)

[motioncircus]

After writing this post, I find the App is now open... Perhaps it's just a LOT slower than I expect. I will report back if this is an intermittent issue Cheers

[pietrop]

Thanks for flagging this @motioncircus ! And thanks for the update

Interesting, it should probl be the 64bit version of the app rather then the 32bit.

based on electron builder docs it should be xcode10.2 on Travis, while in the current setup I have xcode 11 But not sure if this would effect the 32bit vs 64 bit.

And/or based on same docs, could add --x64 flag to make the arch explicit, in the npm script npm run build:mwl:publish:always

Following up on my comment on a related issue https://github.com/pietrop/digital-paper-edit-electron/issues/43#issuecomment-629300616 in v 1.2.7 I removed the electron remote module for the most part, but I suspect that there’s also some re architecting to do, to speed up performance. the electron “backend” at the moment is connect to the react client via a global window variable which might be effective performance. And need to figure out a better way for the two to communicate, while maintaining a modular architecture

some other clues in the electron docs about performance as well.

But back to the windows issue, since I don’t have a windows machine, would you be able to try and package/build locally with the 64bit arc flag and see if that improve startup time?

It would be a matter of following these instruction in the README#setup

to get setup

And modifying this line in package.json

- "build:w": "cross-env NODE_ENV=production electron-builder -w",
+"build:w": "cross-env NODE_ENV=production electron-builder -w --x64"

Before running

npm run build:w

[motioncircus]

Hi Pietro,

thanks for your swift response.

I'm very hopeful of being able to use Autoedit again and hoping I won't suffer the same issues I had a while back (maybe a year or two), where I struggled to replace the proxy files I used in my Resolve Edit, with the full resolution source footage files.

It seemed a simple path replacement task but caused me more headache than I could handle and I gave up due to deadline demands.

I'm a novice script hacker but I understand you would like me to build from source with your proposed variations. However when I run 'nmp' in my windows command prompt, I get this error:

[image: Capture.JPG]

nmp, is a linux command is it not?

I do actually have the Debian GNU/Linux command app https://www.microsoft.com/en-us/p/debian/9msvkqc78pk6 on my machine, am I to understand you mean for me to build using that?

To my novice mind, building an app using Linux would build a Linux APP, not a WIN10 app. However I stand to be corrected

I'll give it a go but, would you suggest I'd get better results running a full separate Linux install?

I don't trust Windows to run Linux properly. I used to have a separate Debian workstation but it got jettisoned in a recent house move.

N

Nigel Haslam *| Director *

Motion Circus Pty Ltd. Byron Bay t*: + 61 2 8007 7338 **|m: * + 61 403 020 126 w: www.motioncircus.com http://www.motioncircus.com/ link to website http://motioncircus.com

On Sun, May 17, 2020 at 11:27 AM Pietro [email protected] wrote:

Thanks for flagging this @motioncircus https://github.com/motioncircus ! And thanks for the update

Interesting, it should probl be the 64bit version of the app rather then the 32bit.

based on electron builder docs https://www.electron.build/multi-platform-build#travis-macos it should be Xcode xcode10.2 on Travis, while in the current setup I have xcode 11 https://github.com/pietrop/digital-paper-edit-electron/blob/master/.travis.yml But not sure if this would effect the 32bit vs 64 bit.

And/or based on same docs, could add --x64 flag to make the arch explicit, in the npm script npm run build:mwl:publish:always https://github.com/pietrop/digital-paper-edit-electron/blob/master/package.json#L19

Following up on my comment on a related issue #43 (comment) https://github.com/pietrop/digital-paper-edit-electron/issues/43#issuecomment-629300616 in v 1.2.7 I removed the electron remote module for the most part, but I suspect that there’s also some re architecting to do, to speed up performance. the electron “backend” at the moment is connect to the react client via a global window variable which might be effective performance. And need to figure out a better way for the two to communicate, while many aiming a modular architecture https://textav.gitbook.io/textav-event-2018/projects/autoedit-panel-for-adobe-cep-pietro

some other clues in the electron docs about performance https://www.electronjs.org/docs/tutorial/performance as well.

But back to the windows issue, since I don’t have a windows machine, would you be able to try and package/build locally with the 64bit arc flag and see if that improve startup time?

It would be a matter of following these instruction in the README https://github.com/pietrop/digital-paper-edit-electron/blob/master/README.md

to get setup

And modifying this line in [package.json] ( https://github.com/pietrop/digital-paper-edit-electron/blob/master/package.json#L14 )

• "build:w": "cross-env NODE_ENV=production electron-builder -w", +"build:w": "cross-env NODE_ENV=production electron-builder -w --x64"

Before running

npm run build:w

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/pietrop/digital-paper-edit-electron/issues/44#issuecomment-629728907, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACCDOEZDESBFYRHGOZZ5C7TRR44PFANCNFSM4NDERSYQ .

[pietrop]

Ok no worries, there should be another release coming up, in the release section 1.2.8 Where I added the 64 bit flag. 🤞 ( as of now it’s still building, check back in a bit)

Re npm, never mind those instruction, is probably a bit more involved, you’d need to install node ( the programming language) and npm is the package manager (works cross platform) but we might be able to test these changes without going through all that trouble.

And yeah it be good to get some feedback when you get to reconnecting the media in DaVinci Resolve.

One thing tho, is that autoEdit (2 and 3) works best if you import the original source (eg the media from the cards, or the source media you want to work with in the edit, rather then proxies if that makes sense), and let it create the audio and video preview for the app and the STT engine from it (uses ffmpeg under the hood), so that it reads the metadata from the original source footage and uses that info to create the sequence so that it can reconnect to it. ( this is mostly the EDL option)

[motioncircus]

Thanks,

I've heard of Node and once even tried to get my head around React but failed. I'll hang out for the next version from your end as you suggest.

I'm wondering about your apparent suggestion that I could use the Autoedit previews in place of proxies.. I'd love to be able to do that but doesn't that involve uploading the hundreds of GIGS of my 4K camera files to AssemblyAI or similar?

I haven't found a proxy settings dialogue and, when I considered trying such an approach, couldn't even locate the previews on my system.

Any suggestions?

Nigel

Nigel Haslam *| Director *

Motion Circus Pty Ltd. Byron Bay t*: + 61 2 8007 7338 **|m: * + 61 403 020 126 w: www.motioncircus.com http://www.motioncircus.com/ link to website http://motioncircus.com

On Sun, May 17, 2020 at 12:02 PM Pietro [email protected] wrote:

Ok no worries, there should be another release coming up, in the release section https://github.com/pietrop/digital-paper-edit-electron/releases 1.2.8 Where I added the 64 bit flag. 🤞

Re npm, never mind those instruction, is probably a bit more involved, you’d need to install node ( the programming language) and npm is the package manager (works cross platform) but we might able to test these changes without going through all that trouble.

And yeah it be good to get some feedback when you get to reconnecting the media in DaVinci Resolve.

One thing tho, is that autoEdit (2 and 3) works best if you import the original source (eg the media from the cards, or the source media you want to work with in the edit, rather then proxies if that makes sense), and let it create the audio and video preview from it, so that it reads the metadata from the original source footage and uses that info to create the sequence so that it can reconnect to it. ( this is mostly the EDL option)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/pietrop/digital-paper-edit-electron/issues/44#issuecomment-629731379, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACCDOE7LGW4SEKD2WEC5PZTRR5ARVANCNFSM4NDERSYQ .

[motioncircus]

I just noticed your update and downloaded it but Windows decided it was a Virus and 'removed the threat'.

Any suggestions?

N Nigel Haslam *| Director *

Motion Circus Pty Ltd. Byron Bay t*: + 61 2 8007 7338 **|m: * + 61 403 020 126 w: www.motioncircus.com http://www.motioncircus.com/ link to website http://motioncircus.com

On Sun, May 17, 2020 at 12:12 PM Nigel Haslam [email protected] wrote:

Thanks,

I've heard of Node and once even tried to get my head around React but failed. I'll hang out for the next version from your end as you suggest.

I'm wondering about your apparent suggestion that I could use the Autoedit previews in place of proxies.. I'd love to be able to do that but doesn't that involve uploading the hundreds of GIGS of my 4K camera files to AssemblyAI or similar?

I haven't found a proxy settings dialogue and, when I considered trying such an approach, couldn't even locate the previews on my system.

Any suggestions?

Nigel

Nigel Haslam *| Director *

Motion Circus Pty Ltd. Byron Bay t*: + 61 2 8007 7338 **|m: * + 61 403 020 126 w: www.motioncircus.com http://www.motioncircus.com/ link to website http://motioncircus.com

On Sun, May 17, 2020 at 12:02 PM Pietro [email protected] wrote:

Ok no worries, there should be another release coming up, in the release section https://github.com/pietrop/digital-paper-edit-electron/releases 1.2.8 Where I added the 64 bit flag. 🤞

Re npm, never mind those instruction, is probably a bit more involved, you’d need to install node ( the programming language) and npm is the package manager (works cross platform) but we might able to test these changes without going through all that trouble.

And yeah it be good to get some feedback when you get to reconnecting the media in DaVinci Resolve.

One thing tho, is that autoEdit (2 and 3) works best if you import the original source (eg the media from the cards, or the source media you want to work with in the edit, rather then proxies if that makes sense), and let it create the audio and video preview from it, so that it reads the metadata from the original source footage and uses that info to create the sequence so that it can reconnect to it. ( this is mostly the EDL option)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/pietrop/digital-paper-edit-electron/issues/44#issuecomment-629731379, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACCDOE7LGW4SEKD2WEC5PZTRR5ARVANCNFSM4NDERSYQ .

[motioncircus]

Hey Pietro,

I managed to successfully downloadautoEdit-3-1.2.8.exe https://github.com/pietrop/digital-paper-edit-electron/releases/download/1.2.8/autoEdit-3-1.2.8.exe by disabling Real Time Virus Monitoring, however, on restarting my machine, Windows Defender have me this error:

Which looks more serious than your normal Windows Defender fake panic.

Is it possible that this *Feury.c!cl *virus has crept into your system?

N

Nigel Haslam *| Director *

[motioncircus]

Ok,

I've managed to wrangle Defender into silence on the matter of trojans and fired up your latest version, (autoEdit-3-1.2.8.exe, )however, as you see below, Task manager still seems to think that it's running the 32 bit version of the app.

Nigel Haslam *| Director *

[pietrop]

Not sure re virus warning, probl not supposed to happen. they are packaged, built and shipped to the release section via Travis CI, a third party, with virtual machine for OSX.

Building another release 1.2.9, where tried to tweak the settings to see if it makes it for arch 64. 🤞

I'm wondering about your apparent suggestion that I could use the Autoedit previews in place of proxies.. I'd love to be able to do that but doesn't that involve uploading the hundreds of GIGS of my 4K camera files to AssemblyAI or similar?

what autoEdit does under the hood, is that it creates an audio preview / version of your media, (that is very fast to do even on large files) and then only sends that to the speech to text engine, eg assemblyAI.

I haven't found a proxy settings dialogue and, when I considered trying such an approach, couldn't even locate the previews on my system.

It also creates a lower res mp4 video preview, To use within the autoEdit programme to show you the preview. If that takes to long and the transcript is ready you’d be able to interact with it via the audio preview while the video preview is being created.

These audio and video previews are generally used only by autoEdit. I could make them available to “export”/“save” externally to the programme if useful tho.

If you have proxies made via the editing software, as I guess in a 4K workflow, you might not edit directly on those rushes (correct?), I’d be curious to look at the steps of that workflow in more details to see what might be an optimal way to integrate it with autoEdit, once we figure out the 32 vs 64 bit issue.

[motioncircus]

Thanks again for your support,

I'm greatly relieved to hear that AutoEdit is smarter than I'd guessed and only uploads low resolution versions for transcription. It might be worthwhile to mention this for others as dumb as myself.

I will try my normal workflow, which is simply to import my full resolution files (mostly 4K camera files), then to use DaVinci Resolve to create efficient low res proxies.

Very excited at my first test edit which worked straight out of the box.

I'll grab your next release as soon as I see it.

Cheers

Nigel

Nigel Haslam *| Director *

[pietrop]

Also when you get a chance could you check if autoEdit 2 windows version was also in 32bit?

https://opennewslabs.github.io/autoEdit_2/

Releases page https://github.com/OpenNewsLabs/autoEdit_2/releases

[motioncircus]

Sure,

N

Nigel Haslam *| Director *

[motioncircus]

It will be tomorrow I'm afraid,

I'm in Australia a bit out of sync with you I guess

Nigel

Nigel Haslam *| Director *

[motioncircus]

Morning!

Some news from downunder!

I've downloaded your latest version *autoEdit-3-1.2.9 *and thought I should flag that the download is double the size of the last one, at 420MEG.

The program is very slow to start still but it runs

Sorry to report that it's still showing up in Task Manager as 32 bit:

FYI I just fired up my old install of Autoedit2 - autoEdit2-1.0.15.exe

And the process shows up in Task Manager like this:

I've just done some tests

*Test 1 *made a paper edit, using 1080P proxiy files created in Handbrake from my 4K source footage and *successfully *imported it into DaVinci Resolve, .

Test 2 made a paper edit using the original 4K source footage which failed to import, throwing this errror in Resolve:

So it would appear that, either I'm doing something stupid (highly possible), or Autoedit doesn't work with 4K files but I can't understand why because I've looked at the EDL that it spits out and there's nothing in there to do with resolution.

Any suggestions?

Nigel

Nigel Haslam *| Director *

Motion Circus Pty Ltd. Byron Bay t*: + 61 2 8007 7338 **|m: * + 61 403 020 126 w: www.motioncircus.com http://www.motioncircus.com/ link to website http://motioncircus.com

On Sun, May 17, 2020 at 6:08 PM Nigel Haslam [email protected] wrote:

It will be tomorrow I'm afraid,

I'm in Australia a bit out of sync with you I guess

Nigel

Nigel Haslam *| Director *

Motion Circus Pty Ltd. Byron Bay t*: + 61 2 8007 7338 **|m: * + 61 403 020 126 w: www.motioncircus.com http://www.motioncircus.com/ link to website http://motioncircus.com

On Sun, May 17, 2020 at 6:06 PM Nigel Haslam [email protected] wrote:

Sure,

N

Nigel Haslam *| Director *

Motion Circus Pty Ltd. Byron Bay t*: + 61 2 8007 7338 **|m: * + 61 403 020 126 w: www.motioncircus.com http://www.motioncircus.com/ link to website http://motioncircus.com

On Sun, May 17, 2020 at 6:04 PM Pietro [email protected] wrote:

Also when you get a chance could you check if autoEdit 2 windows version was also in 32bit?

https://opennewslabs.github.io/autoEdit_2/

Releases page https://github.com/OpenNewsLabs/autoEdit_2/releases

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/pietrop/digital-paper-edit-electron/issues/44#issuecomment-629759341, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACCDOE2PQCHZNWP5OLE7DI3RR6K77ANCNFSM4NDERSYQ .

[pietrop]

Thanks for looking into it @motioncircus !

download size

Download size is probably double because it is now trying to do 32bit and 64bit in the installer.

virus warning

Do you still get a virus warning with latest version of autoEdit?

4K tests

The tests you did was with autoEdit 2 or 3?

What would be different in a 4K file?

The other thing to try is make a short sequence in Resolve with a few 4K clips, and export an EDL from Resolve to compare. (You could copy paste the content of the file here, might be easier then sending an attachment via GitHub)

screenshots

Seems like you might be replying to the GitHub email notifications with the screenshots, and the images are not coming through.

If you visit https://github.com/pietrop/digital-paper-edit-electron/issues/44 you should be able to add them here directly.

[motioncircus]

Hi Pietro, I've edited my replies above by dropping in the images - they seem to work as links but not directly visible in the post. Perhaps editing is different than direct posting because I've checked this post and the images are visible directly in preview.

virus warning

No, I didn't get the warning with the latest download but I did have Win Defender's 'real time virus monitoring' turned off, which is how I got around the issue yesterday.

4K tests

Were done in autoEdit 3

The Resolve import error I'm getting (on an autoEdit created EDL), says the clips fail to link because the timecode extents do not match any clip in the media pool

Which makes me wonder if it's possible that autoEdit-3 creates and uses timecode in it's previews that are stored in a different way, or a different place, than the timecode in the 4K files?

Resolve test EDL export and comparison

I will make a new set of tests, using 4K files directly in autoEdit-3 AND a simple timeline created in Resolve and export the EDLs for comparison.

Back soon Nigel

[motioncircus]

Here's a screengrab of my two test EDLs, side by side in Notepad++

There are some minor differences, one of which rings a bell from the last time I tried to figure this problem out - the fact that Resolve timelines default start at 01:00:00:00

The other is that Resolve sees the start time of each source clip as 02:xx:xx:xx where autoEdit sees source start times as 00:xx:xx:xx

I wonder if my rendering out proxy files eliminates this 4K two hour offset?

I hope this helps.

Nigel

[motioncircus]

OK I've done some research and testing and it's definitely a timecode offset issue because if I hack the EDL output of autoEdit, to add the required offset (and it's not just hours but minutes too) then it works imported into Resolve.

It seems my camera, a Panasonic GH4, is a bit flakey with timecodes:

This is a quote from the manual.

• Time codes are not recorded on Motion Pictures recorded when the [Rec Format] is set to [MP4].

And of course I've been recording in MP4.

The timecodes on my generated proxies start at 00:00:00:00, hence them working fine when the edl is exported from autoEdit.

I might make a test using my GH4 with MOV format, after I check why I was using MP4, it might have been.

If you can think of a better workaround I'd love to hear it. Nigel

[pietrop]

That’s great, thanks!

4K EDL

Seems like it’s also expecting the audio to be on a separate EDL track?

I had a similar problem with .mxf files. But those where easier to recognize, because of the file extension, and if there’s an MXF in one of the clips autoEdit creates 3 EDL Tracks, one for video and two for audio.

file metadata

If the time codes are not recorded then in theory it would threat it as zero in autoEdit, but you said you added an offset manually?

autoEdit (both 2 and 3) reads the file metadata to see if it needs to compute a time code offset when creating the sequence. I’d be curious to see what are the metadata it reads for that 4K mp4.

The easier way to do this, is If you go in autoEdit2, if you have imported a 4K file in there already (?), and in the transcript view, under export option you choose json. You can then share the content of that json file here; or if you are familiar with json, open that with notepad++ 📝 and only share values of the metadata attribute. If that makes sense?

Otherwise there’s also a way to do it in autoEdit3 but is a little more complicated to explain. But can do so if the autoEdit2 option is not feasible.

EDL format

These are some notes I made a while when working on the module to create the EDL programmatically about how the EDL format works https://autoedit.gitbook.io/documentation/appendix/edl-format

[pietrop]

But yeah maybe test with mov first and see if that solves the problem before going down the metadata time codes rabbit hole 🐇 🕳

[motioncircus]

OK,

Yes there was an offset which I edited, so perhaps the GH4 manual is wrong, or a firmware update changed the timecode to allow it to be generated on MP4s.

Here's the (full) json export ((both flavours of json), from one of my original (MP4) 4K files imported into autoEdit3

4k_SOURCE_jsonAutoEditTest.zip

FYI Version 2.1.9 takes a full 4.5 minutes to start after double clicking the exe file - longest program load I've had for twenty years or so and very suspicious.

[pietrop]

Sorry, unfortunately in autoEdit 3, the transcript json doesn't return the metadata, unlike autoEdit 2.

But here's how to do it in autoEdit 3

1. open autoEdit 3
2. go to the transcript view
3. click at the same time cmd+ option+i (not 100% sure keyboard combination on windows - maybe windows key + alt + i) OR in the menu under view --> Toggle Developer Tools
4. This will show some dev tools. at the top, choose console if it's not already selected.
5. in the console, you should see a json object that can be expanded, and you should be able to see the metadata info - see example below

[motioncircus]

file metadata If the time codes are not recorded then in theory it would threat it as zero in autoEdit, but you said you added an offset manually?

That's right.. despite what the manual says, you can see a 2 hour odd offset (in the right hand side of the Notepad++ screengrab above)

I've just tested an MOV but the problem remains see below:

It would appear that autoEdit isn't able to read the offset and add it to it's EDL output.

As you noticed, there is something different in the audio track creation too. Even when I bring in an EDL of a correctly adjusted timecode version, I can't see the audio in resolve until I manually create a new timeline and then switch back to my imported one.

Thanks for your help. I'm really hoping to be able to use this and I feel so close

N

[pietrop]

and, yeah re long startup time, might have to rollback to an earlier version

[pietrop]

and yeah see previous comment https://github.com/pietrop/digital-paper-edit-electron/issues/44#issuecomment-629920475 if you could see what metadata are actually being read by autoEdit 3, it would help narrow it down 🤞

[motioncircus]

I'm trying to follow your awesome guide GIF but my console seems a little different.. can't quite locate the json object

[pietrop]

Ok you can share a screenshot of where you got so far

[motioncircus]

A loong slooow restart fixed the view

[motioncircus]

Looks like no timecode offset was picked up even from my MOV clip.

If you don't have anyone else suffering from this issue, I could simply transcode all my camera clips on injestion to my system, so they all have default timecode starting at zero. It works at least.

[motioncircus]

I think there may actually be another setting in the camera, instead of an accumulative timecode run, a fresh zero start for each clip. I might try that out too.