Touch .kepub.epub

[paola]

Originally Posted by davidfor

It will affect it in the same way that it affect the main plugin. Both have an option to support newer firmware, so just check that for the driver you are using. I have made the changes to the main plugin and they should be in the next calibre release. After that, there won't be a problem for either plugins. Unless one of us break some code.

Unfortunately, I have just remembered there might not be a calibre release this week. Kovid said he was going to be away and might not be able to do the release this week.

thank you!

[BobC]

Originally Posted by davidfor

It will affect it in the same way that it affect the main plugin. Both have an option to support newer firmware, so just check that for the driver you are using. I have made the changes to the main plugin and they should be in the next calibre release. After that, there won't be a problem for either plugins. Unless one of us break some code.

Windows XP, Glo 2.50 Calibre 0.9.27
There is something odd since the 2.50 update - what I am now finding is that with the extended driver in place once Calibre detects the Glo it initially communicates with it sufficiently to read the metadata on the device and show just what books are on it. If you then try to transfer books it fails.

I did have "Support Newer Versions" selected.

The nasty bit though is that once it has done that if you try to use file manager to connect to the USB drives (E & F in my case) it can't do so, although the drives are still visible. Checking in Device Manager shows the two Kobo 2.50 Devices "working correctly" but if you try to populate the Volume information it cannot recognise the drive format. Everything behaved properly until I started Calibre and it detected the Glo.

With the Kobo drivers disabled in Calibre it is possible to Connect/Share to the USB drives on the Glo without breaking anything.

I've restarted both XP and the Kobo a couple of times but still no improvement.

This may mean something to davidfor or jgoguen - I can't call it a bug as I'm using 2.50. which wasn't what the drivers were intended for.

BobC

[davidfor]

Originally Posted by BobC

Windows XP, Glo 2.50 Calibre 0.9.27
There is something odd since the 2.50 update - what I am now finding is that with the extended driver in place once Calibre detects the Glo it initially communicates with it sufficiently to read the metadata on the device and show just what books are on it. If you then try to transfer books it fails.

Was there an error message, and if so what? Does the same thing happen if you disable the extended driver and only use the main one? Do the first books get copied over?

I did have "Support Newer Versions" selected.

The nasty bit though is that once it has done that if you try to use file manager to connect to the USB drives (E & F in my case) it can't do so, although the drives are still visible. Checking in Device Manager shows the two Kobo 2.50 Devices "working correctly" but if you try to populate the Volume information it cannot recognise the drive format. Everything behaved properly until I started Calibre and it detected the Glo.

With the Kobo drivers disabled in Calibre it is possible to Connect/Share to the USB drives on the Glo without breaking anything.

What happens if you try to copy books to the device without starting calibre?

I've restarted both XP and the Kobo a couple of times but still no improvement.

This may mean something to davidfor or jgoguen - I can't call it a bug as I'm using 2.50. which wasn't what the drivers were intended for.

This isn't a worry. The drivers are looking at the database to check it hasn't changed more than it can handle. The changes in 2.5.0 are outside the area the driver uses. And the "fix" to the driver is simply increasing a number to match that in the database. But, in this case there is extra code to handle cover images and the SD card.

[BobC]

Originally Posted by davidfor

Was there an error message, and if so what? Does the same thing happen if you disable the extended driver and only use the main one? Do the first books get copied over?


What happens if you try to copy books to the device without starting calibre?


This isn't a worry. The drivers are looking at the database to check it hasn't changed more than it can handle. The changes in 2.5.0 are outside the area the driver uses. And the "fix" to the driver is simply increasing a number to match that in the database. But, in this case there is extra code to handle cover images and the SD card.

I've just run some further checks and this is what I found :

1) Without Calibre loaded I can copy to and from the device with no problem.

2) With Calibre loaded but both the Kobo Touch and the Extended drivers disabled I can see and copy to the Glo using it as a connected folder.

3) With just the Kobo Touch Driver loaded (not the extended one) Calibre will detect the Glo (it refers to it as a Touch) and goes through three steps sucessfully :

Get Device Information
Get List of Books on device
Send Metadata to Device.

Once this happens I can no longer use file manager to inspect the E or F drives.

If I then try to delete a book from the Glo using Calibre it fails with the following error :

calibre, version 0.9.27
ERROR: Error: Error communicating with device

unable to open database file

Traceback (most recent call last):
  File "site-packages\calibre\gui2\device.py", line 85, in run
  File "site-packages\calibre\gui2\device.py", line 575, in _delete_books
  File "site-packages\calibre\devices\kobo\driver.py", line 450, in delete_books
  File "site-packages\calibre\devices\kobo\driver.py", line 1779, in delete_via_sql
  File "site-packages\calibre\devices\kobo\driver.py", line 362, in delete_via_sql
OperationalError: unable to open database file

The book is not deleted,

Trying to copy a book TO the Glo fails with the following error :

calibre, version 0.9.27
ERROR: Error: Error communicating with device

(2, 'GetDiskFreeSpace', 'The system cannot find the file specified.')

Traceback (most recent call last):
  File "site-packages\calibre\gui2\device.py", line 85, in run
  File "site-packages\calibre\gui2\device.py", line 551, in _upload_books
  File "site-packages\calibre\devices\kobo\driver.py", line 1740, in upload_books
  File "site-packages\calibre\devices\usbms\driver.py", line 256, in upload_books
  File "site-packages\calibre\devices\usbms\device.py", line 986, in _sanity_check
  File "site-packages\calibre\devices\usbms\device.py", line 177, in free_space
  File "site-packages\calibre\devices\usbms\device.py", line 134, in _windows_space
error: (2, 'GetDiskFreeSpace', 'The system cannot find the file specified.')

The book is not copied.

If I go into XP Device manager and look at the device it shows it as a functioning drive but of Type Unknown and Status Unreadable.

The problem is not (only) with the extended driver and only occurs once the standard Calibre driver has established contact with the Glo. If I close Calibre the problem does not disappear until I eject and re-connect the Glo.

It looks like this needs a new thread as this is not directly related to the .kepub.epub issue though unless there is some way of using jgoguen's driver to write a kepub.epub to a local drive it means I can't work round it by simply transferring files by O.S. copying.

BobC

[jgoguen]

My driver piggybacks on the hard work done by davidfor and those who came before him on the mainline Kobo driver. I simply modify the contents of the books and then hand them off to the mainline driver to handle the upload. I don't really see the value in adding the ability to copy kepubs to an arbitrary drive, but if a respectable number of people want it I would see what I could do. Honestly though I think it would be useless outside of the relatively rare occasion when a firmware update changes the database version, which is something that each of us (mostly davidfor, I don't really touch the database aside from setting image IDs) will address in our own code once we have a chance to look at the new database and see what changes to make.

[BobC]

Originally Posted by jgoguen

My driver piggybacks on the hard work done by davidfor and those who came before him on the mainline Kobo driver. I simply modify the contents of the books and then hand them off to the mainline driver to handle the upload. ..... but if a respectable number of people want it I would see what I could do. ......

I really wasn't asking for any change to the way the plugin works, I just wondered if it was possible to locate a copy of the kepubified book in temporary files or similar (though thinking about it as conversion is triggered by transfer to the device and any attempt to communicate with it fails after the initial synch that wouldn't work). At present I have no way of putting kepub versions of books onto my Glo as it looks like the 2.50 update has some low-level incompatibility with the Kobo driver itself. I can copy standard epubs without using Calibre so having access to a kepub versions would have been useful as a work-round. I'm surprised no-one else has hit this problem -it's pretty fundamental to the interaction between Calibre and the Kobo. I think I need to investigate things like my AV software (AVG) to see if that is why I'm suffering and no-one else seems to be.

BobC

[jgoguen]

The Kobo firmware 2.5.0 update has increased the database version beyond what the driver is coded to trust as "safe for modification". I believe davidfor has checked his DB code and found is safe, but that won't be updated until the next calibre release. My plugin is also safe, so I've increased the minimum DB version in the current version as well.

[davidfor]

@BobC: I don't know what is happening for you. Both my Glo and Touch have FW2.5.0 and have no problems when I select the ignore firmware check option. And several others have reported it is working with no problems.

But, I have seen reports of similar problems in the past. A lot of them turned out to be problem with the computer or cable. A damaged cable will do this. Port problems as well. And it might work with another computer. If this is the case, I don't know why it happened with the upgrade to the new firmware.

Another possibility is a problem with the filesystem. Doing a scan of the filesystem might find a problem. It could also be a problem in the database. Checking that might reveal something. Or opening it with a SQLite browser might trigger the same problem. If it is a database problem, then a log out and back in will probably fix it. Or at worse a factory reset.

I don't know how much any of that will help, but it is all I can think of at the moment.

[PeterT]

What happens if you load Kobo Desktop; does it have any issues with the device?

[BobC]

@PeterT
No problem with the Kobo desktop - it seems to work fine.

@davidfor
I've tried it on another USB port without any improvement, without Calibre loaded I can load the database over USB into a SQLite browser and examine the tables (I'm not going to modify them as that might seriously screw things up).

Filesystem scan didn't throw up any errors.

It seems clear that "something happens" after the initial communication between the Touch driver and the Kobo which then makes the drives allocated to the device invisible to the O.S. - Device Manager can see the hardware but not any drives associated with it. The same goes for Computer Management's Logical Disk Manager which, prior to the Calibre connection shows both drives as Healthy FAT32.

Everything worked fine before the 2.50 upgrade.

I noticed that with 2.50 the ProductID for the Kobo was upped from 4163 to 4173 and instead of being simply having a device name of "eReader" it became "eReader-2.5.0" though USBDeview shows them as otherwise the same.

I see Joel's Extended Driver has been updated so I enabled that to check if there is any improvement but no, nothing has changed there (I don't know if that would help though until the basic driver has been updated).

It looks like I need to revert to 2.4 to see if the problem then goes away or if the update was just a co-incidence. - I think the fact that I can happily communicate with the Kobo for as long as I want until the Touch Driver comes into play does rule out any hardware issues (ports, cables etc).

Thanks both for the ideas though.

BobC

[jgoguen]

You said you have a Glo? Product ID 4163 is the Touch's product ID, the Glo has product ID 4173. The Mini is 4183.

[BobC]

@jgoguen - I was looking at USBDeview and as you say the current device is shown as 4173 and it is definitely a Glo. I have never had a Touch.

There was another entry shown by USBDeview for a Kobo Product ID of 4163 and I had assumed that was the earlier version (i.e. 2.4) but may have been a version prior to that. I have now deleted the 4163 entry from the Registry and am relying on my memory.

As I have never had a Touch I can only guess that an earlier version of the Glo showed up in this way. It's no big issue - I purged the reference to it in case it was causing problems.

Unfortunately the Registry gets clogged up with old device data which shouldn't cause a problem but when everything else fails ..........

BobC

[davidfor]

Originally Posted by BobC

@PeterT
No problem with the Kobo desktop - it seems to work fine.

@davidfor
I've tried it on another USB port without any improvement, without Calibre loaded I can load the database over USB into a SQLite browser and examine the tables (I'm not going to modify them as that might seriously screw things up).

Can you run "PRAGMA integrity_check" against the database? This will check if there are any problems with the database.

Filesystem scan didn't throw up any errors.

It seems clear that "something happens" after the initial communication between the Touch driver and the Kobo which then makes the drives allocated to the device invisible to the O.S. - Device Manager can see the hardware but not any drives associated with it. The same goes for Computer Management's Logical Disk Manager which, prior to the Calibre connection shows both drives as Healthy FAT32.

Yes, but what is the problem.

Everything worked fine before the 2.50 upgrade.

I noticed that with 2.50 the ProductID for the Kobo was upped from 4163 to 4173 and instead of being simply having a device name of "eReader" it became "eReader-2.5.0" though USBDeview shows them as otherwise the same.

I sure hope the ProductID didn't change. x4173 is the id for the Glo. If you had x4163 before, then that is very strange.

Since 2.3.1 I think, the device name has included the firmware version.

I see Joel's Extended Driver has been updated so I enabled that to check if there is any improvement but no, nothing has changed there (I don't know if that would help though until the basic driver has been updated).

That is correct. Most of Joel's driver is changing the file. The base driver and calibre do the file copies any changes to the database. But, the update to the base driver isn't going to change anything. The only changes are an update in the firmware version numbers and management of cover images on the SD card. There haven't been any changes that could affect this for at least a month.

It looks like I need to revert to 2.4 to see if the problem then goes away or if the update was just a co-incidence. - I think the fact that I can happily communicate with the Kobo for as long as I want until the Touch Driver comes into play does rule out any hardware issues (ports, cables etc).

You could take a copy of the database. Then log out on the device and get a new one when it restarts. Then see if the communications with calibre still breaks. If it doesn't, then it was a database problem. If the problem is still there, you can restore the copy of the database and try downgrading the firmware.

[BobC]

Originally Posted by davidfor

Can you run "PRAGMA integrity_check" against the database? This will check if there are any problems with the database.

I ran this with no errors reported

Yes, but what is the problem.

I can only characterise it as loss of connection between the Glo and my XP machine (when Calibre connects via the Touch driver)

I sure hope the ProductID didn't change. x4173 is the id for the Glo. If you had x4163 before, then that is very strange.

I think I explained this in my reply to Joel.

Since 2.3.1 I think, the device name has included the firmware version.

I suspect the issue here is an old registry entry.

That is correct. Most of Joel's driver is changing the file. The base driver and calibre do the file copies any changes to the database. But, the update to the base driver isn't going to change anything. The only changes are an update in the firmware version numbers and management of cover images on the SD card. There haven't been any changes that could affect this for at least a month.

Thanks for the info it might help me eliminate some issues.

You could take a copy of the database. Then log out on the device and get a new one when it restarts. Then see if the communications with calibre still breaks. If it doesn't, then it was a database problem. If the problem is still there, you can restore the copy of the database and try downgrading the firmware.

I had decided to do a factory reset on the Kobo as I was coming to the conclusion that the problem was at that end. Before I did that though I was able to duplicate the problem without using Calibre. I used SQLite to access the database on the Kobo and then compacted the database. When it came to save the database the problem occurred - i.e the drive on the Kobo became invisible to my O.S. This now confirms my suspicion that the problem is at the Kobo end rather than the Windows/Calibre end.

I'll do a factory reset then update directly to 2.50 and see what happens.

Again, thanks for the help.

BobC

[tshering]

My Touch had always a very unstable USB connection to my XP laptop. I had for instance to load every FW update by Wifi or by sideloading it, because the USB connection always broke when I tried to update via the desktop. Even sideloading was sometimes difficult or even impossible (then I had to use my Windows 7 net book).
I get always problems if I try to copy a huge file or a rather huge amount of files in one go to the Touch.
Somebody on this forum recommended to change the USB connection from speed to reliability.