Kobo Start Menu 08

[tshering]

Originally Posted by CH23

welcome
What caused you to initially think it bricked the readers though?

I saw some code in the FW 4.6.10075 that showed that certain devices would not be able to connect via usb, when there is KSM installed. In some situations, not being able to connect to the pc is a serious problem. Finally it turned out, that the code concerns other models than those currently known.

[Ebri]

I have installed .9665, which started and endless boot loop in nickel, which was easily solved by installing the patch. But yesterday I put it onto charger, then this morning when I resterted nickel, the same endless loop of putting and removing boxes started. Yesterday before the charging it worked perfectly. Do you know what might caused this?

Thank you!

[tshering]

Originally Posted by Ebri

I have installed .9665, which started and endless boot loop in nickel, which was easily solved by installing the patch. But yesterday I put it onto charger, then this morning when I resterted nickel, the same endless loop of putting and removing boxes started. Yesterday before the charging it worked perfectly. Do you know what might caused this?

Thank you!

Could you try to start nickel by selecting

• "tools" > "nickel diverse.msh" > "start nickel no fmon.sh"

and see whether this makes a difference?

[Ebri]

Originally Posted by tshering

Could you try to start nickel by selecting

• "tools" > "nickel diverse.msh" > "start nickel no fmon.sh"

and see whether this makes a difference?

I tried it on my own, and was able to boot in, but db seems dead, as it asked for language, login, etc. Then I got an error message, that device is full (there should be no books there, as I put all on SD, 2.8 gigs free on device memory). After connecting to computer it hanged, then after reboot started with fmon breaks the endless loop by returning back to KSM. Seems not perfect yet .

Can it happen that not the mounted, but the root directory is full?

[Ebri]

I updated to 10075, same behaviour, after some box showing drops back to KSM.

But without fmon it works now, and I even didn't lose my reading positions in the books, so I hope it is OK.

So thank you very much, though would be nice if it would work with fmon running.

[tshering]

Originally Posted by Ebri

I updated to 10075, same behaviour, after some box showing drops back to KSM.

But without fmon it works now, and I even didn't lose my reading positions in the books, so I hope it is OK.

So thank you very much, though would be nice if it would work with fmon running.

The function of fmon is that whenever some application opens one of the image files in kbmenupngs, it starts a script that is associated with this image file. The problem is that under certain conditions, nickel opens or tries to open one of these files without being told to do so by the user. It seems to happen after some FW updates, that nickel has to open these image files in order to create new thumbnails or something like that. So the solution, is to start nickel without fmon, and try to let nickel do all the work it needs to do with those image files. You look at these image files in the library, inside of the collection, open them so that they get displayed on the home screen, also the collection if they are in one. You start nickel several times without fmon. After that nickel will work again also when started with fmon. I have to add that this seems not to work for some people (I remember one user). To simplify things you could also delete those image files in kbmenupngs that you will likely never use. I for one could for instance do without simulate_usb_connection.png, switchtokoreader.png, toggle_nightmode.

[davidfor]

Originally Posted by tshering

The function of fmon is that whenever some application opens one of the image files in kbmenupngs, it starts a script that is associated with this image file. The problem is that under certain conditions, nickel opens or tries to open one of these files without being told to do so by the user. It seems to happen after some FW updates, that nickel has to open these image files in order to create new thumbnails or something like that. So the solution, is to start nickel without fmon, and try to let nickel do all the work it needs to do with those image files. You look at these image files in the library, inside of the collection, open them so that they get displayed on the home screen, also the collection if they are in one. You start nickel several times without fmon. After that nickel will work again also when started with fmon. I have to add that this seems not to work for some people (I remember one user). To simplify things you could also delete those image files in kbmenupngs that you will likely never use. I for one could for instance do without simulate_usb_connection.png, switchtokoreader.png, toggle_nightmode.

If the issue is when nickel generates the cover images, then we should be able to generate them. The KoboTouch driver in calibre already has code to create the cover images when sending books. The driver doesn't support sending PNGs to the device. I'm not sure if that can be changed as I don't know what support the rest of calibre has for it. But, the code to generate the cover images and put them in the right place on the device is in the driver. Writing something based on that shouldn't be to hard.

[tshering]

Originally Posted by davidfor

If the issue is when nickel generates the cover images, then we should be able to generate them. The KoboTouch driver in calibre already has code to create the cover images when sending books. The driver doesn't support sending PNGs to the device. I'm not sure if that can be changed as I don't know what support the rest of calibre has for it. But, the code to generate the cover images and put them in the right place on the device is in the driver. Writing something based on that shouldn't be to hard.

This could be helpful for people who use calibre anyway. Once calibre is able to send PNGs to the device, the user would have to resent the concerned PNGs each time before upgrading the FW (or at least before running nickel the first time after upgrading). And the driver would have to know for which FW to create the images. Would this be the way to proceed?

[Ebri]

Thank you for the help, during changing light level I got back again to KSM, so I am unsure how much stable my thing currently. But I will check the PNGs.

[tshering]

Originally Posted by Ebri

Thank you for the help, during changing light level I got back again to KSM, so I am unsure how much stable my thing currently. But I will check the PNGs.

It is difficult to see a relation between the PNGs and nickel stopping to work when you change the light level. Are you saying that you got back from nickel to KSM directly? Or did the device reboot?

[davidfor]

Originally Posted by tshering

This could be helpful for people who use calibre anyway. Once calibre is able to send PNGs to the device, the user would have to resent the concerned PNGs each time before upgrading the FW (or at least before running nickel the first time after upgrading). And the driver would have to know for which FW to create the images. Would this be the way to proceed?

I had a very quick test last night and calibre doesn't really support individual images or sending them to a device. That makes doing anything there a bit more complicated.

But, I was thinking more that part of the fmon install process would be to generate the covers images and put them in place. Thinking about it now, they could just be copied from a working system. The cover images have names that are derived from from the book and its location and is used as a id in the database. That is the same for all firmware version. The location has only two choices. Old firmware used ".kobo/images", newer firmware is under ".koboimages". The exact location for the latter is generated from the id. But, it is the same for all devices and and firmware. The exact size of these images does change, but they don't really matter. The smaller sizes are roughly the same and the full size cover probably won't be used but can be any size. Taking a copy of these file in the correct structure and copying that to the device should work.

[tshering]

Originally Posted by davidfor

I had a very quick test last night and calibre doesn't really support individual images or sending them to a device. That makes doing anything there a bit more complicated.

But, I was thinking more that part of the fmon install process would be to generate the covers images and put them in place. Thinking about it now, they could just be copied from a working system. The cover images have names that are derived from from the book and its location and is used as a id in the database.

This is certainly an alternative to the current install process. Even thought, it seems a little uncomfortable to me.

I wonder why on devices where KSM has been installed at some point and was running for some time without problems, all of a sudden fmon is triggered without the user accessing the relevant PNGs. If I remember correctly, reports of this happening were often related to installing a new FW. And usually (I think there was one exception) visiting the PNGs in the library and opening them, brought everything back to normal.
My attempt to explain this was to assume that under circumstances unknown to me some FWs recreate on some models the covers anew. I was however not able to verify this. On my devices I did not see any covers recreated after a FW update. The most recent file date of an fmon related cover on any of my devices is from February 2015.
There are of course other possible explanations. The user never did the install process completely, but by chance nothing happened for some time. Or the user signed out without afterwards repeating the necessary steps related to fmon. Deleting and adding the PNGs at a later time might also have some effect (I never checked whether nickel removes the covers of deleted books).

[Wolfsbruder]

I have a question. What about using kfmon instead of fmon?

[tshering]

Originally Posted by Wolfsbruder

I have a question. What about using kfmon instead of fmon?

Once the covers are created, there is no difference. The question is why nickel opens the concerned PNGs even though the informations have already been put into the database, and the covers have already been created. That nickel does happen to open the PNGs sometimes in such circumstances, I can only assume from user reports.

[NiLuJe]

Yeah, I do check for the existence of the covers & thumbnails in kfmon, so if the files are already there, it'd *probably* not fare much better. The only additional check is the db being locked, which might save the day (or not, due to the potentially huge timing variances).

But all that's moot anyway if the weird nickel restarting behavior also/still happens under KSM (which is something I think nobody has been brave enough to try, with good reason. If it's broke with only KOReader, I wouldn't even begin to imagine how much worse it could be with KSM ).