Closed Varming73 closed 7 months ago
Many of us have this issue specifically and ig yow's on it
The issue was closed as solved this morning, so I hope it will be resolved this time instead.
@Varming73 workaround until i send the fix: disable repair
Tried resolving this on v0.9.3-hotfix.4
please check
Unfortunately after a while zurg latest running, the RD updates not reflected in zurg
@drahmed86 when logging at the log: What should have happend? It's difficult to know what to look for when it isn't there.
Secondly: Be aware then you share the log that if somebody copy/paste the RD URLs it will be seen as somebody using your RD from a different IP, which can make RD close your account.
@yowmamasita I just took a look at my own setup and can confirm that in my setup Zurg doesn't refresh after a while either. With log level DEBUG nothing is shown that can explain why. In my config.yml I have this:
concurrent_workers: 32
check_for_changes_every_secs: 15
api_timeout_secs: 60
retries_until_failed: 5
rate_limit_sleep_secs: 6
download_timeout_secs: 2
I tried the Reboot Refresh Worker but that doesn't work in hotfix4, a new browser tab gets opened but no page is ever shown. It didn't reboot the workers either so it doesn't do anything atm. I then restarted the container and upon reload everything was there.
So the issue is still not resolved - and in DEBUG nothing in the logs even explain what has happend. Will it help you if I put log level ALL or haven't logging been implemented that will give you anything of use?
@drahmed86 when logging at the log: What should have happend? It's difficult to know what to look for when it isn't there.
Secondly: Be aware then you share the log that if somebody copy/paste the RD URLs it will be seen as somebody using your RD from a different IP, which can make RD close your account.
yea thanks
Please check v0.9.3-hotfix.5
Saw it in the repo and installed right away, thnx
It still doesn't work. The container had been running for about 58 min. I added the file via RDP. I can see the file in DMM but Zurg doesn't see that file/or refresh to get it. I rebootet the refresh worker which did open the browser tab with the correct text and I saw this in the log:
2024-01-30T18:03:08.823Z INFO router Rebooted refresh worker
2024-01-30T18:03:08.823Z INFO manager Starting periodic refresh job
2024-01-30T18:03:08.823Z INFO manager Stopping periodic refresh job
I then restarted the container and the file was finally also in Zurg.
Stupid question: In 0.9.2hotfix4 the refresh function worked perfectly and "only" the repair function had to be fixed. Isn't it possible to reuse the refresh function that worked earlier along with the new repair function?
Stupid question #2: Is it possible to run both 0.9.2hotfix4 AND 0.9.3hotfix5 in separate containers at the same time? Then I could have .3hf5 repair things and .2hf4 refresh. Far from optimal but at least I would have a functional setup.
Latest HF5 works like a treat no need for all that dilemma ya mention
Happy to hear it works for you but that doesn't really help me
Have ya tried to delete data folder and start from the scratch?!
Nope, I haven't heard that had to be done but am willing to try. Has been running hotfix5 since release and the refresh doesn't work here. Will try to delete if that's recommended.
Yep give it a shot and stick to the defaults
Confirmed still NOT working. Deleted my Zurg data and fired up hotfix5 again. Several files have been in RD for 4 minutes now and all I see in the log is:
2024-01-31T10:04:23.275Z DEBUG realdebrid Got info for torrent KY7JSNYSOAVC4 (progress=0%)
2024-01-31T10:04:23.275Z DEBUG manager Saved torrent KY7JSNYSOAVC4 to file
2024-01-31T10:04:23.275Z DEBUG realdebrid Got info for torrent YHNWXBLXC6DCA (progress=0%)
2024-01-31T10:04:23.276Z DEBUG manager Saved torrent YHNWXBLXC6DCA to file
2024-01-31T10:04:23.280Z DEBUG realdebrid Got info for torrent YQIDTUQ5UT3ES (progress=0%)
2024-01-31T10:04:23.280Z DEBUG manager Saved torrent YQIDTUQ5UT3ES to file
2024-01-31T10:04:23.284Z DEBUG realdebrid Got info for torrent 76DSJJHRTGP6C (progress=0%)
2024-01-31T10:04:23.284Z DEBUG manager Saved torrent 76DSJJHRTGP6C to file
2024-01-31T10:04:23.284Z INFO manager Fetched info for 5568 torrents
2024-01-31T10:39:33.380Z INFO manager Periodic repair started; searching for broken torrents
2024-01-31T10:39:33.386Z INFO manager Found 0 broken torrents to repair in total
2024-01-31T10:39:33.386Z INFO manager Finished repairing 0 broken torrents
So Zurg still doesn't update - and been running less than an hour.
Can also confirm that 0.9.2hotfix4 still works perfect, just started that container up instead and it refreshes perfectly.
update:: yep ya're right i can see inconsistent refreshing work of zurg HF5 so disabling the repair feature as a workaround .. lets wait and see lol
Can you please try a new revision I sent few minutes ago? v0.9.3-hotfix.5
@Varming73
it should be fixed now on v0.9.3-hotfix.6
this is it
I've started testing hotfix6 now, will report any errors found related to this issue (fingers crossed)
Running hotfix7 it actually seems like you got the issue fixed. Will close tomorrow if everything is still smooth sailing.
Fyi this is already fixed. Please reopen if this is not the case.
Rescan is still super inconsistent on v0.9.3-final
. Couldn't get it to work at all, then tried disabling repair like mentioned earlier and now it's 2/5 for me
I just came home and several files were waiting in RDT. I check on the main RD site and the files were downloaded perfectly. In the Zurg logs no changes were logged so it seems like Zurg still don't pull updates after a while. After restarting the Zurg container everything waiting in RDT became finished as the files were now found in Zurg.
So something still doesn't update in Zurg. I guess I have to revert to 0.9.2hotfix4 again. Seems like an unstable solution to restart the container every 10 min or something.