A great feature would be to disable notifications when something changes in a particular folder. Our google drive has a folder for each department, and I’d like to see when something changes for my specific department (folder) but I do not care if something changes in another department. I still need access to those department folders though. I’m currently getting notifications for every file change which is quite frequent.
Thanks,
Matt
That pretty neat! 
I’ll take note of this request and bring it up with our team. Thank you, Matt!
I’m in desperate need of this feature. A cloud folder shared with me has tens of thousands of updates. I don’t sync it locally as it’s far too big, but I am getting flooded with change notifications.
@gbolcer I understand that it can be quite bothersome to keep seeing these. One option could be to temporarily disable the pop-up notifications on the app-- you can still see the changes on the Feed tab. Would this work with you for the meantime?
Unfortunately, it’s not “bothersome” it’s extremely disruptive.
I still need notification changes from all the other “shared with me” files. Just not that ONE massive folder. I can’t keep checking the feed, which gets diluted from all the changes from that one folder anyways, just to get work notifications for the other important shared changes.
The other issue is that on linux, the 2.2.4.40916 client keeps crashing out so it never finishes the updates. I have to keep insync quit; insync start; insync show just to get a little further.
I see, and I can now further understand why it’s disruptive, @gbolcer. I’ll bring this up with our engineers.
As for the crashing, is this happening while you are trying to sync changes to large files and/or multiple different files?
Thank you. It looks like the linux client is all caught up after a couple of restarts. I did have a problem with a difficult file on an earlier 3.x insync client release, so it looks like it wasn’t actually synching until I upgraded the client recently. There are a few errors in the log, some from Sept, some from now.
INFO 2020-12-30 09:49:52,907 [syncwork:_is_stale_dl_sub:2733] #649: checking dl_sub file .~70b2cae98de7a524b163fcc379ac8f00925b12.insyncdl for staleness.
INFO 2020-12-30 09:49:53,264 [syncwork:_is_stale_dl_sub:2733] #649: checking dl_sub file .~ce27659e0fc2b7ed2a64c127849380a477099b.insyncdl for staleness.
INFO 2020-12-30 09:49:53,739 [syncwork:_is_stale_dl_sub:2733] #649: checking dl_sub file .~master.insyncdl for staleness.
INFO 2020-12-30 09:49:53,814 [syncwork:_is_stale_dl_sub:2733] #649: checking dl_sub file .~HEAD.insyncdl for staleness.
INFO 2020-12-30 09:49:53,852 [syncwork:_is_stale_dl_sub:2733] #649: checking dl_sub file .~880d59c66263bd52fd4383a29f3e12042381dc.insyncdl for staleness.
INFO 2020-12-30 09:49:54,375 [syncwork:_is_stale_dl_sub:2733] #649: checking dl_sub file .~2ba2c97677637c775dd41adf0ea63fc717ceb8.insyncdl for staleness.
INFO 2020-12-30 09:49:54,494 [syncwork:_is_stale_dl_sub:2733] #649: checking dl_sub file .~2e633784b7bd2fc6e14714adad70988e8e24c6.insyncdl for staleness.
INFO 2020-12-30 09:49:54,576 [syncwork:_is_stale_dl_sub:2733] #649: checking dl_sub file .~0b5f39318de630a94e9a5c7fa9e4cb6c0ecd6a.insyncdl for staleness.
INFO 2020-12-30 09:49:54,807 [syncwork:_is_stale_dl_sub:2733] #649: checking dl_sub file .~f9ba2ff380e0c0e40487b5b88f3708bc4b0800.insyncdl for staleness.
INFO 2020-12-30 09:49:55,084 [syncwork:_is_stale_dl_sub:2733] #649: checking dl_sub file .~HEAD.insyncdl for staleness.
js: ResizeObserver loop limit exceeded
js: ResizeObserver loop limit exceeded
js: ResizeObserver loop limit exceeded
js: ResizeObserver loop limit exceeded
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to ‘/tmp/runtime-greg’
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to ‘/tmp/runtime-greg’
QXcbIntegration: Cannot create platform OpenGL context, neither GLX nor EGL are enabled
INFO 2020-09-14 14:30:56,008 [mainlogs:_log_run:122] Core(app_version=3.2.6.40863, platform=Linux-x86_64-ubuntu/20.04) initialized
WARNING 2020-09-14 14:30:56,024 [base_events:_run_once:1771] Executing <Task pending coro=<init() running at ideskcore/core.py:146> wait_for=<Task pending coro=<SettingsMain._load_settings() running at ideskcore/mainsettings.py:169> cb=[_log_tb_after_delay() at ideskasync/coreloop.py:303, <TaskWakeupMethWrapper object at 0x7f0e08a8af78>()] created at ideskcore/mainsettings.py:147> cb=[_log_tb_after_delay() at ideskasync/coreloop.py:303, _chain_future.._call_set_state() at asyncio/futures.py:355] created at asyncio/events.py:88> took 0.176 seconds
INFO 2020-09-14 14:31:01,120 [fswatcher:_start:57] LinuxFSWatcher._start
INFO 2020-09-14 14:31:01,121 [inotify_manager:_pull_loop:312] Inotify loop enter
WebEngineContext used before QtWebEngine::initialize() or OpenGL context creation failed.
INFO 2020-09-14 14:31:01,265 [fswatcher:watch:77] watch origin: /hbase/Insync
INFO 2020-09-14 14:31:01,271 [main:start_core:49] core started
INFO 2020-09-14 14:31:01,275 [unix_socket_server:start:57] unix socket server thread start
INFO 2020-09-14 14:31:50,129 [syncwork:_refresh_local:2513] Permanently deleting the stale sub file during refresh: /hbase/Insync/News/.~12OQjIqY1L4XOrHj9atW3T8Ql7tbB_tFY-2f1f68.insyncdl
INFO 2020-09-14 14:31:50,130 [fs:delete_reg:247] Permanently deleting: /hbase/Insync/News/.~12OQjIqY1L4XOrHj9atW3T8Ql7tbB_tFY-2f1f68.insyncdl
INFO 2020-09-14 14:32:03,261 [syncwork:_refresh_local:2513] Permanently deleting the stale sub file during refresh: /hbase/Insync/News/.~1tCP7i5zZtYKNU98qw9GYXgI8Gq8Mpzph-39aa66.insyncdl
INFO 2020-09-14 14:32:03,261 [fs:delete_reg:247] Permanently deleting: /hbase/Insync/News/.~1tCP7i5zZtYKNU98qw9GYXgI8Gq8Mpzph-39aa66.insyncdl
ERROR 2020-09-14 14:32:18,561 [workbase:__run:258] While running HandleCloudUpdates()
@gbolcer Looks like there are limit errors here. Do you mind emailing the logs.db and out.txt files to support@insynchq.com with the link to this post so we can take a look? Please also include the name of the difficult file for reference. Thank you!
I sen the logs. NO idea what file it was. From a previous support request, I know there was an issue on the windows client that did the same until I removed it. The linux client was behind by two months in synching due to the crashes, so I just assumed it was due a similar issue. Hopefully you can figure out what it was doing from the logs.