Jump to content

rafi

Established Members
  • Posts

    8,960
  • Joined

  • Last visited

  • Days Won

    148

Everything posted by rafi

  1. rafi

    Incomplete Download

    If you see the "torrent availability" number - under 1 - there is nothing to do but wait and hope, there are simply no sources for the rest of it. Yes, you can try another torrent, that has availability > 1 .
  2. ^ Seems like old issue report with qBT. Not sure it is still like this to date
  3. Yes I can access it. https://drive.google.com/file/d/0B1fLVXA8Va91Q3RTQkttWk05a1k/view?resourcekey=0-7Nvxv3fTZOVuJtRA_sxZvg OR: https://drive.google.com/file/d/0B1fLVXA8Va91Q3RTQkttWk05a1k/view?usp=sharing&resourcekey=0-7Nvxv3fTZOVuJtRA_sxZvg
  4. My solution is better, just disable the ads in settings.dat. backup yours, and download mine (@ my sig).
  5. Use your cellular data, or move to another campus...
  6. Try to check under labels->hidden and remove that label from the torrents.
  7. You should take care of forwarding your uTorrent post in your router and al;low it in your Windows firewall.
  8. With what build #? Try with my settings (@ my sig).
  9. Which build #? Try with my settings (at my sig)
  10. rafi

    3.5.x Beta

    Advanced->gui.use_fuzzy_dates = false You better search for your old settings.dat file and try and restore it...
  11. rafi

    3.5.x Beta

    Exit uT and try opening/editing settings.dat with BEncode. Search for webui.version and install_revision keys, and change both values to your installed build# (such as 46206). Save and re-run.
  12. rafi

    3.5.x Beta

    +6 is too small a change for another LAA. Pending +20 or more... ;P
  13. With this torrent too? https://releases.ubuntu.com/21.10/ubuntu-21.10-desktop-amd64.iso.torrent
  14. Try to open the sidebar (F7) and check that the "Torrents" root is selected/focused, exit, wait a bit, and re-run.
  15. Right-click->advanced-> change download location to a directory above the new path of that torrent.
  16. Maybe, but how do you know? Hashing checks is being done during download too, definitely file reads are done during seeding/uploading...
  17. Yeah, there was a design change in 3.x I/O subsystem, that might had this side effect (slower reads). Yet, there are lots of write (downloading) related functions that might have benefitted.
  18. Close utorrent, make a copy of resume.dat to test (so nothing to worry about) , then in BENcode you just open it and use Item->validate on the root. You can also save a copy. Yes, backup your settings.dat, rename mine instead and restart uTorrent with it (for testing only). If you want o use it, you'd need to adjust your paths and port#.
  19. >the files detail information that are to be downloaded in that particular torrent were NOT loaded at all Does these same files show correctly in 2.2.1 ? Can you give an example of such torrent (link/magnet/screenshot)? Maybe upload the .torrent file itself? It might be corrupted somehow. You can also check the validity of the resume.dat file with BEencode editor -> validate function. PS: You are welcome to try also with the settings file in my sig (including a lower cache setting). Make sure to save yours first.
  20. I am not using "completed" folder, but it should not matter. The question is - do you still see the torrent in your list, and can seed it? If so, I suggest to test by tring and add the exact same torrent file twice. In the case you mentioned - my guess would be that the second torrent did was NOT he same one. You can check both by "copy magnet/hash" and compare.
  21. This reflect some Windows-system issue that you should try to find. Like - try to see if *after* the shutdown - updated resume.dat file is being saved (no file permission issues) , and if the way you run uTorrent is using that same path this file is in.
  22. Yes and no. *IF* you have all the torrents added/loaded into utorrent (even w/o files) - it will simply check exactly that (compare hashes) and notify you (refuse to add the new torrent, but only add the trackers from it). If the torrent is NOT loaded, how should it know?!... So - no...
  23. Interesting comparison. I believe that to make sense of it, you'd need to display the NUMBER of bytes read, and not only the RATE. This way, we can be sure this was read "twice". As far as I can see, using Process-Hacker , it reports the correct size in the disk stats->hashing, but only HALF the amount being read by uTorrent process. I guess the other half is being "correlated" to he OS, so I believe you are seeing Windows caching/paging "helping" out to split the READ load... just not very efficiently as before. https://www.imagebam.com/view/ME7QPTJ?full=1
  24. I see two utorrent.exe in your 3.5.5 graphs, and both are also writing... Why? 3.5.5 with 0 writes here: https://www.imagebam.com/view/ME7Q9XA
×
×
  • Create New...