[GUI Plugin] FanFictionDownLoader

[JimmXinu]

Version 1.6.0 - 27 Jul 2012
Options now stored inside the Library rather than an external JSON file.

[cryzed]

Jimm, something I have noticed recently: When I update a FanFiction.Net story and check on the same day for updates again FanFictionDownLoader will not recognize that the story has already been updated (and attempt to do it again) -- this only stops when the updated date differs from the current date, i.e. 1+ days later. Is there a different method to check if a story needs updating?

[JimmXinu]

Originally Posted by cryzed

Jimm, something I have noticed recently: When I update a FanFiction.Net story and check on the same day for updates again FanFictionDownLoader will not recognize that the story has already been updated (and attempt to do it again) -- this only stops when the updated date differs from the current date, i.e. 1+ days later. Is there a different method to check if a story needs updating?

The behavior you describe is what 'Overwrite if Newer' does. None of the sites give update timestamps, just dates. The site is considered 'newer' if it's still the same day in case there has been more than one update in the same day. It also illustrates another reason not to use the FFDL to poll for updates.

'Update EPUB if New Chapters' says it right in the name: it updates if there's new (more) chapters than the existing EPUB. This is the most efficient method, since it only downloads new chapters, but it only works with EPUB.

[cryzed]

Ah all aright. On an unrelated note, I just managed to reverse-engineer the part of the *.mbp files that store the metadata for a *.mobi file on the Kindle, it's now possible for me to keep the location (last page read) when replacing or updating the *.mobi file. I'm not sure how hard it would be to implement that into FFDL, but if you feel up to it, say so and I'll post the required information here.

[seabream]

A bit under a couple of weeks ago, somewhere around 1.5.43, FFDL would pull Favs, Follows, and id from FF.net. I found this useful. Is there a way for me to turn this back on in personal.ini, or somewhere? I wouldn't necessarily want to store them in general tags, I'd probably put them in custom columns if they had classifications that I could shunt appropriately. I tried adding the line "include_subject_tags: extratags, genre, category, status, characters, favs, follows, id," under defaults already.

Thanks in advance (and for work already done).

[JimmXinu]

Originally Posted by seabream

A bit under a couple of weeks ago, somewhere around 1.5.43, FFDL would pull Favs, Follows, and id from FF.net.

That was a bug, actually.

Originally Posted by seabream

I found this useful. Is there a way for me to turn this back on in personal.ini, or somewhere?

You can get id from Story ID (custom column) or storyId (include_subject_tags). The standard calibre column Identifiers already has the full URL, though.

I don't foresee adding Favs & Follows to the metadata anytime soon, but I'll add them to the list with Reviews on the wishlist of 'maybe someday' features.

[JimmXinu]

Originally Posted by cryzed

Ah all aright. On an unrelated note, I just managed to reverse-engineer the part of the *.mbp files that store the metadata for a *.mobi file on the Kindle, it's now possible for me to keep the location (last page read) when replacing or updating the *.mobi file. I'm not sure how hard it would be to implement that into FFDL, but if you feel up to it, say so and I'll post the required information here.

The .mbp file on the Kindle? I can take a look at your info, but I'm not sure what FFDL could do with it--calibre doesn't have that file available and even if FFDL wrote it, would calibre send it to the device?

[cryzed]

@JimmXinu, I actually went ahead and implemented it myself because it was something I really wanted to see for a long time. It also works flawlessly on my end, so for courageous people I'll attach it below. There was no easy and obvious way for it to work like I wanted, so I had to implement it as a device plugin that monkey-patches the built-in "Kindle 2/3/4/Touch Device Interface".

There should be no problems when Calibre updates, as long as there are no not-backwards compatible changes to the API.

To install it first disconnect your Kindle, disable the built-in "Kindle 2/3/4/Touch Device Interface" plugin in the "Device Interface plugins" section and then install my mod. After that simply restart Calibre.

Here is the code for anyone curious. As I said, I'm not responsible for any damages that it might cause -- I can just state that it works on my end.

And to clarify again: Using this simply allows you to keep your current reading location along with other metadata when you update a story with FFDL while using a Kindle or somehow else cause its UID to change. For example you are reading a story called "XYZ" and are currently at location ABC. Now usually when you would update the story with FFDL your current location would be reset, your highlights would disappear etc. -- using this they don't.

[iatheia]

This is very nice, but, wouldn't it make more sense not to integrate it into FFDL, but rather create a separate plug-in, so it would work for all mobi files upon sending to the device, including those from epub conversion?

[cryzed]

That is currently the case, it is not integrated into FFDL and it should work exactly as you just described. I suggested integrating it into FFDL before I had read up on the Calibre plugin structure and now realize that this would be rather hard, keeping it like this ought to be ideal.

If the modification is popular enough I might consider creating an extra thread.

[iatheia]

I mean if you were to release an actual plugin for it, something to load into calibre and use without modification or compilation on the user part.

[JimmXinu]

@cryzed - I think it's a good idea. And I think we all agree now, it's not something FFDL should (or even can) do.

I suggest you submit a patch to the built-in "Kindle 2/3/4/Touch Device Interface" plugin to do this. I bet they'd incorporate it in calibre directly.

[cryzed]

Maybe I am misunderstanding you, but: The attached *.zip file below my post is exactly that, an "actual plugin" -- the user doesn't need to modify anything, he simply needs to deactivate the built-in Kindle device interface and use mine. My plugin is written in such a way that it doesn't get outdated and always has the exact same features as the built-in plugin, even if it is updated.

[cryzed]

@Jimm, I will create a thread then and collect some feedback and hope that David or another contributor stumbles upon it for now.

[iatheia]

That is accessible to everyone who is browsing plugins on Calibre directly, and not just people who are browsing completely random thread 40+ pages in =)

But Jim's suggestion is better, ignore me.