I have PIA and have so far been very pleased. If you are concerned about owner, maybe just go 1 year at a time, so you can pivot elsewhere if their reputation changes.
I DO get captcha on Google sometimes. But it just convinced me to switch to DDG and never looked back.
I use automatic torrent management mode with qBittorrent for most things and set it to seed every torrent for 40 days (iirc). If I had unlimited storage space, I’d probably seed forever, but I found that 40 days works well for me.
Also, don’t use a Debrid service. These services just leech requested torrents and then instantly stop seeding (if they even upload during download, not sure). This is bad for torrent health on public trackers, and will quickly get you banned on private trackers.
If you seed from the same drive where you store your files, learn the art of hardlinking any torrents you’ve downloaded (that don’t require unpacking), and you can seed without taking up too much more space on your drive.
Hard links are essentially links that point to the same file. When one link is deleted, the other still exists and it is only when the last hard link is deleted that the underlying file is actually deleted.
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!
Sounds like you already have a good start on this, but I wrote up instructions for myself when I move computers. I use calibre and an older version of the Kindle for PC app. DM me if you need help.
Maybe a dumb question, but how is this better than having your files on a nas? I have a nas and just play my media files from there on my tv and laptop. What do I get from having jellyfin?
Kodi/XBMC has been providing that for like 20 years though…
What jellyfin does provide that Kodi doesn’t is on the fly transcoding for watching on mobile device and remote access. If you don’t need that, Kodi might be a better choice providing a far wider array of features.
You’re not wrong but there are still drawbacks to Kodi where Jellyfin ends up being better. In my use case, with 5 tvs in the house, 2 are hooked up to Nvidia shield tvs but the other 3 are Chromecast w/ Google TV which have very limited storage unless I want to spend a fortune in hubs for each one to add a USB drive or micro SD.
With kodi installed I would regularly hit the storage limit of the device and have all kinds of weird bugs. Just as an example I had my daughter set up with a kids only account, but account switching would cause Kodi to become unresponsive for anywhere from 30 seconds to having to do a hard reset of the device. Jellyfin gives me the same access to my library with a lighter, more streamlined, persistent interface across devices and with easy and fast profiles. It still allows me to keep a pi as the host so the whole setup is low power (important for me as we’re on solar, every watt helps!)
I don’t really need the Kodi plugins I used to have if the main purpose of streaming my local content isn’t smooth and simple for the family. This is coming from a long time XBMC user, I’ve been running it since my original modded Xbox in the early 2000s.
Then you are doing it wrong. I have three instances of Kodi, one of them on completely hard drive less machine booted via PXE, the other two are Pis with minimal is on an SD card. All the media’s are stored on a NAS, and all the metadata is shared between the instances on MySQL, all of it (profiles, views, etc) shared across all the instances.,
“Wrong,” or a matter of preference and willingness to sink time into the project. Your setup sounds great, but it’s also easy enough for me to do a simple apk install for Jellyfin and host it on the pi that already has my network shares vs spending the time setting up a database and a local DHCP server etc. etc. Netboot is great but with a fraction of the setup with Jellyfin my needs were met, which was my original point. Also how many end users will take this route? Realistically not many.
Don’t get me wrong this was something i’d totally be into a decade ago so I get where you’re coming from, love the idea of having the metadata and everything scraped centralized, but what I have works and it’s easyyyyyyyy 🤷♂️
I just recently set up jellyfin as a way for my family to access the stored media outside of my house. Our current Networking setup doesn’t play nicely with VPNs so this was an easy way to do that.
But, Jellyfin/Plex has the advantage you get a nice pretty “app” that works on your TV/Roku/AndroidTV/etc. It handles transcoding if needed, keeps track of what you have watched, and lets you know when new things pop up.
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)
Nope, and it’s awesome. I2P works similarly to tor except instead of being discouraged, there’s a torrent client built in. Only down side is as it’s an entirely P2P network with alot of hops (more than tor) it’s quite slow.
The container connects to the VPN and only the VPN, now you can route whatever docker containers you want through that container as a network. Now that one VPN connection can serve any container you want.
I use gluetun to route traffic from some of my containers that need a VPN. qBittorrent, Jackett etc. Some containers dont have the option to configure a proxy so you’d have to setup a VPN client within a container which isn’t ideal. With gluetun its easy to attach a container to it and it just works
Why isn’t it ideal? I’m currently using this setup with containers routed through a gluetun container connected to a vpn via wireguard, and it seems to be working fine. I’ve verified using curl inside the relevant containers to query an IP checker and I’ve also used a torrent IP checker to confirm my torrent client isn’t leaking my IP.
Also the biggest benefit; You only need 1 VPN connection and 1 key pair for gluetun to connect everything. Most VPN providers limit the amount of active simultaneous connections. If you have lots of containers that need it then it’s not possible
My recommendation would be to give up on the port forwarding.
If maintaining a ratio is important to you then just rent a seedbox once in a while. 1 month with a seedbox gives me enough upload credit to last me several years.
Thereafter I just download torrents, I may be unconnectable but no big deal.
Does it not impact downloading? I thought the lack of port forwarding on my VPN was what was causing me to not connect to seeders even though qBittorrent shows them
My (possibly mistaken) understanding is that during the download phase your client is contacting seeds requesting parts. Although the data is going to be incoming it’s still an outbound connection because your client initiated it, so you don’t need to be connectable for that.
It’s the seeding phase which is problematic because downloaders can’t contact you to request parts. That said your client will still contact downloaders and offer parts, which again is an outbound connection so you don’t need to be contactable.
In summary download speeds are uneffected, but seeding rates will be diminished. With most private trackers you can still satisfy seeding requirements just by keeping the torrent available for however long.
As an aside I use mullvad & wireguard. I’ve found wireguard dramatically easier to configure, particularly in a docker environment.
I’m not on any private trackers. I’d be interested, but not until I have a more dedicated setup; I’m still very much a casual torrenter.
It’s good news then if port forwarding won’t affect my downloads, because that was the only reason I wanted it, but I saw others online say that lacking that feature is what was causing me not to connect to peers shown in my torrent client. Any idea what’s up with that?
Not really. Either my explanation is wrong or theirs is. Honestly could be either.
There’s so much misunderstanding and misinformation around torrenting.
All I know is that I’ve never had any problems downloading without being connectable. Never ever. It’s just not an issue.
Additionally, the vast majority of people torrenting in 2023 are using a vpn and none (very few) of them will forward ports so it can’t be a big deal.
Thirdly, there’s a lot of piracy purists / elitists who just can’t abide the idea that your set up may not have the best possible configuration for seeding. IMO, seeding on a residential connection is just a waste of time - download on a residential connection, seed on a VPS / seedbox.
There are two low level tricks that make a huge difference for seeding, even if you can’t open ports. These are generic Linux tweaks, you may have to adapt them for QNAP depending on how customized it is. Ask me if you need help. As far as I can tell you need to ssh to the “admin” acount, so open a command line and type ssh admin@your-nas.
To make both tweaks permanent you need to edit /etc/sysctl.conf. you can try editing them with nano. If you don’t have nano you’ll have to try with vi, but vi is not intuitive at all to use.
The first tweak makes you a lot more effective to peers that are on unstable connections and on wi-fi. Google uses it for most of their infrastructure, originally on YouTube. You can read their article for more info on how it works.
Add this line to /etc/sysctl.conf, close nano with ctrl-X, and reboot:
The second tweak decides how fast you can upload to people far away from you. If you calculate 2 * this value / your latency to them, you get the max speed you can upload to them. For simplicity I set it to be the same as my upload speed: let’s say you have 10 MB/s upload, that’s 10000000 bytes / second:
Add this line to /etc/sysctl.conf, close nano with ctrl-X, and reboot:
This way even someone in Australia with 500 ms of latency can download at 10 MB/s from you, (2 * 10000000 bytes / 0.500s = 10 MB/s)
After rebooting you can check if the setting stuck with the command sysctl net.ipv4.tcp_congestion_control and sysctl net.core.wmem_max respectively.
For any of this to make a difference you should disable µTP in your torrent client, or make it prefer TCP over µTP.
To me it makes an enormous difference, from barely any upload at all to 100 GB per day. And I’m sure it’s nice for whoever is downloading on the other side to get what they’re looking for super fast.
For any of this to make a difference you should disable µTP in your torrent client, or make it prefer TCP over µTP.
Just as a caveat, people disabling/throttling µTP may want to manually set appropriate global rate limits (upload/download bandwidth) otherwise it’s possible the torrent client will actually hit the maximum upload/download limits of the ISP or router forcing everything else on the network to slow down/time out during other internet usage. You’re obviously more advanced so you already know all this :)
Mainly it’s extra info for noobs messing around with their settings, often times noobs mess around with settings, disable things, etc. & then wonder why their torrent client keeps “crashing” their internet :P Making changes to µTP should be more of a last resort IMO.
µTP itself is a pretty big topic, there are a fair amount of people testing different settings in the qBittorrent / Libtorrent Github Issues but I’m not sure there’s even a consensus on a proper default setting. e.g. qBittorrent’s devs specifically chose different µTP defaults vs the Libtorrent library’s own defaults. qBittorrent defaults to having µTP enabled with preferring TCP (throttles µTP), Libtorrent defaults to having µTP enabled with peer_proportional (does not throttle µTP). The qBittorrent default is reasonable though I wonder if the Libtorrent default is the more “correct” approach but that’s certainly up to much debate. In both cases µTP is never disabled completely.
With my own testing I tend to keep settings at Libtorrent defaults just to observe behavior, with mainly private tracker peers I’ve noticed at least ~60% of my incoming connections are from µTP peers so at least for me it seems reasonable to keep it enabled.
The big problem with disabling µTP is that because it uses UDP, under some kinds of NAT you can get incoming connections despite being NATted. So you will loose some peers if you’re behind a NAT. If you’re not NATted there’s no connectability advantage, because every client that implements µTP can fall back to TCP.
The big advantage to disabling it that you can tweak these things. I don’t know of any client that lets you choose which congestion control algorithm that µTP uses. They all use one called LEDBAT that’s one of the first attempts to design one that avoids “bufferbloat”, i.e. that problem where the torrents fill up the buffers in routers and “clog up the Internet”. That’s nice however it doesn’t work well with networks with a lot of jitter like wi-fi, and it “loses” to algorithms that do fill up the buffer like the default TCP CUBIC. BBR avoids bufferbloat and is designed to keep working well with high jitter—Google’s intention was to make YouTube load faster on mobile phones. It also it wins over CUBIC, which is why almost every seedbox comes configured with no µTP and BBR congestion control. However, because it wins over CUBIC it will “clog up the Internet” in a different way: you may get lower speeds on everything else but don’t lose interactivity.
Linux comes with a different version of BBR that’s tuned to always yield to other traffic called lp. You enable it with net.ipv4.tcp_congestion_control = lp. I think lp is the optimal choice for seeding public torrents: you give full speed to faraway peers, but only when there’s nobody else that can do it.
What is your toreenting “signal chain”, so to say? Normally when you download things through qBittorrent, are you generally running bare? Do you use a VPN? Is your torrent client configured to use a specific NIC? If so, is that NIC active and passing traffic? There are so many variables that play into this.
No VPN because I live on the wild side and I use pretty stock settings. I resolved my issue but should I look into my NIC settings? Thank you for your help.
The NIC thing was more for if you were using a VPN. You can lock down your client to just use the virtual NIC your VPN client creates, so that’s always recommended when setting up your client.
piracy
Aktywne
Magazyn ze zdalnego serwera może być niekompletny. Zobacz więcej na oryginalnej instancji.