MobileRead Forums - View Single Post

davidfor · 05-14-2017, 06:28 AM

@Kovid:

I have had a problem with the collections displayed in the device list for some time. Occasionally, they wouldn't show. Unplugging the device and plugging it back in would fix it. Because of that, I haven't been bothered about it. But, I've had a couple of reports recently about problems with collections, including a report that when Metadata management was set to automatic, the collections weren't showing. So, I've had a better look at it.

I found a problem in the KoboTouch driver that caused of the problems when the collection management was turned off or there were no collection columns. After fixing that, there were still issues.

The problem is most obvious when there is no metadata.calibre file on the device. So, the second time the device is connected, everything is OK.

The problem is that something is clearing the "device_collections" attribute between the "Get list of books on device" and "Send metadata to device" jobs. I tracked it down to where the metadata from the device is merged with that from the library. This is in gui2/device.py in method "update_book". That calls ebooks/metadata/books/base.py, Metadata:smartupdate. This is called with "replace_metadata=True".

The problem is that smartupdate with that options sets some attributes to None if they are not in the source object. The list of attributes to be treated this way includes "device_collections". As the source object is coming from the database, "device_collections" won't be in the source object and hence will be set to None.

The fix I have is to add "device_collections" to the list SC_FIELDS_COPY_NOT_NULL in ebooks/metadata/book/__init__.py. With that, all the cases I have tested, the collections are displayed correctly.

Searching through the code, I don't think that this will cause a problem. I do not have any non-Kobo devices to test with, so, I can't prove it that way. And, of course, I might have missed something in the code.

05-14-2017, 06:28 AM	#1
davidfor Grand Sorcerer Posts: 24,907 Karma: 47303748 Join Date: Jul 2011 Location: Sydney, Australia Device: Kobo:Touch,Glo, AuraH2O, GloHD,AuraONE, ClaraHD, Libra H2O; tolinoepos	Problem with Metadata smart_update @Kovid: I have had a problem with the collections displayed in the device list for some time. Occasionally, they wouldn't show. Unplugging the device and plugging it back in would fix it. Because of that, I haven't been bothered about it. But, I've had a couple of reports recently about problems with collections, including a report that when Metadata management was set to automatic, the collections weren't showing. So, I've had a better look at it. I found a problem in the KoboTouch driver that caused of the problems when the collection management was turned off or there were no collection columns. After fixing that, there were still issues. The problem is most obvious when there is no metadata.calibre file on the device. So, the second time the device is connected, everything is OK. The problem is that something is clearing the "device_collections" attribute between the "Get list of books on device" and "Send metadata to device" jobs. I tracked it down to where the metadata from the device is merged with that from the library. This is in gui2/device.py in method "update_book". That calls ebooks/metadata/books/base.py, Metadata:smartupdate. This is called with "replace_metadata=True". The problem is that smartupdate with that options sets some attributes to None if they are not in the source object. The list of attributes to be treated this way includes "device_collections". As the source object is coming from the database, "device_collections" won't be in the source object and hence will be set to None. The fix I have is to add "device_collections" to the list SC_FIELDS_COPY_NOT_NULL in ebooks/metadata/book/__init__.py. With that, all the cases I have tested, the collections are displayed correctly. Searching through the code, I don't think that this will cause a problem. I do not have any non-Kobo devices to test with, so, I can't prove it that way. And, of course, I might have missed something in the code.