media offline Edit-Share

[David Bogie]

Sorry, that’s a real puzzler. I’d have to conclude it’s an issue with the storage system which, sad to say, I’ve never heard of. Does the mfr have a user forum or online tech support?

I’d start debugging by capturing a specific clip, carefully noting its name and location, and then seeing if you can get it to go offline.

bogiesan

[Matt Lyon]

Yeah, I’d have to agree with David that it is likely an issue with the Edit-Share. Could it be a problem with file names being too long? I worked on a project a few years back where we used a Linux based SAN (that used some kind of software layer to stay compatible with the apple double file system). If file names exceeded 32 characters (IIRC), the server would randomly append gibberish to the end of the file name, much in the manner you describe. But this was in the pre-xsan, FCP 4.1 days … so you’d /think/ that issues like this wouldn’t be around anymore, but you never know.

Matt Lyon
Editor
Toronto

[Jonathan Lakser]

Thanks for your responses guys. That last suggestion seems like it might be on the right track. Edit-Share is a linux based server so the fact that an issue very similar to this has existed on a linux based san leads me to think we are headed in the right direction.

Edit-Share has a great Tech Support, and they are very helpful. However I was unsure if this was a storage issue or just a general Final Cut Pro issue.

i am going to suggest they keep there file names under 32 characters and see if we can avoid any issues in the future… thanks for the help and any more suggestions are appreciated.

[Matt Lyon]

Cool Jonathan, glad to help. I would also suggest restricting the characters you use in filenames to UNIX/LINUX/DOS friendly ones: No slashes, no spaces (use underscores instead), no question marks, etc. It’s one less thing that can trip up the system.

Matt Lyon
Editor
Toronto

[David Bogie]

32 characters? Sheesh, I’ve never used more than about 20 in a filename. Mostly because the practice makes the name easier to read quickly in a directory. I rely on the metadata and comment fields for shot description.

bogiesan

[Mark Spano]

I have a guess. The way you connect to EditShare should be either AFP or DaveSMB. If you are connecting one way and creating media and then you connect another way, the filenames will show up all funky. All users should connect with the same protocol – admins can disallow AFP if DaveSMB is to be used and vice versa. You shouldn’t (theoretically) have filename issues once that “rule” is in effect. As a start, try disconnecting your shares and connecting them again using another protocol. You may find the one that works might display filenames correctly…

[Jonathan Lakser]

we are using Dave SMB to connect to the editshare. During the time when media was ingested on to the edit share they were mos certainly connected via Dave smb.

this however is a good line of thought and i will most certainly check it out to be sure.

[Jonathan Lakser]

i have just revived an email from edit share report regarding this issue as i have pointed them to this thread. here is what they wrote:

I have done some checking here. This doesn’t seem to be an issue with a
32-character filename limit. I am able to create files with
40-character names on EditShare Media Spaces and not have any issue. In
fact, 44-characters including a “.mov” at the end. I didn’t try longer.

What could be an issue is the total number of characters in the PATH.
That is, the combination of “Media Space Name” + “Capture Scratch” +
“Project Name” + “File Name”. In fact, you probably have to add the “IP
Address” to that as well, i.e.,

\\192.168.1.3\Media Space Name_1\Capture Scratch\Project Name\File Name

I think if the total exceeds 255 characters (the limit for POSIX and
Windows filesystems) you can get into some trouble. When you first WRITE
the file, Samba and OS X might be able to agree on what spot on the
storage system you are pointing to. But then you might get some weird
filename truncation later after disconnecting and re-connecting.

However, that all said… in your case, it looks as if you have
something like:

\\192.168.1.3\UTW201G_1\Capture
Scratch\U2W_201_0916\U2W201_p49_clip08_sit down interview

That’s only 89 characters (I don’t know your IP Address), so I don’t
think the 255 character limit for PATH is coming into play here.

Question: Can you reproduce this problem reliably? If so, can you tell
us how you reproduce it? If you can, then we can up the level of Samba
logging to see what’s actually going on.

I don’t know if THIS is relevant — a post about QuickTime failing to
deal with filenames > 60 characters:

https://lists.apple.com/archives/QuickTime-API/2006/May/msg00113.html

i will update when i have more information on what this means for the issue we are experencing but figured I would throw this up here.