Wrong support thread.

39 minutes ago, wgstarks said:

I don’t think this has anything to do with bitmagnet. If you go to the docker tab and click the icon for the iventoy docker you can select “support” and go to the support thread for that docker.

my bad sorry

I'll be curious to to see the results of the original author's web UI revamp. He's done some commits recently.  https://github.com/bitmagnet-io/bitmagnet/pull/280
 

Quote

This PR is a full rewrite of the web UI, incorporating the following features and improvements:

• Translations
• Themes
• Permalinks, closing
• [WebUI] Direct link to a torrent #192
• Health check within web UI
• Monitoring dashboard
• Queue management within UI
• Allow bulk-copying of magnet links and info hashes
• Separation of torrent files query from main search query, and pagination through files in a torrent
• Show sizes in MiB instead of MB
• Always show original torrent name in table, closing
• Show original torrent names #290
• Add documentation for starting Bitmagnet, closing
• The command to run the server is ./bitmagnet worker run --all=true #312

 

Edited October 23, 20241 yr by Dase
Added summary

Will qBittorrent docker find this container by itself as a DHT tracker or do I have to add it manually somehow?

On 12/28/2024 at 12:07 PM, Lavoslav said:

Will qBittorrent docker find this container by itself as a DHT tracker or do I have to add it manually somehow?

In my personal use case, Bitmagnet includes its own seperate DHT tracker, and qBittorrent has its own seperate DHT tracker used when it downloads files. This worked well, and there was no reason to share one tracker between them. Did you have a use case where you needed to share the DHT tracker between them?

Hello binhex, I have opened an issue at github regarding config.xml/classifier.xml not working the way I think was intended. Maybe you can take a look when you have time?

 

Thank you!

 

https://github.com/binhex/arch-bitmagnet/issues/2

stopped working for me 6 days ago...any ideas?

2025-01-15 13:37:26.954 SAST [718] ERROR:  duplicate key value violates unique constraint "queue_jobs_fingerprint_status_idx"
2025-01-15 13:37:26.954 SAST [718] DETAIL:  Key (fingerprint, status)=(4e722b274ee20a5ed72d50fa3f195b4e07343a1cb24ab9dbe578e8fb5a200a75, retry) already exists.
2025-01-15 13:37:26.954 SAST [718] STATEMENT:  UPDATE "queue_jobs" SET "status"=$1,"run_after"=$2,"ran_at"=$3,"error"=$4 WHERE "id" = $5

2 hours ago, bar1 said:

stopped working for me 6 days ago...any ideas?

2025-01-15 13:37:26.954 SAST [718] ERROR:  duplicate key value violates unique constraint "queue_jobs_fingerprint_status_idx"
2025-01-15 13:37:26.954 SAST [718] DETAIL:  Key (fingerprint, status)=(4e722b274ee20a5ed72d50fa3f195b4e07343a1cb24ab9dbe578e8fb5a200a75, retry) already exists.
2025-01-15 13:37:26.954 SAST [718] STATEMENT:  UPDATE "queue_jobs" SET "status"=$1,"run_after"=$2,"ran_at"=$3,"error"=$4 WHERE "id" = $5

Looks like a duplicate key in the database, no clear idea how to fix it other than trying to hack the database, you could try a restart of the container and it might sort itself out, if it doesnt then create a github issue here

Note:- This closed issue looks like a close match:- https://github.com/bitmagnet-io/bitmagnet/issues/285#issuecomment-2233382128

On 1/14/2025 at 5:44 PM, slushieken said:

Did you have a use case where you needed to share the DHT tracker between them?

Not in particular, but since I know diddly-squat about DHT protocol and how bitmagnet and my download container communicate with each other I was wondering do I need to add my tracker instance to each torrent in my downloader to speed up things along or is it fine as it is.

Thanks, looks complicated but will give it a try.

Maybe i'll just do another instance....

1 hour ago, bar1 said:

Maybe i'll just do another instance....

I had this problem a few months ago and just deleted the db and restarted the container (nuke and pave). The container created a new empty db so basically started over from scratch.

On 1/15/2025 at 10:38 AM, Lavoslav said:

Not in particular, but since I know diddly-squat about DHT protocol and how bitmagnet and my download container communicate with each other I was wondering do I need to add my tracker instance to each torrent in my downloader to speed up things along or is it fine as it is.

That makes sense.

 

I am not an expert either, but I can say confidently it is unnecessary to have them working together or communicating, and that it seems to me the design and architecture would be to run separate DHT engines independently. If this answers you stop here. If you're interested in more info re: how that works and why they need to be seperate, I included my probably technically inaccurate explanation below.

 

As to how DHT works, I understand that once you plug a hash into your bittorrent client, the DHT search engine in there makes a search on the DHT network for a node that is sharing that hash, and from that node all the current seeds/peers are gathered which are offering that hash. In the case of your bittorrent client, it stores the seeder/peer data, then begins downloading from each of these, first the metadata, then it moves on to the files.

 

In the case of bitmagnet it works a little different.  It gathers hashes along with seeder/peer data, then it reaches out to the seeder/peers, gathering their existing DHT entries and any available metadata. This continues on down the line, adding the discovered hashes and metadata into your local DB. I would imagine it then 'forgets' that seeder/peer data, as it has is no reason to keep that. The only thing bitmagnet needs to store is the metadata and the hash.

 

TL; DR: In short, the biggest difference between DHT handling in your bittorrent client and bitmagnet, is that the seeder/peer are only needed for bitmagnet ephemerally. The bittorrent client however needs to track the seeders/peers, as this is who it contacts for the actual file download/upload.

 

Following is a DHT protocol primer, but all that will do for you is break down how the protocol works. It doesn't answer your question, but maybe it is part of what your looking for.

 

https://medium.com/@kyodo-tech/the-bittorrent-dht-and-decentralized-content-sharing-bb91befdb294

 

 

Edited January 23, 20251 yr by slushieken

Any ideas about this error?

 

 

Hello there, whenever I try to pull the docker image (either from the community apps or from docker pull) it throws an error, if im logged in with my docker or github/ghcr.io accounts (access keys configured, etc) them its 'ghcr.io: response from daemon denied'. If I am not logged in, then its 'Docker error response from daemon: Head <ghcr.io url to image>: unauthorized'. I have had this happen with another binhex docker image too, overseerr, but the bedrock minecraft server and *arr dockers download perfectly fine. What is the issue here?
screenshot shows pulling arch-bitmagnet from community apps, NOT logged in to ghcr.io in docker

 

Edited March 2, 20251 yr by L Ingwor
removed personal info from screenshot

bitmagnet updated fine here but it looks like postgres was switched from 16 to 17, that won't work on existing installs, can't upgrade postgres major versions.

 

2025-03-02 19:46:00.453 CET [69] FATAL:  database files are incompatible with server
2025-03-02 19:46:00.453 CET [69] DETAIL:  The data directory was initialized by PostgreSQL version 16, which is not compatible with this version 17.2.

 

Just now, Kilrah said:

bitmagnet updated fine here but it looks like postgres was switched from 16 to 17, that won't work on existing installs, can't upgrade postgres major versions.

 

2025-03-02 19:46:00.453 CET [69] FATAL:  database files are incompatible with server
2025-03-02 19:46:00.453 CET [69] DETAIL:  The data directory was initialized by PostgreSQL version 16, which is not compatible with this version 17.2.

 

working on it, i know what the fix is and a new image is building.

Yup, new push is fine

10 hours ago, L Ingwor said:

Hello there, whenever I try to pull the docker image (either from the community apps or from docker pull) it throws an error, if im logged in with my docker or github/ghcr.io accounts (access keys configured, etc) them its 'ghcr.io: response from daemon denied'. If I am not logged in, then its 'Docker error response from daemon: Head <ghcr.io url to image>: unauthorized'. I have had this happen with another binhex docker image too, overseerr, but the bedrock minecraft server and *arr dockers download perfectly fine. What is the issue here?
screenshot shows pulling arch-bitmagnet from community apps, NOT logged in to ghcr.io in docker

 

working on this too, also see the fix, i will let you know when all is fixed shortly.

 

EDIT - Fixed, please try pulling the image(s) down again.

6 hours ago, binhex said:

working on this too, also see the fix, i will let you know when all is fixed shortly.

 

EDIT - Fixed, please try pulling the image(s) down again.

Yep it pulls successfully now, thanks!

Is anyone running this through a VPN with port forwarding? 
 

I'd love if there was something like the deluge-vpn docker for this.
 

I've currently set bitmagnet to connect through a gluetun-vpn docker with port forwarding enabled, and manually set the bitmagnet ports in the docker config to the port that got forwarded in the vpn docker. It seems to work fine, and since PIA forwarded ports seem to persist for such a long time even after disconnecting for me, it's not overly onerous to check in every month or so. But still it would be nice if it was all scripted, especially if the deluge-vpn script could be adapted to this?
 

Honestly, I'm not sure if port forwarding will make a big difference since it seems to work without it. But since bitmagnet has already proven to be a gem at finding some rare stuff, I'm willing to devote a separate vpn instance with it's own port forwarding if it helps. 

Thanks so much for your dockers, Binhex. <3

13 hours ago, death.hilarious said:

 

Is anyone running this through a VPN with port forwarding

 

I installed the binhex-privoxyvpn docker just so that I could route this and several other dockers through it using Shared Network.

17 hours ago, death.hilarious said:

Is anyone running this through a VPN with port forwarding? 

port forwarding is not required.

 @binhex Are you able to explain how the SHARED_NETWORK variable works? I have been unable to find anything in the github code or in the documentation? What does it check for? Thank you very much for your time.

10 hours ago, csb said:

 @binhex Are you able to explain how the SHARED_NETWORK variable works? I have been unable to find anything in the github code or in the documentation? What does it check for? Thank you very much for your time.

Sure, i need to document this, so SHARED_NETWORK variable is used when you are sharing the networking of another container, for example a VPN enabled container with this container. This sets up a monitor that checks the VPN containers network and if it goes down then it also shuts down this container.

To be clear this is not related to any potential IP leakage, it is purely to ensure that the container will get correctly shutdown when the VPN container is shutdown to prevent the nasty UNRAID Web UI issue, where UNRAID has a hissy fit and keeps attempting to restart the container that was using the VPN network, and as the network no longer exists it keeps on restarting in a loop, this MAY be better handled in v7 (not tested), but i know it was definitely not handled correctly in prior versions of UNRAID.

 

One final note on this, SHARED_NETWORK only works when sharing the network of one of my VPN enabled images, if you are using gluetun or anything else then it won't work and should be set to 'no'.