On Mon, Mar 7, 2011 at 09:51, Rainer M Krug <email@example.com>
The user is not that interestd in the inner workings of a program -
therefore a setting which uses time will be expected by a user to be
saving after that given time (or as soon as possible afterwards) and
not after up to 60 minutes when 10 minutes si set - that might be
confused with a bug. As you pointed out, reliability is the issue
here, and to have effectively "checkpoints" after the time set, after
which the copying can be picked up if an unexpected disconnect occurs.
So from a user perspective, I would say that option of having it time
based is only useful if this time interval is actually kept. The
second option is to go back to the "saving after x tracks". That is
the option which I think is more intuitive: when copying tracks to the
iPod, I usually know how many tracks I will copy, but I do't know how
long it will take - therefore I, personally, would consider the option
of having the "checkpoint" saved after x tracks more userfriendly.
Since we agree, I've reverted the change, except for separating the related GtkAdjustment from the number of threads GtkAdjustment, which was a real fix.
Rainer, how long does it take on your iPod to save 10 tracks + to write the database? I would suggest changing the default to something higher than 10 tracks, otherwise it could hurt performance severely for users who are not aware of this setting.