Update frequency

[kovidgoyal]

Certainly integrating a bit torrent distribution method into calibre is possible, but the major problem with that is the effort it would take to implement, and the problems with making seeding robust.

You have to make the seed server go through firewall, router NAT layers and hope that the antivirus does not decide you are a trojan of some kind.

[BetterRed]

Originally Posted by HarryT

Would there not be an issue with BT distribution that a lot of old versions would stay hanging around out there? With the current system, you're guaranteed to always have the current release, but with BT, what would be to stop someone inadvertently getting an ancient version?

BT would likely only be used by those with some understanding of what they are doing. And if the tracker site doesn't openly 'advertise' torrents for old versions then the chances of starting a download of an old version is small.

Presumably there'd have to be a separate torrent file for each calibre version/flavour, i.e. calibre-64bit-1.42.0.msi.torrent, calibre-1.46.0.dmg.torrent etc. That's what LO and ComicBookRack do.

BR

[eschwartz]

The simplest solution would be simply to offer a .torrent &/or magnet link as an alternative download on the main download pages (and archives), and add the http url as a web seed to start things going. That would definitely ease the congestion on your server, at least from the torrent-savvy.

Maybe then you could offer a direct link to start the respective torrent from the alert popup. How this would integrate with the linux installer, I am not sure yet, but it would work for Windows/OSX.

[Hampshire Nanny]

Originally Posted by kovidgoyal

Indeed, linux makes up less than 2% of the calibre install base. And I am the only calibre developer that actually uses linux. If it were not for that, the linux version of calibre would likely not exist.

I hope you won't abandon support for Linux. While I am using Windows today, I will be installing a Linux system as I near retirement. For now, learning to effectively manage a Linux OS simply requires too much mental effort.

[kovidgoyal]

@HN: Dont worry I have no desire to abandon linux, it is what I use myself

@eschwartz: The server is fine, there is no need for BT at the moment, the problem only rears its head if calibre were to auto-update. And I have no plans to implement auto-updating, for all the reasons mentioned in the FAQ. I only posted in this thread because someone claimed the real reason I dont implement auto-updating is because I am greedy.

[eschwartz]

Originally Posted by kovidgoyal

@HN: Dont worry I have no desire to abandon linux, it is what I use myself

@eschwartz: The server is fine, there is no need for BT at the moment, the problem only rears its head if calibre were to auto-update. And I have no plans to implement auto-updating, for all the reasons mentioned in the FAQ. I only posted in this thread because someone claimed the real reason I dont implement auto-updating is because I am greedy.

You're still allowed to implement BT, you know. It would lead to faster manual downloading too.

And maybe even useful groundwork for the future???

[theducks]

Originally Posted by HarryT

Would there not be an issue with BT distribution that a lot of old versions would stay hanging around out there? With the current system, you're guaranteed to always have the current release, but with BT, what would be to stop someone inadvertently getting an ancient version?

Just takel down the tracker for the old version. each 'update notice' would have the dot torrent file for the current seed, not the old one

(that would still leave the trackerless method, but they still need the 'torrent' file to use that)

BTW the seed could be the complete set of versions. those in the know, know how to pull a subset of the torrent if they care)

[eschwartz]

Originally Posted by HarryT

Would there not be an issue with BT distribution that a lot of old versions would stay hanging around out there? With the current system, you're guaranteed to always have the current release, but with BT, what would be to stop someone inadvertently getting an ancient version?

Or do it the same way the current downloads work...

All versions of everything in the archives, the main download pages have special links which redirect to the latest versions.

Why should .torrents be any different? http://status.calibre-ebook.com/dist/torrent/win32

[eschwartz]

Originally Posted by theducks

Just takel down the tracker for the old version. each 'update notice' would have the dot torrent file for the current seed, not the old one

(that would still leave the trackerless method, but they still need the 'torrent' file to use that)

BTW the seed could be the complete set of versions. those in the know, know how to pull a subset of the torrent if they care)

What do trackers have to do with it? DHT and PEX are pretty thoroughly supported.

magnet links are trackerless too. Or at least, they download the .torrent using DHT and can then use trackers from that. Or so I understand. Not that we really need them.

Also, using one torrent which gets updated to include newer versions will mean everyone hosting old versions will be cut off, which is kinda stupid.

[kovidgoyal]

Originally Posted by eschwartz

You're still allowed to implement BT, you know. It would lead to faster manual downloading too.

And maybe even useful groundwork for the future???

I'm allowed to do pretty much anything I want. The question, is as, always to weigh the benefits vs the costs of doing something.

[Adoby]

Using magnet bittorrents, all that is needed is to publish the magnet hash of the current version. And of course that someone somewhere is seeding the file with this hash. No trackers needed. While the swarm is new download will be slow, but it will soon pick up speed.

I just downloaded calibre-64bit-1.46.0.msi and added it as a new file to my Transmission bittorrent program.

The hash is: 1aa79875d03775afd55875cd7ab195699e30eaaf

And the link is

magnet:?xt=urn:btih:1aa79875d03775afd55875cd7ab195 699e30eaaf&dn=calibre-64bit-1.46.0.msi

You should be able to add this link or just the hash to a magnet aware bittorrent client, and start downloading from my client. I seed with very low bandwidth, and I won't seed more than a few days or so, but it should be proof of concept. Feel free to test and see if you can leach it from me. It can take quite a while before it starts, but it should work. I think...

If many start to leach and share at the same time, everything will go much faster. And many can download the same file and also start seeding it. It will always have the same hash, as long as it is not modified or renamed.

Just an experiment...

[taosaur]

Originally Posted by eschwartz

How would you suggest the update be changed to be easier?

Considering the bandwidth discussion, it may be financially worthwhile to make updates less frequent, less prominent, or both. I was considering bandwidth before and figured that maybe getting the donate button in front of people offset the costs of having the app downloaded and re-downloaded more often than necessary. If fundraising (which I would hardly call a conspiracy) is not the goal, then it might be worth revamping the process to discourage such frequent downloads.

How often people are actually updating, I don't know. Personally, when a program prompts me to update, I tend to assume the developer wants us to download that update. In practice, I only open Calibre once or twice per month on average, anyway. I would guestimate I've downloaded Calibre maybe 15 times in the past year because, "Oh, button! I'll click on it." That's around 800MB downloaded, when in terms of features I probably would have been fine updating once, maybe twice all year.

I'm sure Kovid knows his options. The least disruptive would be to default disable the update dialog--available updates are still displayed on the bottom information bar in Calibre. A step further would be to flag some updates as "recommended" (major bug fix, major feature addition), mark those in red in the main interface, and have the default notification behavior be "recommended updates only," with "all updates" as an additional check box.

Those changes would conserve bandwidth, leave the preference twiddling to power users, and reduce frustration for casual users who want to stay up to date, but don't want update prompts interrupting our workflow nearly every time we open the program.

[AnotherCat]

Originally Posted by taosaur

...In practice, I only open Calibre once or twice per month on average, anyway...

So you are complaining even though you see the update notification, on average, only "once or twice a month"?

[taosaur]

Originally Posted by AnotherCat

So you are complaining even though you see the update notification, on average, only "once or twice a month"?

I'm reporting a user experience. After reading this thread and giving the matter some thought, I'll simply hit "cancel" more often, but keep receiving the notification. It's not how I handle updates for any other Windows application, but it's fine now that I have a better sense of what constitutes an "update" for Calibre. I'm good.

Where Kovid's bandwidth and the broader user experience are concerned, there may be room for improvement. The current scenario is probably sending the wrong message, imparting too much urgency to incremental updates and making the update process a far larger part of the user experience than it needs to be. Every time there's a "How do you use Calibre?" thread, there's a chorus of "I use Calibre to update Calibre, har har har." There are also numerous threads linked earlier about finding ways around the current update options. It may all be a sign that something is out of whack.

[eschwartz]

It is out of whack to use scripting to simulate auto-updates?

(I do that for more than calibe. )