Archived

This topic is now archived and is closed to further replies.

Firon

µTorrent 1.7 beta 2951

Recommended Posts

I wish the crashing would be solved in the next beta, hate going back to 1.6.1 constantly just so I can continue downloading. Looking at the dumps, the client seems to foul up when a tracker gives 302 Found response now, but I have no way of knowing for certain <.<

.. can't be the only reason. Otherwise I couldn't have downloaded for almost a full day before crashing again.

Share this post


Link to post
Share on other sites

I believe that the scope of this change is more about the "presentation" than anything else.

Just as an example: BitComet is very popular in the east and it already allows to prioritize preview pieces through a player that directly ask for the pieces needed. What I mean is that I don't see any relevant negative consequence. World isn't falling apart because of that feature. Torrents still work and that feature seems to have a very minimal impact overall.

If a full control is too harmful it could be at least implemented a partial control that lets you download the part necessary to preview a file. In every case what you need is enough of the file at the end. So you could use an option that gets about 8% of the file at the end and it would be enough to do the trick.

In the worst case you may finish with an incomplete file, but at least you could load it in a player and see at least those chunks you have downloaded. Hey, that's better than be left with a partially downloaded file that you cannot play at all ;)

Share this post


Link to post
Share on other sites

Fadeout could you take this to the Feature Requests forum please, instead of hijacking this thread.

Not that its worth starting a thread there anyway, cuz the feature you want is a no-no. The noobs shouldnt be allowed near a feature like this, and anyone who thinks they know something about BitTorrent shouldnt want to have a feature like this exist.

Share this post


Link to post
Share on other sites

BitComet isn't exactly the saint amongst BitTorrent Clients and claiming a function can't be all bad because BitComet has it won't work because they had and have various functions which are bad for the health of torrents.

IMHO the rarity of the usefulness of this function can't weight up against the negative impact if mis- and/or abused. Why implement a function that isn't going to be used by 99,9% of the users and could be mis- and/or abused by them all?

Share this post


Link to post
Share on other sites

Let me explain better.

The case of prioritizing the last part of a file would be used for previewing video files. Now this feature is being refused because it may harm the distribution of the file.

In this specific case it would mean that there is a very small number of peers/seeds. So let's say 10 or less. If there would be more than 10 then a preview option wouldn't do any noticeable harm to the distribution.

Now let's see what are the consequences in that case. Well the consequence is that the "preview" parts would be distributed first. If the torrent has already a so low number of sources then it's at risk whether the preview option exists or not, the risk would be just slightly higher. With the difference that with that preview option you at least guarantee that a partially downloaded file would be at least playable, while in the other case you would finish with just a broken file that you cannot use in any way.

I mean, let's say that this hypothetical torrent has a so small number of sources AND that everyone is using that preview option. The worst case is that they could at least preview the file if the preview option existed, while with the current client they get a slightly better chance of completing the file, but at the risk of not being even able to preview it in the case it cannot be completed.

So the bottom line is that a preview option would be harmful only in the case the torrent ALREADY risks to be incomplete. And in that case it would at least allow to preview the file.

I think the compromise is worth the very minimal impact it could have in very rare cases.

BitComet isn't exactly the saint amongst BitTorrent Clients and claiming a function can't be all bad because BitComet has it won't work because they had and have various functions which are bad for the health of torrents.

I'm just saying that it's being proven (in practice) that the option isn't having any noticeable negative effect. I'm not discussing BitComet, just using it as an example that the apocalyptic scenarios evoked in the case this option existed are largely unfounded.

I could say the same for eMule. It also allows to preview files and I don't see noticeable negative consequences because that option exists. It's a minor compromise that I believe it's worth the price.

Share this post


Link to post
Share on other sites

The cases in which you can actually preview a file (sequential media files such as mp3,divx and xvid that aren't packed) is fairly limited, the number of people who are interested in it are fairly limited, the number of people who will know and find this option is fairly limited and the number of people who will actually go to the trouble of using this function regularly are virtually nil I suspect.

If piece priority is used as you describe it the consequences might (I didn't think your whole concept through) be small and you might benefit from it but any other scenario someone messes with the piece priority it won't benefit the user and it might damage the health of the torrent. At least thats how I see it.

Maybe a specific preview function instead of a general piece priority function might provide a solution to that but still it means coding, testing and I-dunno-what-else a function that will hardly be used. With a couple more pressing matters on the todo list I don't think this function is gonna be implemented soon if at all. But I guess its up to the defs.

PS if you seriously want it considered you should post in the Feature Request topic and not here.

Share this post


Link to post
Share on other sites

thanks for the link mitchconner

1065 is fine, keeps my port even when cant bind it

1137 also fine

1170 is broken

so something changet between 1137 and 1170 that broke user defined listen port.

--- 2007-04-10: Version 1.7 (build 1170)

- Fix: "Move Up" tooltip corruption

--- 2007-04-10: Version 1.7 (build 1167)

- Change: Compact memory when system resources are low

- Fix: Improved UPnP device detection by setting TTL

- Fix: Multiple monitor clipping problem

- Fix: "Duplicate ID" detection

- Fix: A duplicate connection race condition

--- 2007-04-07: Version 1.7 (build 1137)

the only suspected thing could be upnp handling, but I dont use upnp

btw 1703 closed on its own on me when I tried to change the upload limit from the tray

Share this post


Link to post
Share on other sites
Richard wrote

@ rafi - the "identical" ones in these cases would not have different trackers, as they would be pointing to the exact same .torrent file (not just a matching infohash, but the exact same file). Identical entries should not get checked unless they have both the same name and .torrent. If this is not what you're seeing in the latest build, please let us know.

Yes, it is what I see. As I said - no big need, just strance to see two marks w/o any record of what feed you downloaded it from.

May be - just add the feed's name into the history list....

Share this post


Link to post
Share on other sites

kokobaroko: perhaps you should fix your problem with not being able to bind the port.

Share this post


Link to post
Share on other sites

>Firon

>perhaps you should fix your problem with not being able to bind the port.

perhaps utorrent should OBEY the options, I set "randomize port" to OFF not because it looks nice, but because I DONT WANT it to be randomized, since 1170 utorrent ignores that option

Share this post


Link to post
Share on other sites

@rafi: The torrent was downloaded directly from that link. So it wasn't downloaded 'off a feed'. There were two feeds that had the same link. That link was downloaded thus both feeds are marked. To me it makes much more sense then only marking one feed. Only thing I can think off is that you want to know which torrent name matched your filter but as rafi said it only checks them both if both the name and the link is the same.

Another way to see it: µtorrent adds the same torrent twice and marks both feeds. Upon adding µtorrent notices the second torrent is identical to an already loaded torrent (the first) and tries to add the trackers but since there are no new trackers de facto nothing happens when the second one is added. Because this is known up front µtorrent marks both feeds but downloads the torrent only once.

@kokobaroko: Have you tried deleting the settings.dat file yet (to reset all your settings)? Might be something is broken in there. All my µtorrent copies remember their port no-problem. And Firon meant that maybe the problem is that something is blocking/claiming the port you have set in µtorrent and it therefore tries a different port. Although it shouldn't chose a random port but give a Red Warning sign in the port status area of the status bar (bottom bar of µtorrent right of DHT status).

Share this post


Link to post
Share on other sites

@Lord Alderann: first I asid - it's not a big issue... Next your logic is wrong since one fact was missing (from you) - I use the smart episodes' filter/option. In this case - only the first found feed is handled, and the rest are ignored. this "first" one - should be marked.

Another point is that there is currently no way to tell what feed was torrent located on. The history list would be a possibility, a unique mark on the releases is another option (or just proper color code this mark).

Again, no big deal...

Share this post


Link to post
Share on other sites

Running on Linux (Debian) through Wine. Running great. Not as good as it could be, of course, as it's emulated.. but better than most crappy Linux clients. Funny how bad they are, apparently none of them can update tracker well, uploaded around 30GB and the tracker only saw 10GB, using another client.

uTorrent ftw.

Share this post


Link to post
Share on other sites

@rafi: Ah yes smart filter. Well I guess they check all feeds with the same link and name (without adding the torrent again) as a default behavior and didn't disable this when the smart filter is used.

@bonesaw: haven't used it myself but heard ktorrent isn't a bad linux client.

Share this post


Link to post
Share on other sites
@rafi: Ah yes smart filter. Well I guess they check all feeds with the same link and name (without adding the torrent again) as a default behavior and didn't disable this when the smart filter is used.

Exactly... a bit hard to get 'them' to comprehend this ... ;)

Share this post


Link to post
Share on other sites

Oh I think they comprehend just fine they probably cba to change such a minor frivolity :P

It wouldn't matter which of the two was actually loaded right?

Share this post


Link to post
Share on other sites

I always wondered why the question:

"The torrent you are trying to add is already in the list. Do you want load trackers?"

IF the tracker('s) is already in the list!?

Thanx

Share this post


Link to post
Share on other sites

@Stone: I know, I know, I say that only because it's not a native linux client, therefore, it will never run as it was designed for. Not emulated, you're right, only tried to make it easier to understand for those who do not use linux. :)

@Lord Alderaan: Yeah, it's really not bad.. but it lacks options, it's just too poor when you're used to uTorrent and all those options.

Share this post


Link to post
Share on other sites
I always wondered why the question:

"The torrent you are trying to add is already in the list. Do you want load trackers?"

Even if the tracker('s) is already in the list!?

True... just add the tracker to the torrent (if it does not exist there yet ) and stop asking silly questions... ;) you can focus on the existing torrent then,and log the mesage... or add an option "auto add tracker..."

Share this post


Link to post
Share on other sites

Well the warning is nice. Otherwise people are gonna wonder where the torrent went and might even think it wasn't loaded. And I guess a check if there are actually new trackers isn't made before displaying the notice. Another frivolity :P

Share this post


Link to post
Share on other sites

A user on a particular forum reported that there are problems in latest beta of moving downloaded torrents to correct category (category folder is not created).

Here is screenshot of his settings: http://i9.tinypic.com/4r1rujo.png

Can anyone confirm the issue?

(I can't because I mostly seeding. Maybe there are some small torrents somewhere especially for testing such kind of things?)

Thank you.

Share this post


Link to post
Share on other sites

Local Peer Discovery doesn´t work right anymore.

It finds my other PC but doesn´t transfer for a while, then it transfers about 20Mb and continues sitting idle for some time.

With the older versions of utorrent it trasnsferred at full speed till both clients had the same data......

Some chance to fix this ??

MfG Benny

Share this post


Link to post
Share on other sites
2007-05-05 06:39:12

@ Lucifer - is the failure to log RSS feed download errors reproducible? If there is a specific feed that exhibits this issue, please send over to me. Thanks.

Richard Choi : Sorry i'm late, been busy this week. The status shows it's downloading feed but torrents are not added or even downloaded. This happens mainly to tokyotosho rss feeds like this one :

http://tokyotosho.com/rss.php?filter=1&long=1

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.