-
Notifications
You must be signed in to change notification settings - Fork 215
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[FEATURE] Add option to customize FOLDER_SEARCH_*TIMEOUT, FOLDER_SEARCH_DOUBLE_CHECK_INTERVAL #682
Comments
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 #639 and #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. |
Thanks for your quick reply!
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.
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
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. |
Okay, as you have a use case I have added the following config options to Syncplay (which you can change by modifying syncplay.ini):
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 |
Seems to be working fine. Tyvm Et0h! |
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.The text was updated successfully, but these errors were encountered: