binhex

Community Developer
  • Posts

    7898
  • Joined

  • Last visited

  • Days Won

    37

Posts posted by binhex

  1. 15 hours ago, IMACRAB said:

    Hey, hey,

     

    I was off for a moment myself - thanks for looking into it again.

    Yes, it's the IP address of my Unraid Server.

    For reference, prowlarr uses the exact same address, but with a :9696 at the end.

     

    The :8191 is also not used by any other docker.

    ok then im out of ideas, all i can say is i use this image and it works for me *shrug*.

  2. 15 minutes ago, BobbyPoor_Boy said:

     

    Reporting the same issue.  Haven't been able to find a fix yet.  I believe the issue started last week.

    it looks like this maybe related to out of date mono, so i have kicked off the build again, please pull down latest in around 30 mins from now and report back.

  3. 14 hours ago, nickydd9 said:

    easy way to keep Vuetorrent up to date without manually updating it. 

    Yeah, this is the problem with bundling more and more stuff into the image, as soon as anything goes out of date people want the image rebuilding, so I'm loathed to include stuff that changes frequently, especially stuff that is not necessary, sorry but its a no to including it.

    • Thanks 1
  4. 7 hours ago, Nicon4454 said:

    i use sftp to move files from one unraid server to my main unraid server. so i use the connect option and use the drop down to chose sftp and put in my details.

    OK thanks for that, so it looks like the package 'kio' includes sftp and it looks like the package version has now bumped up to 'kio5' which once included in the build meant that sftp was available again (amongst other additional functionality).

     

    7 hours ago, Nicon4454 said:

    i have seen that sftp is back and thank you for that. i am sorry that it has taken me a while to respond but i have had some cardiac issues.

    Hey no worries, everyone has stuff going on in their lives, i hope you are ok.

  5. 1 hour ago, draeh said:

    I'm not sure what you did, but the latest update dropped about 1.3GB in size.

    i fixed up the broken github action for the base (it was on my todo list) which then kicked off the intermediate image builds, once done then i re-crated the krusader image, and due to the fact there were no updates as the base image is now up to date, the size of the image was dramatically reduced.

     

    from now on we should be back to more frequent automated base image builds, which should help alleviate any large increases in image size due to update churn.

    • Thanks 1
  6. 2 hours ago, MediaMaan said:

     

     

    Lol - yes the x is a 0 - I obfuscated the wrong section ;-)

    At any rate, with it being a zero, I think it is correct. It is working fine when I am on the physical network, so I know that bit is alright. Am I still missing something in having added the ZeroTier address range? 192.168.195.0/24

    hmm ok in that case it looks good to me, i have no idea why it's being blocked by zerotier.

  7. 17 minutes ago, wirenut said:

    Thanks for the suggestion, but its been there a few days with over 100 views showing and not one reply.

    I see you mention a couple posts up about a new build coming. I guess i will wait for that and see if it changes anything for me.

    sorry dude but there is nothing i can do about this as it's an unraid related issue, the image is accessible and for me i cannot reproduce the issue you are seeing.

    you could try deleting the container completely, then re-create it, this may fix it *shrug*.

  8. 13 hours ago, ph_ said:

    unfortunately the update seems to have introduced some problems, see below logs. The app does not work any more, the WebUI shows another error. Help would be appreciated. 

    this looks like the classic caching/cookies issue, try clearing down cookies/cache, try another browser, try incognito mode, one of those should get you going.

     

    FWIW i can confirm the latest image is working for me

  9. 6 hours ago, draeh said:

    Doesn't seem like any of those changes would lead to such an increase in the container. Most likely its one of the other supporting images that changed.

     

    This is what I hate about docker. The lack of traceability. I mean, yes, its traceable if I take each image that makes up the container and track them down manually one by one. Its tedious, but when I see a size increase like this I want to know why.

    the base os i use is arch linux, this is a rolling distro which means i need to update all packages if i want to pick up the latest versions of packages pushed to arch linux repository and because docker images are built in immutable layers this can lead to larger image sizes depending on when the base image was last built, so the size will vary somewhat, this is compounded for this image as it requires a lot of packages due to the fact its running a gui.

    I have not built the base in a while due to an ongoing issue, so i will take a look at it and see if i can fix it up and then kick off a new build of this image which should result in a reduction in the image size (nothing to update).

  10. 34 minutes ago, PaulieW said:

    how do you yourself connect multiple binhex containers to the same VPN IP so that it only counts as 1 device for the VPN provider (and all containers being connectable/port forwarded)?

    Yes i do bind multiple containers together via a single vpn container (privoxyvpn), but you will not receive an incoming port for the other containers, so if it's a torrent client (for example) then your only option to assign an incoming port is to create another separate vpn container, most vpn providers permit multiple connections, PIA i think gives you 5.

  11. 18 hours ago, PaulieW said:

    are you aware of such memory issues when 2 binhex-qbittorrent containers are routed as described?

    i have never thought of doing that!!, you won't get a incoming port for the second container and thus your speeds will be low, you know that right?.

     

    18 hours ago, PaulieW said:

    Correct I added 4 VPN Output ports;

    59142: The forwarded port provided by my VPN provider. Indeed this probably is not needed.

    seriously, don't do this!, this is not what it's used for, see warning:-
     

    Quote

    IMPORTANT
    Please note 'VPN_INPUT_PORTS' is NOT to define the incoming port for the VPN, this environment variable is used to define port(s) you want to allow in to the VPN network when network binding multiple containers together, configuring this incorrectly with the VPN provider assigned incoming port COULD result in IP leakage, you have been warned!.

     

  12. On 3/6/2024 at 9:57 PM, IMACRAB said:


    Thanks for the tip.
    Is it this one?
     

    docker run
      -d
      --name='binhex-prowlarr'
      --net='bridge'
      -e TZ="Europe/Paris"
      -e HOST_OS="Unraid"
      -e HOST_HOSTNAME="Gordon"
      -e HOST_CONTAINERNAME="binhex-prowlarr"
      -e 'UMASK'='000'
      -e 'PUID'='99'
      -e 'PGID'='100'
      -l net.unraid.docker.managed=dockerman
      -l net.unraid.docker.webui='http://[IP]:[PORT:9696]/'
      -l net.unraid.docker.icon='https://raw.githubusercontent.com/binhex/docker-templates/master/binhex/images/prowlarr-icon.png'
      -p '9696:9696/tcp'
      -v '/mnt/user/appdata/binhex-prowlarr':'/config':'rw' 'binhex/arch-prowlarr'
    e55bf9753161d07da6aeb272004338a0f3b9fea8b369d53840417411057cf307
    
    The command finished successfully!

     

    sorry i completely forgot about this post!, the above looks fine and i can see its using 'bridge' and not sharing the network with any vpn docker containers, so i am puzzled as to why prowlarr cannot connect, the URL you are entering into prowlarr for the 'host' is that the ip address of your unraid server, right?.

     

     

  13. 9 hours ago, Miralthor said:

    If someone also has problems with SMB access then here is the command to install the package required for this:
     

    sudo pacman -S kio5-extras

     

    Simply minimize the Krusader window, right click on the desktop, open Xfce Terminal and run the command.

    It would be nicer if SMB was included again in the next update, use it because it's easiest for me that way.

    it will be included in the next build.

  14. 2 hours ago, jtownmassacre said:

    I stand corrected. That info came from the Emby forums with a few people pointing the finger at the ffmpeg version being the issue. Someone even stated they manually updated to the latest ffmpeg and it started working again, so I'm at a loss as to what exactly the issue is. A google search does reveal others having the same/similar issue as me but the info is limited and wanting.

     

    If anyone has any advice for me as to how to get H.W. transcoding back it would be greatly appreciated. If I can't figure it out in the next couple of weeks, it's going to force me to switch to a different container and I want to avoid that if I can.

    Ah had time to do some more digging, so looks like there are two versions of ffmpeg included, emby-ffmpeg and ffmpeg, and its the former that needs to be updated, so i have contacted the upstream dev about the issue, hopefully he should pick up my message and if he agrees then should bump the package version and i can then rebuild and we should be good.

    • Thanks 1
  15. 5 hours ago, wirenut said:

    my repository is correct as you directed to check, should I still post the issue at https://forums.unraid.net/forum/58-docker-engine/ ??

    i am confident the image is fine as other people have pulled it down with no issue (including myself) so the issue you are seeing is either specific to your network in some way or it's an unraid bug that you are seeing, so i think it's worth a post there and see what people say.

  16. On 2/14/2024 at 3:33 PM, Emneth Design said:

    I'm on version 4.8.1.0 and unraid 6.12.6 and since the update getting ffmeg errors when transcoding with my RTX 3060 "Too many packets buffered for output stream 1:1" any ideas? Can the settings be changed does anyone know and if so.. how? :)

    A quick google search reveals that this sort of error is most common due to bad source file, does this happen with ALL files or just the odd one?.

  17. 9 hours ago, jtownmassacre said:

    the issue is having to do with ffmpeg and the fact that Binhex's Emby container is written in Arch. The latest ffmpeg is v 5.1 and the Arch repos are still using 4.8 or something similar.

    Not true, Arch tend to include bleeding edge stable releases and this image is no different, it includes ffmpeg 6.1.1, from the container:-
     

    ffmpeg version n6.1.1 Copyright (c) 2000-2023 the FFmpeg developers


    What is causing your issue i'm not sure, but its definitely not due to out of date ffmpeg.

    • Like 1
  18. On 3/11/2024 at 4:53 PM, Nicon4454 said:

    @binhex is there any information about this?

    i didn't knowingly include or remove sftp, there has been no alterations to the code, it was simply a re-triggered build from a upstream change.

     

    Can you detail how you previously used sftp in this container, that way i can then investigate why it got removed and how to add it back in.