You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi, I've been testing using BiglyBT. I wanted to add some test torrents to the demo and seed them. BiglyBT includes a non-standard field in the torrent info dict. The field is name.utf-8. For example:
Since it's not a standard field, the Index removes it, which changes the torrent infohash (hash for the info dictionary). If you want to seed the torrent, the process would be:
Generate the torrent from sources with BiglyBT.
Upload the torrent to the Index. That would generate a torrent with a new infohash.
Download the new torrent from the Index.
Remove the previous torrent from the BiglyBT.
Add the new torrent.
BiglyBT starts downloading it, but nobody has it since you are the first seeder.
You'll need to tell BiglyBT you already have the sources for that torrent. However, that does not work for me. In general, that is a tricky task for most clients. I guess the option to synchronize the client with the folder storing the sources is the option Check Files Exist.
I think that process is excruciating, but maybe it's just me. I recommend adding non-standard fields in the info dict to the Index to avoid changing the infohash.
Transmission
KTorrent
BiglyBT
Deluge
qBittorrent
I have not checked all of them yet; it seems Transmission does not include any non-standard field.
cc @torrust/maintainers
The text was updated successfully, but these errors were encountered:
@josecelano I think that we should have a set of "community" info dictionary schemas; some sort of whitelist format. In general if we find the format unofficial format somehow useful and not abusive; then I think that we should be quick to accept a new schema into our whitelist.
This white-list could be controlled by the configuration of the index.
@josecelano I think that we should have a set of "community" info dictionary schemas; some sort of whitelist format. In general if we find the format unofficial format somehow useful and not abusive; then I think that we should be quick to accept a new schema into our whitelist.
This white-list could be controlled by the configuration of the index.
Hi @da2ce7 do you mean the white-list should be dynamically injected as configuration at run time? We have to change a lot of things to allow that:
The way we parse the torrents. It's a hardcoded Rust struct.
The way to store them in the database. We also use hardcoded table columns.
For now, I would just add it, and add a schema with what we consider a "valid" torrent.
In the future, we could implement those changes. I think those changes could also be good for other reasons:
A more generic way to parse the torrent would be good for giving the user better errors.
A more flexible way (maybe a NoSQL database) to store the torrents could also allow us to easily change the database structure for torrents, allowing at the same time old torrents without a field and new ones with the new field. Although, it could be implemented with an extra table for dynamic extra fields (rows not columns). However, I would keep it simple if there are only a couple of cases for torrents using custom fields out there. It would be nice to have stats.
Hi, I've been testing using BiglyBT. I wanted to add some test torrents to the demo and seed them. BiglyBT includes a non-standard field in the torrent
info
dict. The field isname.utf-8
. For example:Since it's not a standard field, the Index removes it, which changes the torrent infohash (hash for the
info
dictionary). If you want to seed the torrent, the process would be:Check Files Exist
.I think that process is excruciating, but maybe it's just me. I recommend adding non-standard fields in the
info
dict to the Index to avoid changing the infohash.I have not checked all of them yet; it seems Transmission does not include any non-standard field.
cc @torrust/maintainers
The text was updated successfully, but these errors were encountered: