Everything posted by slushieken
-
Triggering udev events: /sbin/udevadm trigger --action=change
FYI to anyone checking, this same error shows up during a plain, vanilla, stock install of 7.0.1 during initial boot up.
-
[Support] binhex - bitmagnet
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
-
[Support] binhex - bitmagnet
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
-
[Support] binhex - bitmagnet
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?
-
[Support] binhex - qBittorrentVPN
Ok this is strange but I think if you are just patient, the GUI can connect again. I couldn't get my browser to connect to the GUI port 8080 either after a very recent reboot (few days ago). My guess is it was related to an upgrade I just completed to 6.12.8, for which I rebooted. It seemed to be working fine until that upgrade and reboot. I had stopped the container until I could troubleshoot better. I rebooted this AM a couple of times, noticed I still could not connect, and I started gathering the docker logs to post here. Then I thought I would run a TCP packet capture to assess whether it was networking or the application itself. After about 10 mins time (while I was writing this post in fact) I notice the docker log suddenly updated with a bunch of new lines, and I could then connect to the GUI port normally! I'll watch to see if I can help further, but I next need to know how to gather the supervisord.log for you. I use and am still using 'Bridge' network mode only.
-
[SUPPORT] testdasi repo
I am doing a fresh, new install of latest, and getting this too. I have tried at least 3 different repo's and 3 different revisions- no luck. The good news is this repo is the one that comes closest to working - only grafana is failing. The logs in the container are absolutely empty for grafana. At console I execute "grafana-server" it says "Grafana-server Init Failed: Could not find config defaults, make sure homepath command line parameter is set or working directory is homepath" Can someone kind soul out there take a look at this? There are too many building blocks required to get this stack working, and I am not familiar enough with any of them to even start troubleshooting through those. 🤕 Thank you.
-
Case icon requests
I drew this basic Silverstone CS351 png to populate my dashboard, since there is not an existing image for that. I used a picture of the server front as a guide, and traced the outline over that. I see others in this thread include 3 different copies for their png's. On my Unraid server (the way I use it), I didn't find a place to use those. So I searched this thread for a set of requirements, eg what is needed for a full set of images, and where those would be uploaded, but I couldn't find an explanation. Someone who understands better what is needed and why/where it goes - it would have been helpful to have that so I could create a full set. Anyway, here is what I have so far.
-
diskmv -- A set of utilities to move files between disks
I just wanted to say this script is just... amazing. I have been working on cleaning up nearly 20TB of movies and tv shows for several years now split incorrectly over time due to this or that, settings errors on splits, etc. I have been having success over that time with many different methods and a hit and miss effort, but yours wrapped it all up in one fell swoop. Thank you.
-
ZFS plugin for unRAID
Steini, I just discovered this plugin... really want to use it. But, I am at at current release: I am sure it is a pain to do this each time, but can you compile again vs. current 6.2.1?