ken-ji
-
Content Count
1215 -
Joined
-
Last visited
-
Days Won
4
3 Followers
-
I can't replicate it so maybe you have filenames with non-latin characters? the dropbox.py in this container still runs on python 2.7 which is known to have some issues with string encoding But I think that shouldn't cause any issue as the dropbox.py script is for interacting with with the headless client.
-
@editedweb I've built a new image with the latest client (though my account auto updates the client to the latest beta) and I've had it running for a while without any noticeable issues. I have not seen the error message about Rust panic though.
-
Its probably related to the current state of the official dropbox headless client I'm building a new version of the package and having the client update to the latest to see what's going on.
-
Spending a little time reveals that the bash script is doing exactly the same thing as the WebUI the webUI triggers this event toggle_state(up) which is a function that invokes this since it has no other parameters filled out $.post('/webGui/include/ToggleState.php',{device:device,name:name,action:action,state:'STARTED',csrf:'REDACTED'},function(){resumeEvents(event,500);if (button) $(button).prop('disabled',false);}); which then invokes a curl to http://127.0.0.1/update function emhttpd($cmd) { global $state, $csrf; $ch = curl_init("http://127.0.0.1/update"); $option
-
I understand your point, but to provide a counterpoint. those people are running their server dangerously since you should never spec a system with such marginal power capacity - even if your Bios says drive spin up is staggered. That said, my script spinning everything up at once might be why its giving me issues with performance during parity tests... I'll look into this and add a bash snippet when I've figured this out.
-
come to think of it... the bash code is based on the php script earlier in the discussion. maybe its not quite the same for current Unraid versions...
-
The bash code does exactly what clicking on the webui button does. the parameters are all taken from that. Its been the same as far as i can tell.
-
Issue: Mover keeps moving files from cache to disk1 (the one with the least amount of space) even if manually copying files from cache -> user0 locates it disk5 (the one with the most amount of disk space) So I have the this structure /mnt/user/Media/Anime/... spnning all the disks with the share config above I tried to manually simulate the mover (by reading the mover script and executing the move command with debug level 2 find /mnt/cache/Media/Anime -depth | move -d 2 the logs weren't helpful Jul 9 22:09:15 MediaStore move: debug: move: exclude ffff
-
So I broke down the mover script and determined the following command for my dir structure /mnt/cache/Media/Anime/I/Inuyasha Kanketsuhen/*.mkv mover would construct the follwing command find /mnt/cache/Media/Anime -depth | move I manually ran this command for more debugging find /mnt/cache/Media/Anime -depth | move -d 2 but only got the following lines in the log Jul 9 22:09:15 MediaStore move: debug: move: exclude ffffffffffffffff Jul 9 22:09:15 MediaStore move: debug: move: real_path: /mnt/cache/Media/Anime/I/Inuyasha Kanketsuhen/[Raizel] Inuyasha Kanketsuhen - E
-
Pretty sure the share config is okay since I've tested changing the min free space, which should have caused the config to be rewritten. Weekend's coming up so I can probably do a few more tests
-
Hmm. I haven't observed it with any other shares as this is the most used one (and its the only share on Disk1 right now)
-
Can anyone take a look - Its really getting annoying - my only work around now is to either exclude Disk1 or manually migrate stuff off Disk1
-
You can probably run root@MediaStore:~# docker network inspect br1 [ { "Name": "br1", "Id": "dd6c416d2efd0344bfd6f0bb0c3336dbd9e9f0ca3063f5afd599e083fb334f79", "Created": "2021-05-20T08:02:01.315812887+08:00", "Scope": "local", "Driver": "macvlan", "EnableIPv6": false, "IPAM": { "Driver": "default", "Options": {}, "Config": [ { "Subnet": "192.168.2.0/24", "IPRange": "192.168.2.128/27", "Gateway": "192.168.2.1" -
Anybody?
-
Hi I've been having a weird issue lately, it seems when mover runs it insists on sticking all my files to disk1 even with the following share settings only yesterday I invoked mover and it decided to stuff about 32G worth of files into disk1 when the high water allocation should move them to disk5 But moving files from my cache disk to user0 manually using mc or mv command moves the files correctly. Any ideas where I've got it configured wrong? mediastore-diagnostics-20210703-0643.zip