Error with QDoubleSpinBox

[Sabardeyn]

Most likely this is user error as I am presently screwing around with a sample database, trying to establish a viable database, layout, etc.

Anyway, I created a custom column and marked it as a series and subgrouped. Apparently this presented calibre with a problem. Trying to edit metadata, I got the following:


IN THE BOOK LIST
calibre, version 0.9.14
ERROR: Unhandled exception: <b>TypeError</b>:QDoubleSpinBox.setValue(float): argument 1 has unexpected type 'unicode'

Traceback (most recent call last):
File "site-packages\calibre\gui2\actions\edit_metadata.py", line 208, in edit_metadata
File "site-packages\calibre\gui2\actions\edit_metadata.py", line 228, in do_edit_metadata
File "site-packages\calibre\gui2\metadata\single.py", line 1008, in edit_metadata
File "site-packages\calibre\gui2\metadata\single.py", line 501, in start
File "site-packages\calibre\gui2\metadata\single.py", line 538, in do_one
File "site-packages\calibre\gui2\metadata\single.py", line 288, in __call__
File "site-packages\calibre\gui2\custom_column_widgets.py", line 389, in initialize
TypeError: QDoubleSpinBox.setValue(float): argument 1 has unexpected type 'unicode'

The error above would not allow me to enter the Edit Metadata screen for the problem book.


EDIT METADATA (SINGLE) FOR ANOTHER BOOK & PREV/NEXT TO TARGET BOOK
calibre, version 0.9.14
ERROR: Unhandled exception: <b>TypeError</b>:QDoubleSpinBox.setValue(float): argument 1 has unexpected type 'unicode'

Traceback (most recent call last):
File "site-packages\calibre\gui2\metadata\single.py", line 514, in prev_clicked
File "site-packages\calibre\gui2\metadata\single.py", line 538, in do_one
File "site-packages\calibre\gui2\metadata\single.py", line 288, in __call__
File "site-packages\calibre\gui2\custom_column_widgets.py", line 389, in initialize
TypeError: QDoubleSpinBox.setValue(float): argument 1 has unexpected type 'unicode'

The error above would allow me to get into the Edit Metadata screen for the problem book.


Once I altered the data in that custom field to remove the subgroup (ex: GROUP.SUBGROUP changed to GROUP) and saved it, calibre stopped throwing the error message for that book. Checking several books without a subgrouping in that custom column were fine. I could edit metadata without incident.

I noticed this error starting in 9.11 (I think) but I updated to the current version in case this was a known and corrected problem. On WinXP Pro SP3.

I know this should probably be in the bug tracker, but I'm not exactly sure what to call this. Assuming it's a bug and not user error.

[chaley]

I can't reproduce this problem.

What I tried:
- Made a custom series column hierarchical using preferences -> look & feel -> tag browser

then:
- edit a book with no value in the column. No problem.
- edit a book with a value in the column. No problem.
- change a value in the column to contain a period. No problem.

Is there any chance that you changed the lookup name of an existing custom column to one that existed sometime in the past? That can create difficulties.

[Sabardeyn]

As I said it might well be user error. I will try to create a new sample database and recreate the problem on my end in the next couple of days.

I was working with custom columns in the 9.14 instance; specifically "advanced formatting" per manual for conditional printing of fields & prefix/suffix. Which did display very different than expected.

The earlier 9.11 testing,I cannot recall, but it is possible.

[Sabardeyn]

I've been trying to recreate this problem, but I'm not getting the error message in a new database. I can still get errors from the original (problem) database.

I know I removed a #customseries_index, but not the #customseries, from a composite column. Thinking back, the books throwing the errors from the original message were books that all had fields filled with sample data - including the now missing #customseries_index.

[chaley]

Originally Posted by Sabardeyn

I've been trying to recreate this problem, but I'm not getting the error message in a new database. I can still get errors from the original (problem) database.

I know I removed a #customseries_index, but not the #customseries, from a composite column. Thinking back, the books throwing the errors from the original message were books that all had fields filled with sample data - including the now missing #customseries_index.

Thanks for taking the time to try to find a reproducible scenario.

The problem could possibly be related to a bug that I fixed a week ago that caused the series index for custom series columns to occasionally be empty. It would happen if you used bulk edit to set a custom series but not the custom series index. It would display as [1] but actually be null (None).

To test the theory, try running this search on the original database.

#customseries:true and #customseries_index:false

If this finds books that raise the exception, then the fixed bug is likely the culprit. You should be able to select all the books and use bulk edit to set #customseries_index to a known value then see if the problem goes away.

[Sabardeyn]

I just went back to the original database, with the errors. I performed the search, altering the column name, cycling through each of my real custom column's names. I got back 26 responses for one custom column (#universe), but none of the books shown were the titles that caused the error.

I also tried to edit the metadata on the 26 books. The Edit Metadata screen appeared without throwing an error at all. Perhaps, since I'm now using 9.14 and that should include the fix you mentioned, maybe calibre is handling things internally properly? So these "new" errors are not occuring, but the old ones exist in the database already, thus the continuing complaints?

Would your fix require previously "damaged" entries to be corrected manually, or would the correction be done in some automated fashion?



BTW, I think I found another error with composite columns and series/series_index. But one error at a time.

[chaley]

Originally Posted by Sabardeyn

I just went back to the original database, with the errors. I performed the search, altering the column name, cycling through each of my real custom column's names. I got back 26 responses for one custom column (#universe), but none of the books shown were the titles that caused the error.

I also tried to edit the metadata on the 26 books. The Edit Metadata screen appeared without throwing an error at all. Perhaps, since I'm now using 9.14 and that should include the fix you mentioned, maybe calibre is handling things internally properly? So these "new" errors are not occuring, but the old ones exist in the database already, thus the continuing complaints?

Your experiment indicates that the bug probably has nothing to do with your current problem. The fix was to ensure that the value of a custom series index is set to 1 when the series is applied to a book. It is later changed to what the user specified, assuming something was specified. This is the same behavior as the standard series.

Would your fix require previously "damaged" entries to be corrected manually, or would the correction be done in some automated fashion?

The entries need to be corrected manually. The fix ensures that no new ones will be made. The errors are corrected by editing the custom series.

BTW, I think I found another error with composite columns and series/series_index. But one error at a time.

Ohhhh, I can hardly wait.

[Sabardeyn]

First Error
Alright. Suggestions on what to do next to identify and resolve the original error? Should I just send you a copy of the database without any formats attached? The metadata.db file is only 635 Kb. There are still two book entries that suffer from the error, so whatever is going on is still available for testing. (Even if I've gotten into the Edit Metadata for those two books, I've cancelled out to leave them available for testing.)


Second Error
Initial notice of strangeness: Composite column output displayed incorrectly in v9.11.

Repeatable steps:I started a new database completely from scratch (ie, Switch database>Create new> happens if copy structure Y or N, v9.14).

Created 6 series-like custom columns. I used similar names at first (ser1, ser2). Later I created an entirely new database and tried dissimilar names (in case variable names were only unique to the Nth letter position - as programming languages of old used to suffer from this problem). Problem occurs with either naming scheme.

Create one composite column, like tags, shows in tag browser. Set the template to:

{#ser1:|| }{#ser1_index:| [|],  }{#ser2}{#ser2_index:| [|],  }{#ser3:|| }{#ser3_index:| [|],  }{#ser4}{#ser4_index:| [|],  }{#ser5:|| }{#ser5_index:| [|],  }{#ser6}{#ser6_index:| [|] }

For the sake of ease, I created a single empty book, with dummy info. Specifically, the #ser columns were filled with text count (first, second...) and each index was given a matching numeric index value (1, 2...).

Saving metadata, the book list is updated and the composite column shows the following, incorrect order:

Fifth [5], First [1], Fourth [4], Second [2], Sixth [6], Third [3]

Note that if an Edit Template is done at this point from the Book List, the template and template value appears correct:

First [1], Second [2], Third [3], Fourth [4], Fifth [5], Sixth [6]

However, returning to the Book List, the composite column is still displaying the column information out of order.

[chaley]

Originally Posted by Sabardeyn

First Error
Alright. Suggestions on what to do next to identify and resolve the original error? Should I just send you a copy of the database without any formats attached? The metadata.db file is only 635 Kb. There are still two book entries that suffer from the error, so whatever is going on is still available for testing. (Even if I've gotten into the Edit Metadata for those two books, I've cancelled out to leave them available for testing.)

Sure, send me the metadata.db file. Be sure to tell me which book(s) are still broken. Send it to [calibre2 @ charles dot haleys dot org].

Second Error
Initial notice of strangeness: Composite column output displayed incorrectly in v9.11.

... [CLIP]

Create one composite column, like tags, shows in tag browser.

... [CLIP]

Saving metadata, the book list is updated and the composite column shows the following, incorrect order:

Fifth [5], First [1], Fourth [4], Second [2], Sixth [6], Third [3]

This is by design. Telling calibre that the composite column is to behave like tags means that every comma-separated item is independent of the others. Calibre sorts them in alphabetical order. There is no way to make them dependent on the position in the template other than to choose names that sort in the order you wish. This is the same behavior as the tags column; display order is alphabetic regardless of entry order.

Are you sure you want to use "like tags"?

[Sabardeyn]

I've sent out the email with the file attached.

As to whether I must use the data "like tags", ultimately I'm not sure if I will implement things in that manner. As I said I'm kind of messing around with calibre to find out what I can do and how I can do it - optimally for my needs.

Prior efforts met with varying degrees of customization and satisfaction. Some of the issues being shifts in data handling methodology (fields vs tags), file structure (yeah, that old saw!). Another being the amount of manual effort required to get good info into the database. I've started from scratch a couple of times because I just wasn't happy with either the database or my results.

The primary issues at present are nested series and tags to normalize data as much as possible. Well, that and the data entry required.

[chaley]

Originally Posted by Sabardeyn

First Error
Alright. Suggestions on what to do next to identify and resolve the original error? Should I just send you a copy of the database without any formats attached? The metadata.db file is only 635 Kb. There are still two book entries that suffer from the error, so whatever is going on is still available for testing. (Even if I've gotten into the Edit Metadata for those two books, I've cancelled out to leave them available for testing.)

Got the metadata.db file. The problem is another manifestation of the bug I mentioned before. This time it was getting the empty string instead of "None", which caused the error.

The workaround is to fix the series index, which is most easily done by editing the cell directly on the spreadsheet and pressing return. The problem can exist if the GUI displays a (custom) series index of 1, but indices not equal 1 will have the problem.

I am submitting a fix to calibre that does this automatically when you edit metadata. It should be released on Friday.

[Sabardeyn]

Glad to know that there was a legitimate issue here and not just user error. I appreciate you taking the time to answer my concerns and look at the database to determine what was going on.

Thanks also for letting me know how to fix the database. While I wasn't too worried about repairing it (since it was a sample database), I might as well "recover" as much manual input/effort as possible.