I created a dozen or so tasks and bundles, exported them out to a folder on my PC, renamed them, and moved them to a shared folder location for testing. Now, when I try to load in to a new project, the UI gives an message saying that 0 bundles/tasks were loaded successfully.
In some instances I noticed that even when I get the message that zero have been loaded in, I notice that some tasks/bundles have still been loaded in. I have tested this several time and sometimes it loads in some of the tasks, sometimes none of them.
Are you aware of a bug preventing tasks to be loaded in? Is it likely due to the fact that I both renamed and relocated the tasks?
Yes, the .glyph extension was kept. I dug in a little bit more and have more information that might be helpful.
.glyph files stored on local HDD
Importing tasks and bundles from a local hard drive works as expected without any issues.
For additional context, the tasks and bundles are stored in a directory that is synced to Onedrive but the files are kept locally on the machine itself. I did notice that if the files werenāt kept locally on the drive and were cloud hosted that there were some issues importing into the glyph plugin and the files needed to download from the cloud before being able to load in.
.glyph files stored on physical network drive
I moved the glyph files to a shared network drive that all users have access to. The intent was to create a channel in Avail Where users could access company wide tasks and bundles.
After doing a little testing with this setup I have a little more insight into what I think is happening. When I import a task or a bundle by dragging from the shared network drive and immediately click āimportā in the Glyph UI, I almost always received the zero tasks/bundles imported error previously mentioned.
If I wait a few seconds before pressing āimportā - after dragging in the desired tasks/bundles from the network drive - then Glyph will successfully import them. I generally did not have to do this when importing the tasks/bundles from my local hard drive because the read and write speeds are faster than our network drive - but in the rare instances where I did experience issues waiting a few seconds before pressing āimportā resolved them.
My best guess at what is happening
My best guess as to what is happening here is that glyph is copying the task/bundles to some local file or memory before making them available in the user interface and due to the slower speeds of the network drive there isnāt enough time for it to copy the file information before pressing the āimportā button. Does this sound like a reasonable assumption?
If this is the case, then it is easy enough to wait a few seconds before pressing import.
@Elliottk, as always, thank you very much for your detailed explanation and investigation of the issue.
Youāre absolutely right in your assumption. If files stored in the cloud or on a network drive are not fully synced or are still being processed, Glyph may attempt to import a file that hasnāt completely transferred yet. This can result in the issue you described.
Iāve created a ticket for this issue, as well as for the āzero tasks/bundles importedā error, and weāll investigate a possible solution for the upcoming release.
As always, please feel free to share any additional feedback or suggestions on how we can improve Glyph.
Thanks again @Elliottk , as @Miguel already said, this is a super interesting find. Iāve definitly experienced this issue with other apps that use files on shared drives before.
One potential workaround is to use a ākeep on deviceā setting for the folder with the .glyph tasks and bundles, for anyone using them, so they are always there and up to date.
We may look into giving you the option to also store tasks & bundles in the cloud in the future, where we can control if/when the files are downloaded before being imported and such, as another way to potentially avoid this in the future - and give people a way to share tasks without having to send files back and forth.
