Problem with viewing many images...

[Avenger]

I received my digital reader today. I've been using it with manga as was discussed in the previous thread. Everything works well but there is a problem which was alluded to by a member of the Irex forums. If you page flip through enough images, the memory will run out and the UDS viewer process (which I believe what it is called) slows down until it crashes. It doesn't matter how many images are in a folder. Because it happens when you switch folders with a fewer number of images in them. It just looks like the viewer never releases the memory. Is there any way to kill the UDS process when I want (like during a break between reading chapters) so the slowdown and the crash doesn't occur? I pressed the home button on the main menu and closed the documents in the task manager but that doesn't seem to be enough to free the memory. Anything else I can try short of having to reboot after every chapter I read to make sure the memory is freed?

Thanks in advance for your help! The device does seem very good but I may have to return it if there isn't a work around.

[Grimulkan]

Have you tried closing your document after every chapter or so, instead of choosing "return to folder" and navigating to the next bunch of images? Usually, when you close the last document, the UDS releases memory (and if you're running out of memory, it looks likes it does it only then). This is what I do, and I've never seen this bug. Its shouldn't be a problem at all, just close the UDS when you are done with the document.

[Avenger]

I tried doing this twice. It usually craps out after about 2 chapters of the particular manga I am looking at even after closing after every chapter. The images are quite large (around 300k PNG or JPG files) which is why it probably happens faster for me. I would guess if they were smaller, it would happen after a larger number of page changes.

[Grimulkan]

Strange, how many page turns do you reckon it takes to mess things up? I'll try to duplicate it.

[Avenger]

Not too many About 50-75 on these files.

[Avenger]

btw is there any other way to pack the images to view on the DRS1000S? Does it make sense to put them in a pdf file and try it or will that just lead to an unwieldy mess to read? I've seen some scripts for other e-readers while browsing through the forum.

Only other thing I was thinking if there was a way to run a script that does a "ps -ef", greps the UDS process id and kills it? I know this device runs some varient of Linux but don't know if you can kill a process in this manner.

If anyone else reads manga a different way on this device, let me know. This seems like a great device (I love the touch screen and the folders). I have a Kindle DX on order and can try that if this doesn't work out but I know the lack of folders and touch screen will annoy me. It also seems the page refresh is a good deal faster on the Digital Reader as well (at least compared to a kindle 2 and a sony) The Kindles have a picture viewer that isn't documented but hopefully won't be left out of the DX version.

[Grimulkan]

Originally Posted by Avenger

btw is there any other way to pack the images to view on the DRS1000S? Does it make sense to put them in a pdf file and try it or will that just lead to an unwieldy mess to read? I've seen some scripts for other e-readers while browsing through the forum.

You can always pack them into a PDF. For example, ImageMagick has several command line tools to process images and then pack them into a PDF. If you have the full version of Adobe Acrobat, packing images into a PDF is only a right click away. I don't know if this will solve the problem, give it a shot. PDFs are also slower than raw images.

A clunky alternative is to use <img> tags to point to images from a HTML file, and then open it in FBReader. You can then shut down FBReader in case there is a memory leak. You will need to get the image size, margins etc. right in the HTML file though. I find this a little cumbersome, but its faster than the UDS if you manage it.

I haven't had a chance to try and replicate your bug. If the above options don't work, wait for someone to come up with a CBR viewer. I've been working on one for a while now, but my attention has been sidelined by several more interesting projects This just reminded me to get back to it.

Originally Posted by Avenger

[...] Only other thing I was thinking if there was a way to run a script that does a "ps -ef", greps the UDS process id and kills it? I know this device runs some varient of Linux but don't know if you can kill a process in this manner.

Great idea! Put this in a .sh script and try it before trying anything else. This works on the emulator, btw, so it should probably work on the DR as well. You'll need to create a .desktop shortcut pointing to the .sh file. Open an existing .desktop file in a text editor if you are unfamiliar with this, the tags are pretty straightforward. There is a detailed explanation in the iRex developer documentation [PDF].

If MackX gets the terminal port working, you can directly use that. For now, you can also use Leafpad to enter bash commands into a script file (say test.sh), create another script to run the script you created (say run-test.sh), and create a .desktop shortcut to run-test.sh (can be done on your computer or also in Leafpad). You can then redirect your output to a file, and then open that file in Leafpad when done. Described here (courtesy scotsman).

[Grimulkan]

Originally Posted by Avenger

Not too many About 50-75 on these files.

I just flipped through 150 images, all in the same folder, each about 700KB. No trouble, and I didn't even shut down the UDS. I flipped through the pages quickly, without giving the power management or the pre-caching algorithm time to act, so maybe one of those is the culprit.

Try reproducing the error after disabling automatic power management under settings. If that fixes it, it is yet another bug (the other being the "landscape tearing bug") introduced by the new power management in 1.6, and would explain why an avid comic reader like me never came across this before (I haven't read comics on 1.6 yet).

If not, perhaps its the pre-caching algorithm. I ended up permanently locking my right side capacitive buttons (why did you use cap sensors, iRex, why!!?) while doing the above, so I'll figure that one out and then try while flipping pages slowly.

[Grimulkan]

Okay, I'm using 1.6 with power management turned on and just read a 80 pages of the above comic without any issues at all. I was plugged in to my computer via USB and I waited about 20-40 seconds between page turns this time. I'll update this post after trying the same while not plugged in.

Update: Continued reading 80 more pages in the same fashion but without being plugged in, and I still have no trouble. Perhaps the problem lies with your specific DR, or the image format? Mine were standard .jpegs. Can you replicate the error if all pages are in the same folder? Maybe the memory leaks occur when you open/close documents. Beyond that, I'm stumped

Note: Another change I had made is that I had modified my /apps/er/sys/power/sec_suspend value to 3 seconds in dr1000.ini in the System folder on my SD card. I don't even know if the DR looks at this value in 1.6, so I doubt it made any difference. Also, in case you're still stumped, how about trying to install 1.5 to see if the bug persists? Re-installing 1.6?

[Avenger]

Grim, thanks for your help. I went and systematically duplicated what you did. I first turned off power management but still had the problem. Next I tried using jpg's instead of png's and still had the problem. However what I did next was to dump all the png's into one folder. That worked! No hanging even on 140 page turns. I then went through a book with chapters by just going to the previous folder and not using "Close Document". That seemed to work too but I will do some more testing to make sure. So at this moment it seems that the "close document" and switching to different folders caused the problem. I'll update later if I see any other issues.

Again many thanks for trying to duplicate the issue!

[Grimulkan]

Good job on tracking down the bug BTW, your kill process idea should take care of even that.

[Avenger]

One thing that happenned to me once is that a sensor locked up. The LED stayed green even though everything else was functional (other sensors and touch). I had to reset to get the sensor right again. Does this happen once in a while? Other than that, I paged through another large bunch of images without any problems. It seems that there can be a delay with jpgs (probably because of the compression) where as png's fly by.

[Grimulkan]

Originally Posted by Avenger

One thing that happenned to me once is that a sensor locked up. The LED stayed green even though everything else was functional (other sensors and touch). I had to reset to get the sensor right again. Does this happen once in a while? Other than that, I paged through another large bunch of images without any problems. It seems that there can be a delay with jpgs (probably because of the compression) where as png's fly by.

Yup, the sensor lockup is something that happens about once in 3 days for me with 1.6, it didn't happen in 1.5. Even a shutdown sometimes doesn't help, you need to reset the device.

Good to know that pngs are faster.