Scanning has not yet started. Abort?

Flame Flame Questions
43

It happens on my Macs occasionally as well. Maybe once a month, last time was about a week ago. I seem to remember that it was hung on access to some volume, may have been the NAS. Don’t want to add useless speculation, but affirming that you’re not the only one dealing with this.

From a software perspective it seems like the background process has stalled waiting for an I/O condition. Is there any log (or could one be created) that dumps out what volumes Flame thinks there are and which ones it has access to? Then we could contrast compare that to a time where it ran without stalling and narrow down which volume is causing the stall, which makes it more actionable.

Or make this a non-blocking operation. What’s difficult is once scanning stalls, you can’t access any files, even files on a volume that seems perfectly fine from what I remember.

44

Thanks for the additional information Jan. As we can see, this is a very random issue, which makes it very hard to debug on our side.

Have you tried to press the Refresh key after seeing the issue?

We do have many logs that can be seen from the Service Monitor / Diagnostic tab. if you could get the data to our Support team and highlight the time you have seen the issue would be very helpful.

45

Hi Stephane,

Totally understand on the challenge. These are the worst bugs to chase.

Let me look in the logs and see if my last hang is still in there. Otherwise, next time it happens, I’ll definitely grab detail and send them over.

46

Thanks a lot!

47

The logs on that system don’t go far enough back to cover my last ‘scanning error’.

However, while looking for it, I found that the service monitor has a handy test for ‘Full Disk Access’ which may be worth running. You do have to include Service Monitor in Full Disk Access, otherwise it can’t run its test and gives an error, like it did just for me.

Does the installer currently take care or check full disk access, like it does for some other apps?

One complication is that several of these access permission are on a per-version basis. I currently have 6 of some of these listed…

System Integrity Protection status: enabled.

System Integrity Protection will prevent applications and services from reading or writing in some areas of the file system.

Granting Full Disk Access to these applications and services will be necessary to make all features available when System Integrity Protection is enabled.

Flame Family Application and Services

✔ Stone+Wire Database Server (sw_dbd) has Full Disk Access.

✔ Stone+Wire Probe Server (sw_serverd) has Full Disk Access.

✔ IFFFS Wiretap Server (ifffsWiretapServer) has Full Disk Access.

✔ WireTap Gateway Server (wiretapgateway) has Full Disk Access.

✔ Flame Multi-Purpose Daemon (DLmpd) has Full Disk Access.

(Not having full disk access might prevent important features from working)

Other Services

❌ NFS Service (/sbin/nfsd) not found in Full Disk Access database.

(Not having full disk access might prevent collaboration with other machines on the network)

Tips: You can use <command> + <shift> + g to navigate to any path in the Full Disk Access browser.
48

all mine already have the Full Disk Access - its the first thing i allow when the updates get added.

Just had the same problem again, and this time i ran a terminal command…

sudo /opt/Autodesk/io/bin/vic -a -l

which is used to check all stonefs volumes without making any changes. It found all the Stones - which just happened to be on the external drives.Flame started correctly next time.

I doubt this fixed anything though, because when i do have the scanning not started - i can still see all the clips and files already used in the project - so it must be seeing the Stones on the various external storages…it just fails to allow any other access to those drives.

49

Maddening.

Did you check the diagnostics tab in Service Monitor for anything out of the ordinary?

50

i looked but i don’t really speak programmer, so its all just nonsense to me.

51

Might still be helpful to send to Stephane and support, in case they can spot a useful nugget…

52

Yep, send any useful data or investigation you have done to our Support team so they can go through all this.

53

In case anyone has this problem, I encountered it and flame wouldn’t see drives etc and it turned out to be the IP address in the “/etc/hosts” file contained the wrong addresses and current hostname was wrong , fixing both of those solved the issue and changing the IP address to static new one since it had a conflict with a system address, so not totally straightforward but that was it on my end.

54

Did your system see those drives before, or was this a new setup?

My issue happens randomly…it can work fine for weeks but then suddenly stop seeing the drives. This can happen partway through a day, after restarting Flame with a different project.

All my ips are static, so surely if the host file was the problem it should happen everytime?…or maybe not!

55

Mine was random it would work for a few hours then it would disappear, it’s super weird and I don’t understand or why it would be intermittent but the minute I changed that file and the addresses it all worked

56

I think one of the clues maybe ‘restarting Flame’. If I’ve decoded it correctly, these background processes don’t run all the time, but get started and shutdown with the Flame UI. Which is why (at least on Mac) you can have multiple versions installed.

Restarting this process would be the time that it resolves network addresses and other config details. Even if the IPs of your main system are static, there’s still a chance of an IP address conflict if you have DHCP configured on the router and don’t make your DHCP range exclusive of what you’re allocating static IPs from.

This may still be reaching far into the unlikely, just highlighting a detail worth checking.

You could log into your router, check DHCP config, read the current DHCP table and see what it allocates. Also there are various iPhone apps which can easily scan your LAN and tell you who is talking on what address.

Generally DHCP will retain a MAC-IP binding as long as the corresponding device remains active. But if something gets turned off for longer than the lifetime of the lease, next time it might get a different address, which could explain the sporadic nature of this. Could be a smart TV, an iPad, printer or other gadget in the building.

All of this would only matter if Flame doesn’t use the local loopback address of 127.0.0.1 to talk to the local Wiretap service, but instead tries to resolve an actual hostname / IP address.

If you dig into the S+W docs and config files, there’s some mention of local addresses. My Linux Flame is currently off, so can’t check how it’s setup.

/opt/Autodesk/cfg/network.cfg
/opt/Autodesk/sw/cfg/sw_framestore_map

I’ve experienced these issues on my Mac from time to time, but never my Linux system. Coincidentally my Mac uses DHCP, while my Linux Flame has a static IP outside of the the DHCP application range.

That said, this may still be a red herring, but worth a bit of digging.

57

just checked my host file, and it says the localhost is 127.0.0.1, and the ip addresses shown match the ones my mac is using, and also is correct for the second Flame on our network.

The corresponding file on that other Flame is also matching all the numbers.

I do know that all the IP settings on both our systems are static ones.

I know nothing of Routers and DHCP - thats all controlled by our IT dept - and i have no faith they know what they are doing

58

Makes sense.

How did you get the static IPs you’re using allocated? Did IT give them to you?

59

yes. Always request static ips when i know i’m getting new kit. Makes it easier than having random settings for everything!

60

I’m also having this issue today, do you have a way to fix it? :sob:

61

Not yet…Autodesk have been unable to reproduce the problem so have not been able to come up with a solution.

Baffled why no other software has this problem though!

62

So many issues.