[errno 98] Address already in use

[slhx99]

Hi,

I'm facing an issue where I can't get Wine started at all. I have no idea what I should be doing to get around this. I've tried recreating the image and container but to no avail.

Originally posted by @slhx99 in https://github.com/Banh-Canh/docker-FMD2/issues/11#issuecomment-1773667495

[abwezi]

I am experiencing this same issue. Initially caused by updating FMD2 in a working container. Recreated the container image and container also, but behavior is still the same. @Banh-Canh Please consider looking into this and fixing or rehosting an older version if you may have it archived because I really like this tool. There seems to be nothing else to easily automate only downloading the newest chapters of a manga from instead of the entire thing.

[Nitrousoxide]

I got this working again in my repo, though I'm having permissions issues with the userdata, module, and data directories. I may look into it further, but you can use my repo to build a working version and run it using this command:

https://github.com/Nitrousoxide/docker-FMD2 docker run --rm -it -p 3000:3000 docker.io/library/fmd2-docker:latest bash

(adjust the image to whatever you chose when you built it locally obviously)

Though note, with no volumes mounted any downloads won't survive a container reboot.

Please feel free to look into this more and see if you can fix the rest of the issues with the volume mount issues. Not sure if I'm going to put more work into this.

[abwezi]

@Nitrousoxide Thank you. Unfortunately this doesn't seem to be working correctly for it maybe due to the folder permissions that you mention. I have tried declining to update modules on launch or accepting and applying when they say they have finished downloading but either way when I hit apply nothing happens, when I restart the container the modules are all errored out, and no websites populate to search from

[Nitrousoxide]

@abwezi it's possible my version might also need to implement the chown script that this one does https://github.com/Banh-Canh/docker-FMD2/blob/master/root/etc/cont-init.d/30-config

Or, it's possible that the config files might need to be moved into the mounted directories after the container is spun up, if they are empty. I suspect some of the issue might be due to when userdata and other directories are added as volume mounts they override the versions installed in the container, leaving it with missing app files since the user's host directories will start out empty initially.

[abwezi]

@Nitrousoxide permissions is definitely the problem. I got it running with the current latest from this repo. Quoted reply from other issue below

Installed the latest from the docker compose. I added a line to mount my existing media folder on my host drive.

After it installed and ran the container I went into docker terminal and ran chmod ugo+rwx /app/FMD2/fmd.exe

Update: I also had to run chmod -R ugo+rw-- *path to my mounted manga folder* to get downloads to stop failing due to permissions as well

[Nitrousoxide]

@Nitrousoxide permissions is definitely the problem. I got it running with the current latest from this repo. Quoted reply from other issue below

Installed the latest from the docker compose. I added a line to mount my existing media folder on my host drive. After it installed and ran the container I went into docker terminal and ran chmod ugo+rwx /app/FMD2/fmd.exe Update: I also had to run chmod -R ugo+rw-- *path to my mounted manga folder* to get downloads to stop failing due to permissions as well

Okay, good fix. I blew my repo out and recloned it and added those fixes to the startup script. I also added a compose file which will build from the git repo context so someone can clone the repo and docker compose up to build a local image even the one on dockerhub or whatever is busted. I also opened a PR here to push the fixes, but someone can use my repo for now to get a working compose file.

https://github.com/Nitrousoxide/docker-FMD2

[Banh-Canh]

I'll try to take a look this weekend. I'm deploying it on kubernetes without issues but I think I can see why it can happen.

[Banh-Canh]

Can you guys try banhcanh/docker-fmd2:kasm-v2 ? it's cleaned up, should be much better, even though the image might be heavier.

I don't have a ci pipeline for this project so the versioning and all is manual sorry about that.

[Nitrousoxide]

Can you guys try banhcanh/docker-fmd2:kasm-v2 ? it's cleaned up, should be much better, even though the image might be heavier.

I don't have a ci pipeline for this project so the versioning and all is manual sorry about that.

I'm getting permissions issues with the download folder.

I see your dockerfile should be chowning it to abc:abc so I don't know why this is

Brian@openmediavault:~/DockerAppData/compose-files/docker-FMD2$ docker exec -it --user abc fmd2 bash
To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.

abc@a5f976e4ef23:/$ ls -asl
total 160
 4 drwxr-xr-x   1 root root   4096 Jan 13 21:18 .
 4 drwxr-xr-x   1 root root   4096 Jan 13 21:18 ..
 8 drwxr-xr-x   1 abc  users  4096 Jan 13 17:58 app
 0 lrwxrwxrwx   1 root root      7 Jan  9 18:33 bin -> usr/bin
 4 drwxr-xr-x   2 root root   4096 Apr 18  2022 boot
12 drwxr-xr-x   2 root root  12288 Jan  9 18:33 command
 4 drwxr-xr-x   9 abc  users  4096 Jan 13 21:18 config
 4 drwxr-xr-x   2 root root   4096 Jan 13 17:53 custom-cont-init.d
 4 drwx------   1 abc  users  4096 Jan 13 21:18 defaults
 0 drwxr-xr-x   5 root root    340 Jan 13 21:18 dev
 0 -rwxr-xr-x   1 root root      0 Jan 13 21:18 .dockerenv
24 -rwxr--r--   1 root root  22451 Dec 31  1969 docker-mods
 4 drwxr-xr-x   2  911  1000  4096 Jan 13 17:58 downloads
 8 drwxr-xr-x   1 root root   4096 Jan 13 21:18 etc

I tried deploying the container with the downloads directory volume mount commented out to rule out host permissions issues and it still had that issue.

the tweaks I made to the compose file

version: "3"
services:
  fmd2:
    #build: ./
    image: banhcanh/docker-fmd2:kasm-v2
    container_name: fmd2
    environment:
      - PUID=1000
      - PGID=100
      - TZ=America/New_York
      - UMASK=022 #optional
    ports:
      - 3000:3000
    volumes:
      - $HOME/DockerAppData/FMD2/userdata:/app/FMD2/userdata
      - $HOME/DockerAppData/FMD2/modules:/app/FMD2/lua
      - $HOME/DockerAppData/FMD2/data:/app/FMD2/data
      - $HOME/DockerAppData/wine/data:/config/.wine
#      - /srv/remotemount/Media/Media/Manga:/downloads

Manually jumping into the container to chown /downloads let me write to it as abc (as expected) but even after that the app will still give the same "cannot create directory" error so maybe it's running as a different user than abc?

Brian@openmediavault:~/DockerAppData/compose-files/docker-FMD2$ docker exec -it --user abc fmd2 bash
To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.

abc@a5f976e4ef23:/$ cd /downloads/
abc@a5f976e4ef23:/downloads$ ls
abc@a5f976e4ef23:/downloads$ touch test
touch: cannot touch 'test': Permission denied
abc@a5f976e4ef23:/downloads$ exit
exit
Brian@openmediavault:~/DockerAppData/compose-files/docker-FMD2$ docker exec -it fmd2 bash
root@a5f976e4ef23:/# chown abc:abc /downloads/
root@a5f976e4ef23:/# exit
exit
Brian@openmediavault:~/DockerAppData/compose-files/docker-FMD2$ docker exec -it --user abc fmd2 bash
To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.

abc@a5f976e4ef23:/$ cd downloads/
abc@a5f976e4ef23:/downloads$ touch test
abc@a5f976e4ef23:/downloads$ ls
test
abc@a5f976e4ef23:/downloads$ 

Edit: Just to make sure I wasn't crazy I went back to the build on my fork (which was made before the refactor to kasm), and it was able to download successfully.

Double edit: I'm also not doing something weird like having fmd2 download to somewhere other than /downloads.

[Banh-Canh]

ok, it seems like it's an issue with Wine 6.0 and later. I need to dive in a bit.

[Banh-Canh]

Hey I'm pushing banhcanh/docker-fmd2:kasm-v3, had to write a workaround for this regression in wine6+.

It's not perfect, I can't persist all data (meaning, fmd2 configuration when you click on the webui) but it should work for most cases. Modules are preloaded on container start.

significant changes in how bind mount are made so you better look or just trash out your old datas (shouldn't be too important since fmd2 is all about download and that's it).

On container restart, some hot configuration might disappear, but most configuration (website conf and modules should be fine).

Going on wine8, it's at least prettier.. couldn't revert to wine5 because it has some ui issue on kasm and I don't think i want to maintain the old image (using noVNC, and using the old wine5). If this version has unsolvable problems i might consider going back to maintain the trash old one (and actually fix the old permission issue).

[Nitrousoxide]

still seem to be getting permissions issues with downloads if I mount the directory to my real downloads folder

Jumping into the container as user abc I can see and touch a test file in the download directory

Brian@openmediavault:~/DockerAppData/compose-files/docker-FMD2$ docker exec -it --user abc fmd2 bash
abc@c32464399018:/$ ls
app  boot     config          defaults  docker-mods  etc   init  kasminit  lib    lib64   lsiopy  mnt  package  root  sbin       srv  tmp  var
bin  command  custom-cont-init.d  dev       downloads    home  kasmbins  kclient   lib32  libx32  media   opt  proc run   settings.json  sys  usr
abc@c32464399018:/$ cd downloads/
abc@c32464399018:/downloads$ ls
'12 Fairy!'                                                        'Isekai Bishōjo Juniku Ojisan to'
'3x3 Eyes'                                                         'Isekai Ojisan'
'Adachi to Shimamura'                                                      'Jahy-sama wa Kujikenai!'
'Ah! My Goddess'                                                       'Kimi wa Houkago Insomnia'
'Bocchi the Rock!'                                                      Otoyomegatari
 Helck                                                             'Tensei Shitara Slime Datta Ken'
'Heterogeneous Linguistics'                                                'That Time I Got Reincarnated as a Slime (Digital) (danke-Empire)'
'Houseki no Kuni'                                                      'The Owl House - Comics by Moring Mark'
"I'll Become a Villainess That Will Go Down in History The More Villainous I Become, the More the Prince Dotes on Me"
abc@c32464399018:/downloads$ touch test
abc@c32464399018:/downloads$ ls
'12 Fairy!'                                                        'Isekai Bishōjo Juniku Ojisan to'
'3x3 Eyes'                                                         'Isekai Ojisan'
'Adachi to Shimamura'                                                      'Jahy-sama wa Kujikenai!'
'Ah! My Goddess'                                                       'Kimi wa Houkago Insomnia'
'Bocchi the Rock!'                                                      Otoyomegatari
 Helck                                                             'Tensei Shitara Slime Datta Ken'
'Heterogeneous Linguistics'                                                 test
'Houseki no Kuni'                                                      'That Time I Got Reincarnated as a Slime (Digital) (danke-Empire)'
"I'll Become a Villainess That Will Go Down in History The More Villainous I Become, the More the Prince Dotes on Me"  'The Owl House - Comics by Moring Mark'
abc@c32464399018:/downloads$ ls -asl
total 24
 0 drwxr-xr-x 2 abc  1000     0 Jan 14 09:41  .
 4 drwxr-xr-x 1 root root  4096 Jan 14 09:40  ..
 0 drwxr-xr-x 2 abc  1000     0 Jan 13 21:35 '12 Fairy!'
 0 drwxr-xr-x 2 abc  1000     0 Jan 13 20:37 '3x3 Eyes'
 0 drwxr-xr-x 2 abc  1000     0 Jan 13 15:11 'Adachi to Shimamura'
 0 drwxr-xr-x 2 abc  1000     0 Jan 13 16:01 'Ah! My Goddess'
 0 drwxr-xr-x 2 abc  1000     0 Jan 13 21:58 'Bocchi the Rock!'
20 -rwxr-xr-x 1 abc  1000 18436 Jan 13 20:51  .DS_Store
 0 drwxr-xr-x 2 abc  1000     0 Jan 13 22:16  Helck
 0 drwxr-xr-x 2 abc  1000     0 Jan 13 23:05 'Heterogeneous Linguistics'
 0 drwxr-xr-x 2 abc  1000     0 Jan 13 15:22 'Houseki no Kuni'
 0 drwxr-xr-x 2 abc  1000     0 Jan 13 22:37 "I'll Become a Villainess That Will Go Down in History The More Villainous I Become, the More the Prince Dotes on Me"
 0 drwxr-xr-x 2 abc  1000     0 Jan 13 23:01 'Isekai Bishōjo Juniku Ojisan to'
 0 drwxr-xr-x 2 abc  1000     0 Jan 13 22:14 'Isekai Ojisan'
 0 drwxr-xr-x 2 abc  1000     0 Jan 13 22:32 'Jahy-sama wa Kujikenai!'
 0 drwxr-xr-x 2 abc  1000     0 Jan 13 22:36 'Kimi wa Houkago Insomnia'
 0 drwxr-xr-x 2 abc  1000     0 Jan 14 05:39  Otoyomegatari
 0 drwxr-xr-x 2 abc  1000     0 Jan 13 14:51 'Tensei Shitara Slime Datta Ken'
 0 -rwxr-xr-x 1 abc  1000     0 Jan 14 09:41  test
 0 drwxr-xr-x 2 abc  1000     0 Sep 10  2021 'That Time I Got Reincarnated as a Slime (Digital) (danke-Empire)'
 0 drwxr-xr-x 2 abc  1000     0 Jan 13 18:49 'The Owl House - Comics by Moring Mark'
abc@c32464399018:/downloads$ 

though it works if I comment out the download mount so it's no longer persistant

this is my compose file (I also built it from your repo rather than pulling from the image)

---
version: "3"
services:
  fmd2:
    build: ./
    #image: banhcanh/docker-fmd2:kasm-v2
    container_name: fmd2
    environment:
      - PUID=1000
      - PGID=100
      - TZ=America/New_York
      - UMASK=022 #optional
    ports:
      - 3000:3000
    volumes:
      - $HOME/DockerAppData/fmd2-beta/userdata:/app/FMD2/userdata
      - /srv/remotemount/Media/Media/Manga:/downloads

[Banh-Canh]

Try on v3 i meant, i know about the permission issue. It's strictly due to how wine handle its permissions. It really is wine that can't write on a volume mounted in by the container on the host

[Nitrousoxide]

Try on v3 i meant, i know about the permission issue. It's strictly due to how wine handle its permissions. It really is wine that can't write on a volume mounted in by the container on the host

still getting failure to create directory errors. I can still exec into the container and touch a test file fine.

compose file with me pulling rather than building

---
version: "3"
services:
  fmd2:
    #build: ./
    image: banhcanh/docker-fmd2:kasm-v3
    container_name: fmd2
    environment:
      - PUID=1000
      - PGID=100
      - TZ=America/New_York
      - UMASK=022 #optional
    ports:
      - 3000:3000
    volumes:
      - $HOME/DockerAppData/fmd2-beta/userdata:/app/FMD2/userdata
      - /srv/remotemount/Media/Media/Manga:/downloads
    restart: unless-stopped

[Banh-Canh]

ah i know, you have to change the settings for fmd2 target folder; it has to be downloads/; relative to fmd2 install. Check my reworked branch for the settings.json sample, or just copy it and replace yours

[Nitrousoxide]

You mean the host's side? That's not going to work for me because the download location is on a remote share from my NAS mounted into /srv/ on this computer.

[Banh-Canh]

if you can get into your container shell and delete /app/FMD2/settings.json, it's gonna to do the trick. Restart the container after that.

[Nitrousoxide]

you mean /app/FMD2/userdata? I don't see a settings.json in /app/FMD2/

removing the one in userdata seems to let it download even with my real download directory mounted.

You'll probably want to add to the readme that under no circumstances should people change the download location, and how to fix it if they do (ideally not destructively with removing settings.json, if possible)

[Banh-Canh]

Indeed, in userdata. I'll get to it when i get the time.

Note that it downloads to /app/FMD2/downloads/ then sync it back to /downloads/.

You should indeed keep it to the default i set; aka downloads/ which mean the relative path inside FMD2 = absolute path: /app/FMD2/downloads/.

Can you confirm that everything is working as intended? you get your cbz ?

[Nitrousoxide]

Indeed, in userdata. I'll get to it when i get the time.

Note that it downloads to /app/FMD2/downloads/ then sync it back to /downloads/.

You should indeed keep it to the default i set; aka downloads/ which mean the relative path inside FMD2 = absolute path: /app/FMD2/downloads/.

Can you confirm that everything is working as intended? you get your cbz ?

It's almost there. It seems to be dropping both the completed cbz and the raw images in the mounted folder. Despite fmd2 being set to only cbz

abc@582e180f9ca7:/downloads$ cd 'Afterschool Girl'/
abc@582e180f9ca7:/downloads/Afterschool Girl$ ls
'Afterschool Girl - Ch.000'  'Afterschool Girl - Ch.000.cbz'
abc@582e180f9ca7:/downloads/Afterschool Girl$ 
abc@582e180f9ca7:/downloads/Afterschool Girl$ cd 'Afterschool Girl - Ch.000'
abc@582e180f9ca7:/downloads/Afterschool Girl/Afterschool Girl - Ch.000$ ls
001.jpg  002.jpg  003.jpg  004.jpg  005.jpg  006.jpg  007.jpg  008.jpg  009.jpg  010.jpg  011.jpg  012.png
abc@582e180f9ca7:/downloads/Afterschool Girl/Afterschool Girl - Ch.000$ 

I see the downloads directory under /app does correctly remove the images and leave only the cbz behind

abc@582e180f9ca7:/app/FMD2$ cd downloads/
abc@582e180f9ca7:/app/FMD2/downloads$ ls
'0x0 Memories'  'Afterschool Girl'
abc@582e180f9ca7:/app/FMD2/downloads$ cd 'Afterschool Girl'/
abc@582e180f9ca7:/app/FMD2/downloads/Afterschool Girl$ ls
'Afterschool Girl - Ch.000.cbz'
abc@582e180f9ca7:/app/FMD2/downloads/Afterschool Girl$ 

[Banh-Canh]

yeah it's the syncing thing, does it matter that png files are there? it's either it's there or i have to forbid any other format but cbz :x: hmm

[Nitrousoxide]

I mean, it wouldn't matter for a download or two, but you could easily have people downloading TB's of data, and doubling that (or more) by transferring both the images and cbz would be not great.

[Banh-Canh]

I'll see what i can do, it's already quite hacky as it is :/

[Nitrousoxide]

looks like rsync is included in the image. You could use that and pass along an env variable (which the user could set in the docker container creation) for which file types to be transfered.

Something like this?

#!/bin/bash

source_dir="/path/to/source/directory"   # Replace with your source directory path
dest_dir="/path/to/destination/directory" # Replace with your destination directory path

while true; do
  rsync -av --include '*/' --include '*.cbz' --exclude '*' "$source_dir" "$dest_dir"
  sleep 60  # Sleep for 60 seconds (1 minute)
done

[Nitrousoxide]

that has some downsides though, since I could see a user trying to delete a directory they decided they didn't want and rsyncing will keep putting it back unless they reset the container

[Banh-Canh]

it's actually what i'm using https://github.com/Banh-Canh/docker-FMD2/blob/master/root/usr/local/bin/sync_dir

i know that but i don't see any way around yet but reverting to wine 5

[Nitrousoxide]

actually you could add the flag to remove source file I think?

#!/bin/bash

source_dir="/path/to/source/directory"   # Replace with your source directory path
dest_dir="/path/to/destination/directory" # Replace with your destination directory path

while true; do
  rsync -av --include '*/' --include '*.cbz' --exclude '*' --remove-source-files "$source_dir" "$dest_dir"
  sleep 60  # Sleep for 60 seconds (1 minute)
done

[Nitrousoxide]

you wouldn't want to remove the directory until the whole download is done though. Since I'm sure that'll blow something up.

[Nitrousoxide]

I see you pushed the refactor to the main branch. I cloned that and made some tweaks to it on my local copy, you are welcome to implement them on yours if you'd like

first: /root/usr/local/bin/sync_dir

#!/bin/bash

# Function to monitor changes using inotifywait and sync with rsync
rsync -avz "$1"/ "$2"
monitor_changes() {
    while inotifywait -r -e modify,create,delete,move "$1"/; do
        rsync -avm --include='*/' --include=*"$TRANSFER_FILE_TYPE" --exclude='*' --remove-source-files  "$1"/ "$2"
    done
}

monitor_changes "$1" "$2" &

Changed the command a bit to remove the source files after it's transferred, so the container doesn't continue to balloon in size the longer it's kept up and running with its own /app download directory's stuff sticking around. Also fixes the potential issue of rsync trying to repush downloaded stuff that user deleted at the destination directory.

Also added an env variable instead of the file type so the user can set which file type to sync from the docker compose file like below:

docker-compose.yaml:

---
version: "3"
services:
  fmd2:
    build: ./
    #image: banhcanh/docker-fmd2:kasm-v3
    container_name: fmd2
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Europe/Paris
      - UMASK=022 #optional
      - TRANSFER_FILE_TYPE=.cbz
    ports:
      - 3000:3000
    volumes:
      - ./tmp/FMD2/userdata:/app/FMD2/userdata
      - ./tmp/downloads:/downloads
    restart: unless-stopped

added TRANSFER_FILE_TYPE env variable to let the user select the type of file it will transfer. It will need to match the type selected in fmd2. This will let them choose to transfer pdf's, epubs, etc. They can't select multiple types at the same time here as that would require multiple --includes (i think) in the rsync command.

Tested this on a few downloads on my end and this seems to work.

I didn't want to rebase my branch yet to your new kasm version to open a PR here, but feel free to implement this change if you want. I'll be using it locally at lest.

[Nitrousoxide]

Actually, sometimes it looks to corrupt the cbz file? I don't see why that would be. Rsync should be making sure the hash is identical.

I don't think using rsync -avm versus your rsync -avz should matter either there. That's just whether it transfers with compression or not or skips empty directories.

Some cbz files do make it over fine, which is why my testing looked okay initially.

Are you seeing that on your end too?

[Banh-Canh]

I'm guessing the deletion you are doing cause that. I did not implement it because i know fmd2 download everything then pack it to a cbz. So when it get sync in parallel and delete them, i think it confuses it. I didn't try your changes yet but that's my idea for now

[Nitrousoxide]

I'm guessing the deletion you are doing cause that. I did not implement it because i know fmd2 download everything then pack it to a cbz. So when it get sync in parallel and delete them, i think it confuses it. I didn't try your changes yet but that's my idea for now

Yeah that's probably right.

Adding a sleep 10 before it seems to fix it, though it does technically introduce a race condition. Probably not super likely to fail to be done zipping the cbz yet, but I suppose it's possible.

sleep 10 && rsync -avm --include='*/' --include=*"$TRANSFER_FILE_TYPE" --exclude='*' --remove-source-files  "$1"/ "$2"

[Jerrk]

For me it doesn't appear that fmd2 moves the completed .cbz's from "/app/FMD2/downloads" to "/downloads", they just stay in "/app/FMD2/downloads".

using unraid my path in the container is set as: /mnt/user/manga/.manga/:/downloads

in options -> save to -> default download path: /downloads

adding anything to the download queue just sends them to "/app/FMD2/downloads" and never moves it to "/downloads" /downloads is mapped correctly because if i put files in the directory outside of the container they show up as they should

also it appears that favorites are hard coded to use the windows path with \ separating the path and manga title instead of /. so i would have to go through all favorites manually and change the path. if that even works.

am i messing up the paths somehow?

[Banh-Canh]

For me it doesn't appear that fmd2 moves the completed .cbz's from "/app/FMD2/downloads" to "/downloads", they just stay in "/app/FMD2/downloads".

using unraid my path in the container is set as: /mnt/user/manga/.manga/:/downloads

in options -> save to -> default download path: /downloads

adding anything to the download queue just sends them to "/app/FMD2/downloads" and never moves it to "/downloads" /downloads is mapped correctly because if i put files in the directory outside of the container they show up as they should

also it appears that favorites are hard coded to use the windows path with \ separating the path and manga title instead of /. so i would have to go through all favorites manually and change the path. if that even works.

am i messing up the paths somehow?

are you using the kasm-v3 ? Unfortunately i believe you will have to change your favorites paths if it's set with the old downloading path. FMD2 should be configured to downloads to /app/FMD2/downloads ("downloads/" relatively to its installation path). My script will then synced it back to /downloads on the container where the mount to the host is.

[Jerrk]

are you using the kasm-v3 ?

yes

Unfortunately i believe you will have to change your favorites paths if it's set with the old downloading path.

when changing the "save to" location on the favorites tab of multiple manga, fmd2 automatically inserts the \ for windows paths between the path and the title instead of the / for unix paths. that is the issue.

FMD2 should be configured to downloads to /app/FMD2/downloads ("downloads/" relatively to its installation path). My script will then synced it back to /downloads on the container where the mount to the host is.

so "default download path" should be set to "/app/FMD2/downloads" in the app, and then you have a script set up which moves it to /downloads when the cbz is created? got it.

[Banh-Canh]

1) when in doubt just delete your /app/FMD2/userdata/settings.json

2) You shouldn't worry about hos unix vs windows process paths. You can set the relative path to downloads/ just fine in fmd2 ui.

3) That's it indeed

the container should log if my script is correctly syncing files, if you have issue paste them here i'll see if i can help

[Jerrk]

I deleted the settings.json and started over.

I set the "default download path" to "/app/FMD2/downloads"

i changed the "save to" path of all of my favorites to "/app/FMD2/downloads" as well Here you can see what i was talking about with the path having both \ and /, but if u say it doesnt matter i'll take your word for it.

Your script for moving the manga from "/app/FMD2/downloads" to "/downloads" now worked after restarting the container but it didn't remove the manga within "/app/FMD2/downloads" after it was completed.

and now if i set the "default download path" to "/app/FMD2/downloads" the manga actually gets downloaded to "/app/FMD2/app/FMD2/downloads" so i'm still doing something wrong

The logs don't seem to tell me anything other then when your script is moving manga and when webui connections are made.

added the log just incase it tells you something fmd2 log.txt

[Banh-Canh]

https://github.com/Banh-Canh/docker-FMD2/blob/eba398f6547e03e4472b0b451068a165d4104d4e/settings.json#L59

that's what i mean. You have to put it to the path relative to the FMD2 installation folder "downloads/" once you delete you settings.json you don't have to set anything, it's preconfigured.

[Jerrk]

Yes now the paths are all sorted out and working. "default download path" is "downloads\" and all the favorites are in "downloads\{title}".

Now i'm running into issues with the script copying the contents of "/app/FMD2/downloads" to "downloads\" and never deleting them so that as soon as a new manga is added it copying the entire directory to "downloads\" again.

Watches established.
/app/FMD2/downloads/ CREATE,ISDIR Maou no Hajimekata - The Comic
sending incremental file list
./
Candy & Cigarettes/
Candy & Cigarettes/Candy & Cigarettes -.- Vol. 01 Ch. 001 - The Old Man and Crime [Royal Translations, Fallen Angels] [MangaDex].cbz
........

I see you've talked about it with @Nitrousoxide a bit but haven't came up with a perfect solution yet.

But yeah, reimporting the same chapters over and over is not ideal, so some way to delete them from "/app/FMD2/downloads" after they've been copied would be great, but as you say FMD2 might not like that. maybe its possible to only run the script after downloads finish? idk

The separate image files being moved over is not a huge deal since i can take care of them with a simple rm command on a schedule, but throwing a condition to the script to only copy .cbz files might help there (though that only works if people are only using .cbz).

Thanks for the help and the developement 😄

[Nitrousoxide]

Yes now the paths are all sorted out and working. "default download path" is "downloads\" and all the favorites are in "downloads{title}".

Now i'm running into issues with the script copying the contents of "/app/FMD2/downloads" to "downloads\" and never deleting them so that as soon as a new manga is added it copying the entire directory to "downloads\" again.

Watches established.
/app/FMD2/downloads/ CREATE,ISDIR Maou no Hajimekata - The Comic
sending incremental file list
./
Candy & Cigarettes/
Candy & Cigarettes/Candy & Cigarettes -.- Vol. 01 Ch. 001 - The Old Man and Crime [Royal Translations, Fallen Angels] [MangaDex].cbz
........

I see you've talked about it with @Nitrousoxide a bit but haven't came up with a perfect solution yet.

But yeah, reimporting the same chapters over and over is not ideal, so some way to delete them from "/app/FMD2/downloads" after they've been copied would be great, but as you say FMD2 might not like that. maybe its possible to only run the script after downloads finish? idk

The separate image files being moved over is not a huge deal since i can take care of them with a simple rm command on a schedule, but throwing a condition to the script to only copy .cbz files might help there (though that only works if people are only using .cbz).

Thanks for the help and the developement 😄

I rebased my repo to this one (and kept the no-vnc version as a branch). Added my tweaks to my fork of this. You can build from context on that one by doing git clone https://github.com/Nitrousoxide/docker-FMD2.git navigate to the docker-compose.yaml file in the repo (not the example in the readme) and editing as you need for your local context... then... docker compose up --force-recreate --build -d

which will build an image from the context of the repo rather than pulling from the image repository. This will have my changes in it. It should remove the internal /app/FMD2/downloads after transfering them.

Please keep in mind my "fix" is very hacky and depending on the hardware or the size of the cbz files it's transferring I could see it trying to start before your server is done with initial compression. That said on my machine my hardware and the file sizes were such that I didn't have any corruption issues in the 10 or so gigs of chapters I downloaded to test it. If you find you need more time you can go to /root/usr/local/bin/sync_dir and add more time to the sleep command and then rebuild the image as I mentioned before.

I'm positive that there is a more elegant way to accomplish what I did that doesn't introduce a race condition like I did, but I'm not a programmer by trade.

[Jerrk]

The only thing i think could be changed in your sync_dir script would be instead of sleep add a check for time since latest file changed, this would also replace the inotifywait command. (not sure if that causes any other issues)

That would make the script only run after all of the current download jobs are finished, or if the connection gets timed out which would stop the download as failed anyway. this could be set as another variable as you did with TRANSFER_FILE_TYPE.

heres an example:

#!/bin/bash

# Function to monitor changes using find with -cmin and sync with rsync
rsync -avz "$1"/ "$2"
monitor_changes() {
    if [ "$(find "$1" -type f -cmin -"$THRESHOLD_MINUTES")" == "" ]; then
        rsync -avm --include='*/' --include=*"$TRANSFER_FILE_TYPE" --exclude='*' --remove-source-files  "$1"/ "$2";
    fi
}

monitor_changes "$1" "$2" &

with a THRESHOLD_MINUTES of 5, this script would only run the rsync command if there have been no changes to any files in /app/FMD2/downloads in the last 5 minutes.

We could also add another condition on top not to run if there are still image files in $1 that have yet to be cleaned up

Not a programmer by trade either 😁

[Nitrousoxide]

I like the check for last change, though 5 minutes might be too long. I, at least, would tend to think the container isn't working right the manga didn't show up in my download folder minutes after FMD2 says it finished. Probably something under 30 seconds would still be safe but still give it plenty of time to have finished zipping the file.

If there's a way to not prevent it from transferring until all changes in /app/FMD2/downloads are done that might be better too. Leaving moves pending for potentially hours because you've got a string of separate mangas downloading or even just one long manga with lots of chapters leaves you at risk of data loss if the container goes down before it transfers the download out. A *.cbz file sitting pretty with the same file size for 30 seconds is probably a good bet it's done being worked on, at least without a proper api from FMD2 or lock files from it that can indicate when it's working/done.

That said, I have no idea how to write that bash script, so I won't begrudge your work!