I found this tool www.sidify.de a while ago. They have a paid solution, which you could pirate a crack for on a site of your choice. Maybe not the best solution, but it downloads the Tracks/Playlists/Albums by recording the audio and adding all the metadata.
Check out something like smart dns proxy, it works for all the uk tv channels with streaming services. It’s much more reliable than VPNs for that particular use case.
Anyone else has cross-seed configured? I started the process, created the config.json and now I need to configure it. It would be useful to see how someone else set it up and why. I feel the provided explanations in the config file are just a notch too high than what my hobbyist mind can understand atm. Then there’s direct client injection or autotorrent2 I still have to figure out.
For those curious, cross-seed allows you to take what you are seeding and find where else that torrent is and seed it there too, within a defined set of trackers. Perfect for sharin’ ye booty, arr!
The only ports you need to expose from Gluetun are the ones for the webUI for each of the containers you’re running thru it. You should never expose the port for incoming connections since that would make your torrenting traffic avoid the VPN.
Your qBittorrent and *arr containers should be run with network: “service: gluetun” in your docker-compose file (assuming you’re using compose)
Can someone explain to me what port forwarding in the context of torrenting is about? I use qbittorrent and nordvpn in docker containers and have never exposed/forwarded a port but get more than adequate upload/download speeds.
Port forwarding allows you to bypass your NAT firewall which will naturally block all unsolicited traffic on a closed port. What that means for a torrent download is peers cannot introduce themselves to you and create a new connection, you can only connect to active peers who have their ports open.
Just to add more background to that, before your torrent can begin downloading pieces from various peers, you need to know the address of the peers sharing the pieces you need. Typically that is handled by the tracker and/or DHT. A tracker acts as sort of a logistics middle-man. It helps facilitate efficient transmission between peers by tracking what each peer has and needs. If peer B needs piece X, the tracker will supply peer B with the address to peer A who has piece X. Assuming peer A has their incoming port open, they will accept the request for piece X and send it to peer B. If their port is closed, the request will simply be denied and no traffic will be shared between the peers. The tracker’s address, as well as the data hash and some other misc data is coded into the torrent file. DHT is a little more unique and complicated. It is a fully distributed hash table on a P2P network and does not rely on a tracker at all, it’s strictly P2P. The only little catch to that is to initially introduce yourself into the network you need to bootstrap your connection using some hardcoded addresses, often from a very centralized source. Port forwarding becomes much more important for DHT because after the initial bootstrap, there is no middle-man, it’s strictly peer to peer and by having your ports closed, your client can’t effectively communicate across the network. Without two-way communication across peers, your client will generally be stuck with a very limited pool of peers it can communicate with. Magnet links as well as most torrent clients utilize DHT.
One reason it’s not so noticeable these days when ports are closed is because many torrent peers exist in big data centers with virtually unlimited bandwidth. When torrents were still young, most if not all peers were hosted on consumer grade hardware at a residence so you needed every connection you could get.
If your torrent download happens to be a well-known Linux ISO, chances are very likely that there will be at least two or three peers you’ll connect to that exist in a data center, they will most likely account for 80%+ of your download speed.
Blocking ports ultimately hurts seeding the most which can effect the overall “health” of a torrent. Say a peer labeled A can’t connect to those giant data center peers for whatever reason, they now have to seek out other peers that may have the data they are looking for. If all the other peers have their ports closed, well then the torrent is essentially dead for peer A and they’ll have to either wait for someone with open ports to come online and start seeding or search for an entirely new torrent.
Sorry, this was a bit of an on-the-go mind dump so please anyone correct me if I’m wrong anywhere here but that’s pretty much the gist of port forwarding in the context of torrenting.
When torrenting your client should be “Connectable” which means fully accessible from others. You can use the guides others have posted to achieve that but basically, an unconnectable client can still seed to those who are connectable, but two unconnectable clients cant connect to each other. Or at least this is how it has been described to me by a private tracker.
check one of my previous comments on my profile. the provider I mentioned has french channels for ~20eur/year. in my comment a mention a new box I bought but before that I was using the service on a mi box given by my ISP
I have the same problem. I generally just leave my torrent client running in the background when I work. I never leave it running because I think of my parents’ electricity bill.
If you have a server the key is just… time. Leave it be, and when you’re not downloading anything, go full throttle on sharing!
I’ve spent all today and yesterday trying to get this working with PureVPN and QBitTorrent and it hasn’t been working much at all 😭. It’s been painfully slow when it works at all, which has been rare. Although it has been doing the job of hiding the Docker container IP so that’s good, and it makes me think it’s something minor, like port forwarding not working because of PureVPN or something off with my settings, or it’s a qBittorrent issue, or Docker and Linux inexperience.
Admittedly troubleshooting has been slow because I’m super new to Linux and Docker and keep running into permission and file system issues. Running the VPN and torrent straight in my computer was way easier, but I’d really love to be able to run Plex and a torrent client on the same computer on at the same time with Plex not going through the VPN and the torrent client going through it, which is what this seems great for.
I’ve set it up with PrivadoVPN without issues, using Docker. Gluetun in its own docker container and Qbittorrent in its own, with network mode set to use the Gluetun contaoner. Haven’t tested downloading a lot though. Gluetun has some good docs how to set it up in Docker.
Maybe it’s my VPN provider then. I’ll have to try it with another one. I’ve followed so many of those documents. Do you use Port Forwarding with PrivadoVPN?
piracy
Ważne
Magazyn ze zdalnego serwera może być niekompletny. Zobacz więcej na oryginalnej instancji.