1. General
  2. Bugs
+1
Planned

Java exception on issues containing a decimal

Wesley Howard 9 years ago • updated by Tom 7 years ago • 6
20150330 20:34:29 [Scanner thread] WARN com.ubooquity.b.c - Problem while reading comic metadata for file file: /share/comics/DC Comics/Wonder Woman (2011)/wonder woman 023.1 (2013).cbz
java.lang.NumberFormatException: For input string: "23.1"
at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) ~[na:1.7.0_75]
at java.lang.Integer.parseInt(Integer.java:492) ~[na:1.7.0_75]
at java.lang.Integer.valueOf(Integer.java:582) ~[na:1.7.0_75]
at com.ubooquity.b.c.a(SourceFile:81) ~[Ubooquity.jar:1.7.6]
at com.ubooquity.data.feeder.a.b(SourceFile:499) [Ubooquity.jar:1.7.6]
at com.ubooquity.data.feeder.a.c(SourceFile:458) [Ubooquity.jar:1.7.6]
at com.ubooquity.data.feeder.a.b(SourceFile:39) [Ubooquity.jar:1.7.6]
at com.ubooquity.data.feeder.a$1.run(SourceFile:127) [Ubooquity.jar:1.7.6]
at java.lang.Thread.run(Thread.java:745) [na:1.7.0_75]


fresh install, initial run.
Linux, Ubuntu mix (flawless server 2.0), headless

Comic does appear in the web UI in the correct location for the path, but does not have an issue number with it.

This is a corner case with some DC titles around 2 years into the new 52 affecting just about all the titles. Let me know if you need any more logs etc out of me.
Under review
Tom 9 years ago
Ouch, I made a mistake saving this field as an integer whereas the ComicInfo XSD allowed any string of characters.
The bad news is, a fix will require a full rescan for everybody when it is released.
I have to think about it.

Thanks for pointing it out anyway.
Planned
Tom 9 years ago
Elouan 7 years ago

I have a similar problem: my collection contains many "Hors serie" comics displaying HS in the number field (I scrap metadata from bedetheque). And I get a similar warning in the logs during scanning


If you plan to change the type of this field, in a future release be very careful of the ordering method you will use in that field: 95% of comics have a proper number in that field, and you will want to have 1 ordered before 2 and 2 before 10... if you make a string of this field and use normal ordering then 10 will be after 1 but before 2.... which would be very bad

Alternatively, you could add a new field "Alternate numbering" make it a string and populate it during a scan whenever the current number field is invalid; The current number field is the order in which the item is to be seen: when you have a mix of both in a collection, put the "alternate number" at the end of the number field for example


I don't think you need a full rescan to fix this. You can rescan only books that have an empty number field. You could also add a button when opening the book for a rescan of an individual book. This way the user may go and choose to rescan the book when he made a modification

Tom 7 years ago

Good catch, I'll see what I can do (since the database is unfortunately not capable of natural sorting, which is what I would need here).


As for the full rescan, it will be necessary with the next version anyway (even preferences will be lost).

Elouan 7 years ago

Going back to the subject: As mentionned above, I scrap metada from Bedetheque, and most "Hors Serie" show as "alternate number" which is reflected in comick rack with the <AlternateNumber> tag

for example:

http://www.bedetheque.com/BD-Cites-obscures-H07-Mary-la-penchee-40559.html

the number appears in comcik rack comicinfo.xml as

<AlternateNumber>H07</AlternateNumber>


I don't know if you intend to do something about it, but it wold be a good idea to read the "alternate number" tag when you do a scan; combined with a (normal string) sorting on the field, you might have a solution for sorting a collection

Tom 7 years ago

I now read the alternate series and alternate number fields from the metadata file, and I will display the alternate number when the main one is empty.


As for the sorting, I started working on a "meta key" that would have sorted books by series/volume/number. Then I realized that the resulting order would be the same as sorting by file path 99,9% of the time.

So I'll stick to sorting by file path unless there is a really compelling reason to do otherwise.


(and the number type is fixed)

Customer support service by UserEcho