FFAStrans forum

Hi steinar, emcodem

Alot of them were from that YouTube downloader workflow (editorial loves selecting from YouTube) and sometimes had emojis in their name, but they've been picked up correctly after using the symbolic link workaround. There are other files that got stuck in Wetransfer Auto Upload, in any of the DNX Encoding/Dispatcher workflows and both of the MP4 workflows. Files in those monitored folders usually have sane names but they never got picked up aswell.

@emcodem:
Yes, I can get they're a bit messy. I'll create a new FFAStrans instance with only a single watchfolder and send over those logs. Will get back with those soon.

Hello, in my workflow the links to YouTube videos with a "pretty name" with more than 60 characters do not work when you drag
the shortcut to a folder monitor, it shows "Incoming" but the workflow does not start. It doesn't matter if they have emojis or not. Workaround rename the shortcut.

Attached a new DB folder. This one contains only 1 workflow with a watchfolder.
I noticed that there are no incoming jobs in the webinterface now (although a restart might fix that I realise), but the jobs still don't get started.
This FFAStrans instance was started via UNC, not via the symbolic link. As soon as I restarted via the link, it picked the files up. Directly submitting jobs when launched from UNC works.

I did see in the logs what you mentioned earlier, jobs are created but closed after a few seconds.

The testfiles were MXF files, DNxHD HQx video, PCM 24bit 48KHz audio, with following names:
DTRO_S04_A1_Archiefmaster.sub.mxf
DTRO_S04_A5_Archiefmaster.sub.bmp.mxf

These don't look out of the ordinary, or extremely long, so I don't think that is the issue?

Thats really cool but there is one info missing:
whats the full unc path behing y:\ for you? (PM it to us if you prefer)
Thank you so much!

Edit: my post #1000, yeeey

PM'd you the UNC path.

Congrats on the posts

Hi Stef, we really appreciate your help

It seems we have found the cause of the issue and it's really quite stupid. I should have though of that long ago. Anyway, we believe the reason for the misbehavior is that the path of the FFAStrans installation is too long. This would explain why it works when you map it to a shorter drive. Also, it would explain why it works when submitting but not from monitor. You see, the monitor creates some very long paths (but not THAT long) in the FFAStrans installation location which in sum makes them very long. This was not foreseen as normal installation path is usually shorter.
Anyway, it would be nice if you could confirm the theory by going back to UNC path but a much shorter one. Just one short level from the main share or something like that.

Thanks again for your help!

-steinar

Thanks for the tip. I'll check after the weekend if a shorted path solves the issue.

A later response than expected, but moving the FFAStrans folder to the root of the share does solve the issue. Thanks for the help!