search

Syncplay / syncplay

Client/server to synchronize media playback on mpv/VLC/MPC-HC/MPC-BE on many computers
http://syncplay.pl/
Apache License 2.0
2.1k stars 214 forks source link

Increase FOLDER_SEARCH_TIMEOUT again #130

Closed Ghosthree3 closed 7 years ago

Ghosthree3 commented 7 years ago

I know that this was recently increased (which helped a lot) but is there any reason it can't be increased further? It seems to be 6 seconds now which works for me most of the time, but about 10% of the time I still get the folder-search-timeout-error. Is there some limitation that means it can't be even 60 seconds? I understand the 15s FOLDER_SEARCH_FIRST_FILE_TIMEOUT but not FOLDER_SEARCH_TIMEOUT being so low.

FYI I'm using a samba mount with 4852 files in it currently as my media directory. I can only assume the fact it's a network mount is the reason sometimes it works and sometimes it doesn't. Generally if I reopen syncplay after it errors it'll work fine.

Et0h commented 7 years ago

If it gives an error then I think that you don't need to restart Syncplay to get it to work again, you just need to go File -> Set Media Directories, and press 'Okay'. That should reset the flag which told Syncplay to ignore the network drive, and things should work again. This could be made more clear in the notification.

Anyway, getting to your suggestion...

Current default options for the File Switch / Folder Search feature are:

Generally speaking it is recommended that users use local drives rather than network shares as their media directory, and avoid directories with way too many files in them. Values could be increased, but if the value for FOLDER_SEARCH_TIMEOUT is greater or equal to FOLDER_SEARCH_DOUBLE_CHECK_INTERVAL then it could result in situations where Syncplay is constantly updating the cache, and I'm guessing that this isn't a good thing.

One potential way that Syncplay could address this would be to update the cache less frequently in the event of things taking too long, and/or potentially changing how frequently it refreshes the cache depending on if there are any unfound files. The reasons this doesn't already happen is because (1) it would result in less consistency of behaviour, (2) it could encourage people using folders which are too big, and (3) it is more complicated and therefore harder to code and test.

It would be useful to hear from other users whether they experience any notifications during their usage of Syncplay and if so when, or if they use shared playlists without any problems.

Ghosthree3 commented 7 years ago

Ah ok, I understand the issue regarding the way FOLDER_SEARCH_TIMEOUT and FOLDER_SEARCH_DOUBLE_CHECK_INTERVAL work together.

In that case may I suggest upping the FOLDER_SEARCH_DOUBLE_CHECK_INTERVAL to 120s or even 300s and adding a button to the UI allowing the user to force an update in the case where they've just put something in and want it now?

Alternatively allow the user to set both values in misc and cap FOLDER_SEARCH_TIMEOUT to be at most 20% of whatever they set FOLDER_SEARCH_DOUBLE_CHECK_INTERVAL to and keep their defaults as they are now. Personally I don't care how big the update interval is because it's no skin off my teeth to take 5s to reopen syncplay, it doesn't really take that long to reload. I just want it to actually load in the first place.

Unfortunately it is impossible for me personally to use local drives as there is simply too much content to store it in a normal machine and I sort of want it in a NAS anyway for others. I understand I may be fringe though.

Is there some other reason that folders which are 'too big' is a problem? Because I don't understand, "it could encourage people using folders which are too big".

I've not yet experienced any issue with shared playlists but I haven't used them extensively either.

Et0h commented 7 years ago

Simply increasing FOLDER_SEARCH_DOUBLE_CHECK_INTERVAL too much is bad for the user experience, as it means if you download a file that you don't have it will still be marked as 'not found'.

Folders being too big is a problem because (1) it is probably not always good for the hard drive for Syncplay to be constantly looking for files 100% of the time (especially when this is the same drive you are also currently getting the media itself from), and (2) it means that when there is a file you want it might take Syncplay too long to find it or it could result in unreliable playback due to the IO being too busy.

I would rather not have to add even more UI options, as it clutters the interface which is bad for usability.

For now I'm happy to increase the tresholds a bit, but any more would ideally want a re-think of the implementation.

Ghosthree3 commented 7 years ago

Well as I have no small amount of files and was frequently fitting into the 6 second window I would say that your commit changing it to 20 seconds will probably stop this issue being heard from again for a long time, if ever. Unless the user has some other IO issue.

Et0h commented 7 years ago

Okay, hope it works then. Let me know if there are any problems in the future, and for now I'll consider this issue closed.