Error performing BAT pack in Windows with shared storage #104263
Labels
No Label
Good First Issue
Priority
High
Priority
Low
Priority
Normal
Status
Archived
Status
Confirmed
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Job Type
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No Assignees
3 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: studio/flamenco#104263
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
System Information
Operating System(s): Windows 11
Flamenco Version
Is Broken: 3.2
Short description of error
When trying to submit a job to a Flamenco manager, I get the error message:
Blender Flamenco addon will then say "investigating your files" indefinitely. The only way to try again is to reload the .blend file.
Exact steps for others to reproduce the error
I have a NAS that has the IP address 192.168.1.231. I have it mapped as a network drive in Windows as X:\
My .blend file is also on the shared X:\ drive. I tried changing the setting: File -> External Data -> Make Paths Relative, but that did not have any affect.
What did work is that I saved my .blend file to my local C:\ drive. Once I tried submitting a job it then went all the way through. My blender installation is also on the local C:\ drive.
Not sure where it's getting confused, but the 2 network paths given in the error message are essentially the same. I don't believe I used an IP address in the configuration of Flamenco, so not sure where it's pulling that from.
Since Flamenco is working with the .blend file saved on the local C: drive, I have a work-around but wanted to report this error situation.
Thanks for the report. Do you have the complete error message for me, including the Python stack trace? That will tell me more about where in the code the error occurs.
This is due to how Python handles paths on Windows. When I ask Python for the absolute path, it will not just give me
X:\smiller\who_disliked_my_video\who_disliked_my_video_v7.flamenco.blend
but it'll also resolve theX:
drive to where it's stored, which apparently leads to\\192.168.1.231\truenas_smm\smiller\\who_disliked_my_video
. It's annoying, as it makes it harder to compare paths with each other.Below is the output from the console. I'm not sure how to get the Python stack trace, unless that it's below. If you can tell me high level how to get the stack trace I should be able to figure it out. If you need any other information, please let me know.
Just a thought, might be able to do something like search the path and if it contains an IP, do some other type of call to translate the IP to the drive letter. Don't know if that makes sense in this case, but something to consider.
Correct, in my environment X:\smiller is the same as \\192.168.1.231\truenas_smm\smiller. So if I put both of the paths into File Explorer, they both go to the same network share folder.
Thanks for the extra info. Unfortunately the stack trace isn't in there, and getting more info might be a bit tricky. In any case, could you give Flamenco 3.3-beta3 a try? There have been some fixes in there, and so this might already have been fixed. If so, it would save me some digging. You can download the beta from https://flamenco.blender.org/download/#go-experimental
Sorry, same error with 3.3-beta3. I made sure I was using 3.3 manager, worker, and Blender add-on.
I created a ticket but I'm having very similar issues to Shaun so I'm going to follow along here. I haven't tried the beta build but I'll try it on Monday.
The beta build is 3.3-beta0, which is older than the 3.3.1 release, so save your time and don't bother with that one ;-)
@dr.sybren is there any other information that could be helpful. This is the only thing stopping us from using Flamenco in our studio. We're really looking forward to using it!
Having the .blend file on the local C:\ drive is the work-around that I used. If you haven't tried that yet, I would suggest seeing if it works or not as a test render. If it does work, then you might have to adjust your process / workflow to compensate.