YACReader beta 8.0

Thank you all for your help! I am finally back (happily back)

@Xukkorz, please send me the files by email, I will check what it is going on with the CPU issue.

Today I am releasing the release candidates of YACReader for iOS 2.0 and YACReader 8.0 for desktops.

@selmf, is the "jpg" bug affecting YACReader 7.2.0 too?

Luis and I discussed the "jpg" issue yesterday and we've found a way to fix it for good. It will need some testing since it is in a sensitive area (the decompression backend), but once we have it right directory names shouldn't be a problem anymore. The bug actually is present in version 7.2 as well, but it does not trigger on "jpg" folders but on ".jpg" folders.

I emailed them to you in a Zip, please let me know if they do not show up.

I noticed a small bug while testing the latest Mac version. While in the Grid view, if you minimize the app to the Dock, then bring it back up, there are no covers displayed in the grid view. If you switch back to the "Cover Flow" style view then they reappear and I can switch back and forth to Grid view without issue. Whenever I minimize in Grid View, they disappear after bring the app back into focus. This does not happen while in Cover flow view.

That is the only issue I've seen so far though. The latest versions for both Mac and iOS appear to work very well, I'm loving the sync feature to keep my reading progress between my desktop and phone, I was missing that for a while.

For almost every 8.0 release (windows 7), I've been getting the bug where it crashes when creating/adding a library, at a certain size. [strike]Before it used to be a couple hundred megabytes, in the latest release it lasts a little longer, perhaps at a few gigs.[strike] I can't create the whole library without it crashing at a certain size (always the same). Was fine with 7.2.0.

Just checked, it stops/crashes at about 19GB. In earlier releases it crashed at around 3-4GB.

Hmpf! You could have told us earlier!

Are you sure you don't have this problem in 7.2? It has a known bug which results in hangups after a certain amount of comics scanned for the library. This was fixed for the 8.0 series...

My current guess is that this is caused by a bad comic in your collection. Could be a problematic pdf or a comic file containing a folder with the same name as a file extension ("jpg", for example). The size should not be the problem. Are you able to resume the library creation (via update library) after the crash or does it crash again right away?

Caulden wrote: For almost every 8.0 release (windows 7), I've been getting the bug where it crashes when creating/adding a library, at a certain size. [strike]Before it used to be a couple hundred megabytes, in the latest release it lasts a little longer, perhaps at a few gigs.[strike] I can't create the whole library without it crashing at a certain size (always the same). Was fine with 7.2.0.

Just checked, it stops/crashes at about 19GB. In earlier releases it crashed at around 3-4GB.

Please, create a library in the folder where it is crashing. And check what was the latest comic added before the crash (you will see the path in the bottom part of the importing view). Then try to open the following comics in that folder using YACReader, one of them will cause an "error opening or format not supported", could you share it with me please?

So I'm not sure if this should be considered a bug or not but if issue numbers are not just numbers it does not properly order them, or at least not the way I would expect it to. For example. The Age of Ultron comics are mostly numbered normally but have some that have letters in the numbers. The appropriate numbering should be ... 8, 9, 10, 10AI. Instead it is sorting 10AI, 1, ..., 9, 10. Again I'm not sure if this is something that can be fixed since its kinda out of the ordinary and probably has to do with the integers ordering different then strings.

EDIT

So I was looking at other odd numbers for issue number, there are for instance issues 10.1 10.2 10.3 and they are not sorting in that order.

Hi Xukkorz,

in my opinion your sorting problem lies somewhere between a minor bug and a feature request. Sorting files the way a human would expect it is tricky and what one human would consider natural another might not. Making it "right" for everyone is tough and I don't think messing around with the sorting system at this stage of the release cycle would be a good idea.
Still, we regularily have been getting feature requests related to the sorting system, in particular for a feature to ignore leading articles in filenames and such stuff in the sorting algorithm. So we sooner or later will have to have a closer look at the sorting code and decide how to implement the features it is currently lacking for our intended use cases. Now, as I said before, this probably won't happen in the current beta, so it probably would be a good idea to move this bug/feature request to a non-beta part of the forum so it doesn't get lost

Regards,

selmf

Xukkorz wrote: So I'm not sure if this should be considered a bug or not but if issue numbers are not just numbers it does not properly order them, or at least not the way I would expect it to. For example. The Age of Ultron comics are mostly numbered normally but have some that have letters in the numbers. The appropriate numbering should be ... 8, 9, 10, 10AI. Instead it is sorting 10AI, 1, ..., 9, 10. Again I'm not sure if this is something that can be fixed since its kinda out of the ordinary and probably has to do with the integers ordering different then strings.

EDIT

So I was looking at other odd numbers for issue number, there are for instance issues 10.1 10.2 10.3 and they are not sorting in that order.

There is a tag for this in YACReaderLibrary, "bis". for example, if you have an issue between 10 an 11, you have a "10 bis". The number should be 10 and the check box "bis" should be checked.

But, this will not cover all the possible combinations. For complex sorting, you can use a reading list (in 8.0) or don't use issue comic numbers, just the name for sorting. In a future, a new field should be required for adding extra sorting capabilities to YACReaderLibray.