[GUI Plugin] Quality Check

[Capricorn]

Ah...I hadn't realised there were two different versions with the same version number.
I have now installed the version 1.14.3 posted by JSWolf (post #1258), and it all works again. Cool. That makes my life a little bit easier, when working on books, as I use this plugin quite a bit.
Thank you for pointing out the differences, and the way forward.

[PeterT]

Originally Posted by JSWolf

Do you think it would be a good idea to get the latest code from the Git and then apply the fix?

I've no idea. Kiwidude never released to MobileRead that version. Again, it's his call

[JimmXinu]

Release Notes
https://github.com/kiwidude68/calibr..._check-v1.14.4

RECOVER_PARSER removed from Calibre, see #131

I've been in touch with kiwidude, he's swamped right now. So I'm putting these fixes up in my capacity as his backup.

Thanks, JSWolf, for stepping up in the interim.

[un_pogaz]

Additionally to this fix release, the previous one who has not been published here (v1.4.3) contains three new feature:
https://github.com/kiwidude68/calibr..._check-v1.14.3

• Added 'Normalize the fields' and 'Normalize the notes' options for merge and reorder diatrics. (#un-pogaz)
• Added 'Fix Author Sort' action. (#un-pogaz)
• Added Actions Chains support. (#un-pogaz)

Else, @JSWolf if I understand your point of view, the one of BetterRed don't come to nowhere either.
So if your publish any hacked version of a plugin in the future, I encourage you to use a exeprimental/preview version number rather that let the official untouched. Like 1.14.3.100. That allow to know that this version is a altered one, and in the same time there is no risk of conflict with the next version when updating in Calibre.

[un_pogaz]

Except that 1.14.4 is the one that include the fix, so our version is absolutly irelevant now. And you don't use experimental version number.

[JimmXinu]

Originally Posted by un_pogaz

Additionally to this fix release, the previous one who has not been published here (v1.4.3) contains three new feature:
https://github.com/kiwidude68/calibr..._check-v1.14.3

• Added 'Normalize the fields' and 'Normalize the notes' options for merge and reorder diatrics. (#un-pogaz)
• Added 'Fix Author Sort' action. (#un-pogaz)
• Added Actions Chains support. (#un-pogaz)

The version I've released as v1.14.4 in the first post is built on kiwidude's v1.14.3. It should have everything from v1.14.3. v1.14.3 was 'released' in github. If it wasn't previously released here, I assume that was an oversight.

Originally Posted by un_pogaz

Else, @JSWolf if I understand your point of view, the one of BetterRed don't come to nowhere either.
So if your publish any hacked version of a plugin in the future, I encourage you to use a exeprimental/preview version number rather that let the official untouched. Like 1.14.3.100. That allow to know that this version is a altered one, and in the same time there is no risk of conflict with the next version when updating in Calibre.

I'm going to strongly recommend against this. The standard plugins is major.minor.micro and stored internally as a list of 3 integer values. Adding a fourth number is outside standard. Unless I missed Kovid blessing that, don't do it.

I also recommend against bumping from v1.14.3 to v1.14.100 as test versions because kiwidude's standard is to increase the micro number for each release. v.1.4.4 would not be called out as a new version if you had v1.14.100 installed.

I could have bumped the new release versions I made to v1.15.0 or v1.14.5 to be higher than JSWolf's versions. I didn't because: a) it's not my repo, so I followed kiwidude's established standard and b) there's no effective difference between (as far as I know) between JSWolf's versions and what I released.

[un_pogaz]

@JimmXinu My recomandation use four numbers: Release, Major, Minor, Experimental
So the fourth number don't interfer with the first three official. Yes, Calibre accept that like fine, there is absolutly no issue since it compare the raw version tupple.
So if you use a hacked version 1.14.3.100, when a official version 1.14.4 will be releasead, the official will overwrite the experimental.

[JimmXinu]

This is also being discussed over here, FYI.

[kiwidude]

@un_pogaz - all your changes would have been included in JimmXinu's build off main. No I never published that release here because immediately after making changes that add new menu items I tend to give the translators a few weeks to do their updates which I can then pickup for the official release build. You were the only person using those changes obviously so there was no "rush" to publicly push it out on the forums from my perspective, anyone who desperately wanted it could grab it from the GitHub releases. Since that time as JimmXinu has said I am snowed with my day job and these plugins are way down the list of priorities. Especially when there is a dead simple workaround - don't sit on the bleeding edge of calibre all the time.

[un_pogaz]

Yeah, I understand all that. I just dumped the changelog of the 1.4.3 to complet the release info of JimmXinu, since apparently your publish a message for every version and change, even minor.
Take good care of you.

[Trester99]

I have a large amount of ebooks, and unfortunately quite a few have two covers. Calibre does have an option to “Remove First image” using the convert process, but since there is no way to identify which books have two covers, I would have to convert all of the files to eliminate the percentage of books that have extra covers. I’ve spent quite a bit of time using Google, without luck.

So my first question is if anyone knows of an alternate method to identify or delete the second cover in the ebooks? My second question, if no one knows of any options, would Quality Check consider adding this feature?

[JSWolf]

Originally Posted by Trester99

I have a large amount of ebooks, and unfortunately quite a few have two covers. Calibre does have an option to “Remove First image” using the convert process, but since there is no way to identify which books have two covers, I would have to convert all of the files to eliminate the percentage of books that have extra covers. I’ve spent quite a bit of time using Google, without luck.

So my first question is if anyone knows of an alternate method to identify or delete the second cover in the ebooks? My second question, if no one knows of any options, would Quality Check consider adding this feature?

The first thing you need to do is to figure out how you can identify the two covers. If you cannot do that, then you'd have to view each book manually in either the editor or the viewer to see which has two covers.

How did you get eBooks with two covers?

[Trester99]

Originally Posted by JSWolf

The first thing you need to do is to figure out how you can identify the two covers. If you cannot do that, then you'd have to view each book manually in either the editor or the viewer to see which has two covers.

How did you get eBooks with two covers?

I've been collecting ebooks for probably close to 30 years, so I do have a lot.

Doing the review manually is just not an option, it would take me forever.

Thanks

[JSWolf]

Originally Posted by Trester99

I've been collecting ebooks for probably close to 30 years, so I do have a lot.

Doing the review manually is just not an option, it would take me forever.

Thanks

There's no other way to do it but manually.