-
Notifications
You must be signed in to change notification settings - Fork 10
[errno 98] Address already in use #13
Comments
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. |
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 (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. |
@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 |
@abwezi it's possible my version might also need to implement the chown script that this one does 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. |
@Nitrousoxide permissions is definitely the problem. I got it running with the current latest from this repo. Quoted reply from other issue below
|
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 |
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. |
Can you guys try I don't have a ci pipeline for this project so the versioning and all is manual sorry about that. |
ok, it seems like it's an issue with Wine 6.0 and later. I need to dive in a bit. |
Hey I'm pushing 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). |
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
|
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 |
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. |
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. |
you mean 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) |
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 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
I see the downloads directory under /app does correctly remove the images and leave only the cbz behind
|
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 ❌ hmm |
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. |
I'll see what i can do, it's already quite hacky as it is :/ |
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?
|
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 |
it's actually what i'm using i know that but i don't see any way around yet but reverting to wine 5 |
actually you could add the flag to remove source file I think?
|
you wouldn't want to remove the directory until the whole download is done though. Since I'm sure that'll blow something up. |
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:
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:
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. |
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 Some cbz files do make it over fine, which is why my testing looked okay initially. Are you seeing that on your end too? |
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.
|
yes
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.
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? |
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 |
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 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 |
Line 59 in eba398f
that's what i mean. You have to put it to the path relative to the FMD2 installation folder "downloads/" |
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.
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 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. 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. |
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! |
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 #11 (comment)
The text was updated successfully, but these errors were encountered: