Filebot very slow

[cybman]

Hi,
when i click to load files it takes ages to show my directory list
and navigating between dirs is also very slow
it takes almost 20 seconds to respond

any ideia?

REgards

[rednoah]

Are we talking about a remote network share? Or a local disk? Feel free to elaborate and include as much information as you can think of, including screenshots.


Please read How to Request Help.

[CraigHBruce]

Jumping in here with the same issue/symptoms. I've just reinstalled FileBot from the Windows store (v4.9.1.0) and am finding (have for some time actually) certain actions very slow:
- Press Load. Takes ~15s for window to appear. Default (Documents) folder shown in window when it does appear is empty and everything is frozen for 3mins or so. I then choose to go up a directory level...another 15s or so. Choose another subdirectory 5-10s to load, same for another subdirectory off that. Once I choose a file/files to load they quickly show in Original Files section.
- Completing Rename. With multiple files to be renamed (6-10) the files themselves are moved almost immediately, but Filebot 'hangs' and takes forever to delete/clean any empty directories

While either of these hangs are happening, Windows Explorer also hangs but network traffic is minimal (kb/s)

PC is an i9-990K with 32GB and NVME M.2 SSDs (970 Evo Plus)
Documents, Downloads, Music, Photos and Video system folders are all mapped to network drives running on a Synology Diskstation running RAID 10. Gigabit network connection - disk operations between PC and NAS benchmarked at 30MB/sec write and 120MB/sec read.

Filebot configured to Read from //diskstation/Video/To File and to then write renamed files to //diskstation/Video/Movies or TV

I suspect there may be an issue due to the large number of files/directories in the mapped drives. The NAS is configured with a single 14.4TB volume and each mapped drive is simply a folder within that volume - each mapped drive shows, for example, as 1.53TB free of 14.4TB. Within this, for example, my Movies folder contains 1279 folders taking up 753GB of space.

Of course, it may be something elsewhere in my config....but only seems to occur when using Filebot (same issue seen on my laptop which is configured in the same way - my home machines are on a domain and folders are mapped via group policy).

[rednoah]

You have an extremely unusual setup. The user home is expected to be a local file system that is instantly accessible. If you throw in a remote folder, backed by a spinning hard disk, then you are increasing file system latency 1000x or more for all basic file system operation.


Bandwidth doesn't matter. Latency does. Consecutive read/write speed is meaningless you're waiting 5 ms instead of 0 ms for basic file attributes, every single time. That's a hard multiplier.


Note that it isn't FileBot specifically, but underlying runtime and libraries, including Windows API, that probably aren't well-tested with and optimized for high-latency user home folders.


You'll want to ask for optimization advice in Windows and Synology NAS forums. I'm no expert on the SMB protocol, but perhaps there's some advanced caching options that can be enabled. The number of files on your remote network share is unlikely to be the bottle neck, because your local PC don't know don't care.


You may prefer Drag-n-Drop from Windows Explorer instead of the default File Dialog, if the default File Dialog doesn't work well in your environment.

[CraigHBruce]

Thanks for the reply - reckon you're likely correct in the diagnosis. May be time to repartition the NAS into different volumes

[CraigHBruce]

An update after a lot more testing on my NAS setup with iperf3 and NAS Tester 1.7.....posted here for anyone facing similar issues.

When mapping a drive to a network share there's a significant performance difference in using the IP address (avoiding a DNS lookup) rather than hostname. In my case I had V: mapped to //diskstation/Videos and when changing it to //192.168.1.100/Videos the write performance in particular across my network was *massively* improved...fixing the issues I'd been seeing when using Filebot