[FEATURE] Add option to customize FOLDER_SEARCH_*TIMEOUT, FOLDER_SEARCH_DOUBLE_CHECK_INTERVAL

[t-nil]

Hi, I use rclone mount to mount a media server via FTP. Using syncplay in combination with media server is really useful to me, since people don't need to download the videos prior to watching. Unfortunately listing all directories can take much longer than 20 secs. I admit it was pretty easy for me to modify the corresponding constants in constants.py. But I suppose other people could also run into this problem and a configuration option would be nice. If maintainers are opposed to that, I would opt to writing a short Wiki article / Doc section.

[Et0h]

Syncplay was simply not designed to support the FTP media directory use case.

At present Syncplay doesn't just scan once but it regularly scans to check for files being created or deleted.

While there might be some APIs that can notify Syncplay of an update to reduce that burden and allow for this behaviour to be changed, getting it to work reliably cross-platform would require a lot of development time and for one of the developers to actually regularly operate with that use case, and so far nobody has volunteered for this.

As such, the timeout is not just an arbitrary value, it is a way of raising a red flag if you are trying to select a folder that is not suitable for being specified as a media directory due to how Syncplay currently operates.

See https://github.com/Syncplay/syncplay/issues/639 and https://github.com/Syncplay/syncplay/issues/639 for further discussions relevant to the above issues.

For streaming, Syncplay allows for paths to be specified such as HTTP and HTTPS paths, and then it is up to the media player to access those files. At present the barrier to this working properly with the shared playlist feature is that FTP is not listed under TRUSTABLE_WEB_PROTOCOLS and so it won't auto-play even if you added the domain to your list. If you want FTP, SFTP and/or any other protocol added to that list then let me know and I will discuss it with other Syncplay developers. Generally when streaming a file from a server I find mpv works best, especially with Syncplay.

[t-nil]

Thanks for your quick reply!

If you want FTP, SFTP and/or any other protocol added to that list then let me know

Thanks, but this isn't necessary for me. I am quite happy with my "rclone mount -> syncplay" workflow. I just wanted to mention that, for me and possibly some other users, the default timeouts simply do not work, and maybe even just a CLI flag would be warranted and productive. Otherwise I am fine with documenting that workaround somewhere.

At present Syncplay doesn't just scan once but it regularly scans to check for files being created or deleted. \ While there might be some APIs that can notify Syncplay of an update to reduce that burden and allow for this behaviour to be changed, getting it to work reliably cross-platform would require a lot of development time and for one of the developers to actually regularly operate with that use case, and so far nobody has volunteered for this. \ As such, the timeout is not just an arbitrary value, it is a way of raising a red flag if you are trying to select a folder that is not suitable for being specified as a media directory due to how Syncplay currently operates.

Unfortunately I'm not sure what you mean. Syncplay scanning repeatedly for changes, instead of listening (by e.g. inotifywait), is totally fine for mounted rclone backends. To the contrary, I think ,would syncplay rely on inotify, I would have problems using the media folders that way. So the only thing that would my use case a bit more comfortable would be configurable timeouts :) (I use that workflow regularly, and outside of long scanning times there is absolutely nothing going wrong in any way. Probably because rclone does a good job abstracting the backend)

To be clear: mounted Rclone backends look very much like local folders with high latency on some operations, or say like network mounts over a bad connection.

Still, if you decide to not support my idea, I can workaround fine and would only like to document somewhere what I found.

PS: You linked the same issue #639 two times, and I don't think that issue applies much. In fact, to quote you

Syncplay was never designed or intended to deal with SFTP as if it were a local drive, and relies on the OS and third party mount software to allow for this to work. \ In terms of mounts, Syncplay is designed to media directories regularly for new files. This might be an issue if you mount an external drive, but nobody has volunteered to improve Syncplay's behaviour in this regard as per https://github.com/Syncplay/syncplay/discussions/547 and so that will be the behaviour for the foreseeable future.

Using third party tools to mount is exactly what I'm doing, and AFAICT syncplay is working perfectly well if you increase the timout by enough.

[Et0h]

Okay, as you have a use case I have added the following config options to Syncplay (which you can change by modifying syncplay.ini):

• folderSearchFirstFileTimeout # Default: 25 Seconds - How long to wait to find the first file in folder search (to take account of HDD spin up)
• folderSearchTimeout # Default: 20 Seconds - How long to wait until searches in folder to update cache are aborted (after first file is found)
• folderSearchDoubleCheckInterval # Default: 30 Seconds - Frequency of updating cache

These three settings are now listed at https://syncplay.pl/guide/client/

Please test to ensure that changing the settings correctly changes the behaviour. You can download the builds at: https://github.com/Syncplay/syncplay/actions/runs/9245333500

[t-nil]

Seems to be working fine. Tyvm Et0h!