[frllop]

Any luck with the file I sent? I'm very sorry to say that I had another instance of Black Page today... Now with language set to English (so using the Norwegian translation was definitely not to blame), and on 1.4.4 (so all the work you have done with potential rendering bugs still doesn't seem to have resolved this issue...).
Using the suggested remedy of changing to Night mode and back with a corner action did indeed bring the page back, but cost precious seconds..
Anyone else using the Samsung Note Pro with Android 5? I don't really want to start experimenting with downgrading the OS to Android 4, but I realize it may be "the only thing" left to try, if no other solution suddenly reveals itself...

I had the same problem with Samsung Note Pro with Android 5 two times some time ago...

[Steinway]

That's really interesting! Strengthens the theory that Android 5 is to blame, at least in combination with the Note Pro.. Skip, you also mentioned earlier that you had experienced this a while ago - any chance that you are also on Android 5? I'm seriously beginning to consider a downgrade..

[Zubersoft]

I guess I'll have to go back to the drawing board. I have the Samsung Note Pro running 5.0.2 as well, so I'll start doing all of the testing on it to see if I can reproduce the problem.

[Skip]

Steinway:
I'm still on 4.4, never upgraded 'cause there were too many problems being reported.

[Steinway]

Continuing to think about this, I suddenly realized there seems to be a certain pattern to where the black page appears.. The last three times I have seen this, the black page has always been one of the first four or five pages of a song. If the first pages render correctly, and I continue turning just one page at a time, the rest of the song always seems to work fine. Also, in the instances where I have seen the black page after using the page slider, the black page has always been (I believe) one of the first four or five pages after using the slider. In other words, as far as I can tell, the error seems to occur either upon the initial loading of the song (when all the first pages are loaded into memory) or after changing the page so several new pages has to be loaded at once. Does this make any sense?

[Steinway]

Hmm, I guess that's yet another theory that didn't survive for long.. I now skipped to page 10 with the page slider, turned forwards a page at a time from there, and page 16 didn't render. As far as I know, that's further ahead than the pages which would be loaded into memory upon skipping to page 10..?

I know you said earlier that you could make some kind of regular check to see if any page didn't render, but that you didn't want to because you'd rather find and correct the problem itself. As it is, however, the problem is there (for me at least), and it doesn't seem we are getting any nearer to finding a solution..

So would it be possible to add, as a temporary solution, some kind of check when turning to the next page, to verify that the next page has indeed been rendered - and then to automatically reload the page in the unlikely event that it hasn't? I don't know whether that would be possible, but at least it would let me sleep better at night..

[Zubersoft]

My code already does that. Every time you turn a page, it goes through and checks if any page needs to be rendered. The problem is that if a page is in the process of rendering, but never does render and no cancellation or failure is generated anywhere (i.e. a deadlock of some kind would do this), it would cause my framework to fail. There should be no way in which a page could enter that state but then never exit it, but apparently that is somehow happening for you. The kind of check I was talking about adding was a check that says, "If it has been more than 10-20 seconds since a page entered the rendering state but still isn't rendered, then forcefully cancel that job and queue it up to render again". This is a major kludge though, and should never be necessary, and adds some nasty failure cases if a particular PDF takes a long time to render some of the pages. For example, if 11 pages are queued to render, and each page takes 3 seconds, that 11th page may not start rendering until 30 seconds have gone by, which would be considered a failure with that new check.

I'm currently on vacation, but when I get back home at the end of the week, I'm going to start testing heavily with my Samsung Note Pro 12.2 to see if I can reproduce this error. If you are seeing it this regularly, I should eventually see it myself. I'm going to do everything I can to fix this, and will consider it my highest priority.

Thanks,
Mike

[Steinway]

Thank you! I really appreciate all the work you're putting into this, and I'm confident that you'll find a solution eventually!

By the way, wouldn't a page in the process of rendering always be shown as a blank page with a spinning circle, even if it were stuck in an endless loop somehow, and never actually would finish the rendering? I have (extremely rarely) had a page with an eternal spinning circle, which didn't render until I turned a few pages back and then tried again. With my dreaded black pages, however, there's no spinning circle or any indication at all that it is in the process of rendering (or trying to, and failing). There's simply an instant black page, as if it never even tried to load the page.. 

Note though: If there are any annotations on the failed page, however, they are actually displayed correctly (on the blackness).

[Zubersoft]

You are correct - if the page was in the process of rendering but never did, you would see the spinning circle. I didn't realize all you saw was a black screen (a lot of people say black screen when talking about the screen with the progress indicator). The fact that nothing but black is shown is something entirely different. This means either the image that is being generated is all black (which would be extremely unusual), or something is failing while the page is going through the layout phase (the phase where the container object positions each page on the screen). For example, I know that if I provide bogus page size values to the PDF renderer (if I pass a size of -1, -1), a completely black page will be generated. Likewise, if some incorrect values were being used during the layout phase, the page could be shown off the screen and the black background would be the only thing shown. Both of these things shouldn't happen during normal operation, but something must be occurring to cause issues such as the tablet generating low memory warnings (to which my application responds by trying to free up as much as possible by clearing out cached pages and even reducing the number of rendered pages if the warnings are severe).

Based on what you told me, I now realize I've been looking in the wrong place for answers to this problem. I'm really hoping that I can reproduce this problem on my Samsung Note Pro 12.2, as I've never seen it on my Nexus 7, Nexus 10, or Samsung Galaxy Tab 2.

Thanks,
Mike

[frllop]

For me was the same: no spinning circle or any indication. There's simply an instant black page. I don't remember if I had annotations on that page...
Thanks Mike!

[Zubersoft]

After turning through thousands of pages, I still can't reproduce this issue on my samsung note pro 12.2. Perhaps I need to test with one of your libraries? If either of you wants to upload either PDFs that have exhibited this problem or library backups, I'd be happy to keep testing, but I'm not sure what to do now.,

Mike

[Steinway]

Thank you so much anyway, for all the testing you have gone through to solve this issue!
I did e-mail you one of the files that have exhibited the problem, did you test with that one?
Anyway, I'd just like to mention that I haven't had a single black page since my last post (11 days ago), and I've also turned through literally thousands of pages in that time. So I guess this is a tough problem to reproduce.. Also, out of fear that it might happen again (really busy playing season coming up, with exams and recitals almost daily..), I've finally decided to downgrade my Note Pro to Android 4.4.2. Downgraded without any problems yesterday, everything works fine until now at least. I'll let you know if a black page turns up again, but I'm crossing my fingers that the downgrade will have solved the problems for me at least..

[Zubersoft]

I believe I may have located the cause of this issue (and the issue described here http://zubersoft.com/mobilesheets/forum/...p?tid=3383). Certain conditions can trigger requests from the Android OS for my app to release some memory (like if it's in the background or the device is almost out of RAM). In response to those requests, I free up resources, but some of those may be actively in use. I believe this creates a situation in which pages can not render or be rendered incorrectly. I'm certainly seeing this while trying to print large PDFs. I'm going to be changing the code to either safely free up resources, or just not free them at all to ensure that the program can never enter a bad state.

Mike

[Steinway]

Thank you! This does indeed sound like a real breakthrough! Eagerly awaiting the update. Maybe I'll even upgrade the OS again..

[frllop]

Thank you!