I read all of my articles in chronological order, so I scroll down to
the oldest unread article and continue upwards. Lately, as I scroll
down, I notice that seemingly random articles are already marked as
"read" even though the online version of Google reader says it is not
(and in fact, I have not read the articles). They do not seem to be
associated with a specific feed....
I'm not sure what version of NewsRob I'm running... is there a way to
check? I can't seem to find it in settings...
Very strange. You are the first person I hear that from.
Could you please do a Clear Cache and see if it happens again. And please
upgrade to 3.2.1. You can see that when you start NewsRob in the status bar
on top of the first screen, the dashboard..
On Thu, Oct 8, 2009 at 7:49 PM, yao <master...@gmail.com> wrote:
> I read all of my articles in chronological order, so I scroll down to
> the oldest unread article and continue upwards. Lately, as I scroll
> down, I notice that seemingly random articles are already marked as
> "read" even though the online version of Google reader says it is not
> (and in fact, I have not read the articles). They do not seem to be
> associated with a specific feed....
> I'm not sure what version of NewsRob I'm running... is there a way to
> check? I can't seem to find it in settings...
i have the same issue. In my case i cleared cache before installing
the last version (before 3.2.1), but had this issue since. Every now
and then there is an article marked as read, even tough i haven't read
it.
I can't find a structure behind this bug...seems to be very random.
bye,
shahpur
On 8 Okt., 20:07, Mariano Kamp <mariano.k...@gmail.com> wrote:
> Very strange. You are the first person I hear that from.
> Could you please do a Clear Cache and see if it happens again. And please
> upgrade to 3.2.1. You can see that when you start NewsRob in the status bar
> on top of the first screen, the dashboard..
> On Thu, Oct 8, 2009 at 7:49 PM, yao <master...@gmail.com> wrote:
> > I read all of my articles in chronological order, so I scroll down to
> > the oldest unread article and continue upwards. Lately, as I scroll
> > down, I notice that seemingly random articles are already marked as
> > "read" even though the online version of Google reader says it is not
> > (and in fact, I have not read the articles). They do not seem to be
> > associated with a specific feed....
> > I'm not sure what version of NewsRob I'm running... is there a way to
> > check? I can't seem to find it in settings...
Hmmh... That sounds really tricky and hard to get to the bottom of it. It
would be much easier if articles accidentally stay unread or get unread
again, but accidentally get read is strange.
Do you guys both have sync intervals > 30 minutes?
Unfortunately I didn't get any response about the bug report from above. I
can go back (once again) to using SAX to parse the reading list from Google
Reader. This will work around the continuation bug.
I could also give you a special built version without the incremental sync.
Maybe something is wrong there.
...
The articles you see that should be unread, could you be very specific about
the details? Could make sure a sync has just been run and make a screenshot
of the device (article list please) and the Google Reader web interface.
Let me do the SAX thing first. It will take a bit of time, but it would help
to give NewsRob a flatter memory profile and for this reason is on my TODO
list anyway.
On Fri, Oct 9, 2009 at 11:42 AM, Shahpur <shahpur.azizp...@gmail.com> wrote:
> Hi,
> i have the same issue. In my case i cleared cache before installing
> the last version (before 3.2.1), but had this issue since. Every now
> and then there is an article marked as read, even tough i haven't read
> it.
> I can't find a structure behind this bug...seems to be very random.
> bye,
> shahpur
> On 8 Okt., 20:07, Mariano Kamp <mariano.k...@gmail.com> wrote:
> > Very strange. You are the first person I hear that from.
> > Could you please do a Clear Cache and see if it happens again. And please
> > upgrade to 3.2.1. You can see that when you start NewsRob in the status
> bar
> > on top of the first screen, the dashboard..
> > On Thu, Oct 8, 2009 at 7:49 PM, yao <master...@gmail.com> wrote:
> > > I read all of my articles in chronological order, so I scroll down to
> > > the oldest unread article and continue upwards. Lately, as I scroll
> > > down, I notice that seemingly random articles are already marked as
> > > "read" even though the online version of Google reader says it is not
> > > (and in fact, I have not read the articles). They do not seem to be
> > > associated with a specific feed....
> > > I'm not sure what version of NewsRob I'm running... is there a way to
> > > check? I can't seem to find it in settings...
> Do you guys both have sync intervals > 30 minutes?
actually i have disabled auto-sync, and use locale to start the
newsrob sync twice a day. In every sync there are about 300 articles
to be downloaded.
> The articles you see that should be unread, could you be very specific about
> the details? Could make sure a sync has just been run and make a screenshot
> of the device (article list please) and the Google Reader web interface.
Yes, i will see if i can find any structure (like if this happens only
for feed downloads or only webpage downloads etc..). Next time this
happens i will make a screenshot.
> Let me do the SAX thing first. It will take a bit of time, but it would help
> to give NewsRob a flatter memory profile and for this reason is on my TODO
> list anyway.
> On Fri, Oct 9, 2009 at 11:42 AM, Shahpur <shahpur.azizp...@gmail.com> wrote:
> > Hi,
> > i have the same issue. In my case i cleared cache before installing
> > the last version (before 3.2.1), but had this issue since. Every now
> > and then there is an article marked as read, even tough i haven't read
> > it.
> > I can't find a structure behind this bug...seems to be very random.
> > bye,
> > shahpur
> > On 8 Okt., 20:07, Mariano Kamp <mariano.k...@gmail.com> wrote:
> > > Very strange. You are the first person I hear that from.
> > > Could you please do a Clear Cache and see if it happens again. And please
> > > upgrade to 3.2.1. You can see that when you start NewsRob in the status
> > bar
> > > on top of the first screen, the dashboard..
> > > On Thu, Oct 8, 2009 at 7:49 PM, yao <master...@gmail.com> wrote:
> > > > I read all of my articles in chronological order, so I scroll down to
> > > > the oldest unread article and continue upwards. Lately, as I scroll
> > > > down, I notice that seemingly random articles are already marked as
> > > > "read" even though the online version of Google reader says it is not
> > > > (and in fact, I have not read the articles). They do not seem to be
> > > > associated with a specific feed....
> > > > I'm not sure what version of NewsRob I'm running... is there a way to
> > > > check? I can't seem to find it in settings...
> > Do you guys both have sync intervals > 30 minutes?
> actually i have disabled auto-sync, and use locale to start the > newsrob sync twice a day. In every sync there are about 300 articles > to be downloaded.
> That's what I was after. If the sync interval (manual or automatic) is
longer than 30 minutes, than it will most certainly yield regularly more than 20 articles and therefore I would use continuations with the Google Reader API which appear to be broken. Still, I am not sure how articles would accidentally be marked as read.
Meanwhile I made the transition to SAX parsing again and as I went there from DOM it is a completely different style, completely different control structures. It took me sometime to do that and it might still be buggy. There are no known bugs left at the moment, but I will let it mature another day on my device. Afterwards, let' try with the new version. I'll send another message when I publish the new version.
> The articles you see that should be unread, could you be very specific > about > > the details? Could make sure a sync has just been run and make a > screenshot > > of the device (article list please) and the Google Reader web interface.
> Yes, i will see if i can find any structure (like if this happens only > for feed downloads or only webpage downloads etc..). Next time this > happens i will make a screenshot.
Thanks. I meanwhile suspect an issue with the GR API or the way that I interpret it, but let's revisit that when the change from above didn't work. We would then shutdown incremental syncing to see if that is the cause.
Ok so on the last update (414 articles) i had no article which was
marked as read.
But i had about 16 articles which weren't downloaded at all. Seems
like in this cases only the headers have been downloaded, but no
default content. Is there an internal time slot which will cause the
download to end for an article if it takes too long? Otherwise i don't
know why the content for 15 articles hasn't been downloaded.
The articles are from different feeds.
bye,
shahpur
On 12 Okt., 15:18, Shahpur <shahpur.azizp...@gmail.com> wrote:
Only the content of unread articles will be downloaded.
Does this explain what you see?
Just to prevent misunderstandings. I make the semantic distinction between
download (content) and fetch (the article itself). Do you use the same
terminology?
No, the download time is not limited per se, but I have a timeout for the
sockets. I think I set it to 45 seconds.
----
I am meanwhile sure that the incremental sync is broken: http://tr.im/nr322
Not sure what this means. Either I didn't understand the concept behind the
new GR API changes or it's broken.
I just released a version with the incremental sync being disabled, but
included a switch in the preferences to turn it back on.
On Mon, Oct 12, 2009 at 5:46 PM, Shahpur <shahpur.azizp...@gmail.com> wrote:
> Ok so on the last update (414 articles) i had no article which was
> marked as read.
> But i had about 16 articles which weren't downloaded at all. Seems
> like in this cases only the headers have been downloaded, but no
> default content. Is there an internal time slot which will cause the
> download to end for an article if it takes too long? Otherwise i don't
> know why the content for 15 articles hasn't been downloaded.
> Only the content of unread articles will be downloaded.
> Does this explain what you see?
> Just to prevent misunderstandings. I make the semantic distinction between
> download (content) and fetch (the article itself). Do you use the same
> terminology?
> No, the download time is not limited per se, but I have a timeout for the
> sockets. I think I set it to 45 seconds.
> ----
> I am meanwhile sure that the incremental sync is broken: http://tr.im/nr322
> Not sure what this means. Either I didn't understand the concept behind the
> new GR API changes or it's broken.
> I just released a version with the incremental sync being disabled, but
> included a switch in the preferences to turn it back on.
> On Mon, Oct 12, 2009 at 5:46 PM, Shahpur <shahpur.azizp...@gmail.com> wrote:
> > Ok so on the last update (414 articles) i had no article which was
> > marked as read.
> > But i had about 16 articles which weren't downloaded at all. Seems
> > like in this cases only the headers have been downloaded, but no
> > default content. Is there an internal time slot which will cause the
> > download to end for an article if it takes too long? Otherwise i don't
> > know why the content for 15 articles hasn't been downloaded.
What happens when you hit refresh? Are those articles downloaded during the
next sync? They should. All articles with a light gray download indicator,
other than the ones that have a hollow circle (headers only) and the ones
with a red dot (unrecoverable error during download), NewsRob will try to
download again with each subsequent sync.
So why didn't NewsRob download them in the first place. This is a bit hard
to say exactly without a special log, that you need to enable, but the
generic reason is that NewsRob got interrupted.
This maybe because you hit "Cancel", turned off the phone, removed the
battery etc., or because the process was killed by the OS. This happens when
NewsRob is not in the foreground (so it's a background app) and other apps
with a higher importance (foreground apps e.g.) need more memory. The OS
kills background processes then.
On Mon, Oct 12, 2009 at 8:37 PM, Shahpur <shahpur.azizp...@gmail.com> wrote:
> Hi,
> Well read articles are marked normally, but in this case i dont see
> the yellow marker in the list.
> I can only see that there is a bunch of articles which is not
> downloaded at all since the indicator circle Is greyed out.
> Im using your Terminology when im talking about 'download'.
> On 12 Okt., 19:24, Mariano Kamp <mariano.k...@gmail.com> wrote:
> > Only the content of unread articles will be downloaded.
> > Does this explain what you see?
> > Just to prevent misunderstandings. I make the semantic distinction
> between
> > download (content) and fetch (the article itself). Do you use the same
> > terminology?
> > No, the download time is not limited per se, but I have a timeout for the
> > sockets. I think I set it to 45 seconds.
> > ----
> > I am meanwhile sure that the incremental sync is broken:
> http://tr.im/nr322
> > Not sure what this means. Either I didn't understand the concept behind
> the
> > new GR API changes or it's broken.
> > I just released a version with the incremental sync being disabled, but
> > included a switch in the preferences to turn it back on.
> > On Mon, Oct 12, 2009 at 5:46 PM, Shahpur <shahpur.azizp...@gmail.com>
> wrote:
> > > Ok so on the last update (414 articles) i had no article which was
> > > marked as read.
> > > But i had about 16 articles which weren't downloaded at all. Seems
> > > like in this cases only the headers have been downloaded, but no
> > > default content. Is there an internal time slot which will cause the
> > > download to end for an article if it takes too long? Otherwise i don't
> > > know why the content for 15 articles hasn't been downloaded.
i'm using the newest newsrob version for a few days now and disabled
incremental sync. That solved the issue of new articles being marked
as read.
I'm using an htc hero with android 1.5, and i'm using a taskmanager
(advanced task manager) where i have added newsrob to the ignore list.
That means the newsrob process shouldn't be killed by the os.
But articles not being downloaded happens only rarely, therefore it's
not a big issue for me.
On another note: Would it be possible to justify the text on the
articles when zooming in? currently zooming in results in some nasty
line breaks.
bye,
shahpur
On 12 Okt., 20:52, Mariano Kamp <mariano.k...@gmail.com> wrote:
> What happens when you hit refresh? Are those articles downloaded during the
> next sync? They should. All articles with a light gray download indicator,
> other than the ones that have a hollow circle (headers only) and the ones
> with a red dot (unrecoverable error during download), NewsRob will try to
> download again with each subsequent sync.
> So why didn't NewsRob download them in the first place. This is a bit hard
> to say exactly without a special log, that you need to enable, but the
> generic reason is that NewsRob got interrupted.
> This maybe because you hit "Cancel", turned off the phone, removed the
> battery etc., or because the process was killed by the OS. This happens when
> NewsRob is not in the foreground (so it's a background app) and other apps
> with a higher importance (foreground apps e.g.) need more memory. The OS
> kills background processes then.
> What Android version are you using? 1.6?
> On Mon, Oct 12, 2009 at 8:37 PM, Shahpur <shahpur.azizp...@gmail.com> wrote:
> > Hi,
> > Well read articles are marked normally, but in this case i dont see
> > the yellow marker in the list.
> > I can only see that there is a bunch of articles which is not
> > downloaded at all since the indicator circle Is greyed out.
> > Im using your Terminology when im talking about 'download'.
> > On 12 Okt., 19:24, Mariano Kamp <mariano.k...@gmail.com> wrote:
> > > Only the content of unread articles will be downloaded.
> > > Does this explain what you see?
> > > Just to prevent misunderstandings. I make the semantic distinction
> > between
> > > download (content) and fetch (the article itself). Do you use the same
> > > terminology?
> > > No, the download time is not limited per se, but I have a timeout for the
> > > sockets. I think I set it to 45 seconds.
> > > ----
> > > I am meanwhile sure that the incremental sync is broken:
> >http://tr.im/nr322
> > > Not sure what this means. Either I didn't understand the concept behind
> > the
> > > new GR API changes or it's broken.
> > > I just released a version with the incremental sync being disabled, but
> > > included a switch in the preferences to turn it back on.
> > > On Mon, Oct 12, 2009 at 5:46 PM, Shahpur <shahpur.azizp...@gmail.com>
> > wrote:
> > > > Ok so on the last update (414 articles) i had no article which was
> > > > marked as read.
> > > > But i had about 16 articles which weren't downloaded at all. Seems
> > > > like in this cases only the headers have been downloaded, but no
> > > > default content. Is there an internal time slot which will cause the
> > > > download to end for an article if it takes too long? Otherwise i don't
> > > > know why the content for 15 articles hasn't been downloaded.
i'm using the newest newsrob version for a few days now and disabled
> incremental sync. That solved the issue of new articles being marked > as read.
Yes, it's a meanwhile known bug with the incremental bug and fixed in 3.2.5 which I will post as an alpha tonight.
I'm using an htc hero with android 1.5, and i'm using a taskmanager
> (advanced task manager) where i have added newsrob to the ignore list. > That means the newsrob process shouldn't be killed by the os.
From what you write I would say it means that the task manager doesn't kill NewsRob, but the OS still can, right?
You can read up on the whole killing think in the NewsRob mailing list archives. I had a lengthy discussion with Mark on that topic.
> But articles not being downloaded happens only rarely, therefore it's > not a big issue for me.
If you not prove you need to enable logging in NewsRob (see the a.m. discussion), but if you're happy this way, then that's even better.
> On another note: Would it be possible to justify the text on the > articles when zooming in? currently zooming in results in some nasty > line breaks.
No, not to my knowledge. I use the embedded WebView.
Why do you need that? Do you have feeds that for some articles need zooming and for others don't? NewsRob memorizes the zoom settings you used on that feed and that view (web or feed). So there shouldn't be a need to regularly use the zoom button (and I don't), if you don't have feeds that have inconsistent font sizes or the like, no?
> Yes, it's a meanwhile known bug with the incremental bug and fixed in 3.2.5
> which I will post as an alpha tonight.
oh good to know. I will be trying that out!
> From what you write I would say it means that the task manager doesn't kill
> NewsRob, but the OS still can, right?
Yes, i think you are right.
> No, not to my knowledge. I use the embedded WebView.
> Why do you need that? Do you have feeds that for some articles need zooming
> and for others don't?
no, thats not the problem.
> NewsRob memorizes the zoom settings you used on that feed and that view (web
> or feed). So there shouldn't be a need to regularly use the zoom button (and
> I don't), if you don't have feeds that have inconsistent font sizes or the
> like, no?
Yes the zoom settings are kept, but thats not what im talking about.
Let me explain:
For some feeds i use a more zoomed in view (bigger text) because the
default view is just too tiny. But many articles get bad line breaks,
let me give you an example:
Default (tiny view) Feed:
The new NewsRob version has been released finally. Now it's END of
DISPLAY
possible to use incremental sync to speed up things. END
of DISPLAY
(the physical display space is used completely to show the content of
the article)
Zoomed in view:
The new END Of Display
News END Of Display
Rob version END Of Display
has been END Of Display
released finally END Of Display
"End of display" means that this is the physical edge of the display
on my hero. After zooming in you will have a lot of "empty" areas on
your display.
So if you have a feed where the default view is too small (mostly for
webpage downloads), and you zoom in, you'll get nasty linebreaks
resulting in a very reading unfriendly formatting.
Browsers like opera or the HTC Browser automatically "Justify" the
content when zooming in. That way you have a much better readability,
especially with long articles.
I can post a screenshot tomorrow, i'm at work know and have no access
to android sdk. But a screenshot would explain my problem very
easily ;)
> > Yes, it's a meanwhile known bug with the incremental bug and fixed in > 3.2.5 > > which I will post as an alpha tonight.
> oh good to know. I will be trying that out!
It's out. Please do.
> From what you write I would say it means that the task manager doesn't > kill > > NewsRob, but the OS still can, right?
> Yes, i think you are right.
Do you use Android 1.5 or 1.6?
> Yes the zoom settings are kept, but thats not what im talking about. > Let me explain:
> For some feeds i use a more zoomed in view (bigger text) because the > default view is just too tiny. But many articles get bad line breaks, > [..] > So if you have a feed where the default view is too small (mostly for > webpage downloads), and you zoom in, you'll get nasty linebreaks > resulting in a very reading unfriendly formatting. > [..] > I can post a screenshot tomorrow, i'm at work know and have no access > to android sdk. But a screenshot would explain my problem very > easily ;)
A screenshot would certainly help me to understand the issue better, but I think I get the drift and unfortunately there is nothing I can do at least nothing that I am aware of. The way you describe it, I don't see how it should be differently. When there is not enough space for a word on the same line it needs to be wrapped. What happens when you use the built-in browser (use NewsRob "Show in Browser") and zoom to the same level. If that is different, then please give me screenshots.
> A screenshot would certainly help me to understand the issue better, but I
> think I get the drift and unfortunately there is nothing I can do at least
> nothing that I am aware of.
> The way you describe it, I don't see how it should be differently. When
I was thinking that justifiying the text would help (in making it
easier for the eye), but i'm not so sure anymore...
> there is not enough space for a word on the same line it needs to be
> wrapped.
> What happens when you use the built-in browser (use NewsRob "Show in
> Browser") and zoom to the same level.
> If that is different, then please give me screenshots.
i tried it with the HTC Browser, and the results were the same. So it
seems like my memory tricked me ;) I was sure that the browser would
justify the text, but it doesn't. So newsrob is working exactly like
the browser does.
Do you think it makes sense to provide a zoom slider for newsrob?
Because many times i have the case that the default view is a LITTLE
bit to small to read, but zooming in to the next level is a LITTLE bit
too large. Therefore having the ability to zoom by percentage or
slider would help getting the exact font size i would like to have
(readable but not too big). Especially when downloading webpages you
have quite big differences in default text size, and the pre-set zoom
levels are sometimes not fitting.
On Oct 16, 2009 10:22 AM, "Shahpur" <shahpur.azizp...@gmail.com> wrote:
> It's out. Please do.
Just started testing ;)
> Do you use Android 1.5 or 1.6?
Android 1.5
> A screenshot would certainly help me to understand the issue better, but I > think I get the drif...
I was thinking that justifiying the text would help (in making it easier for the eye), but i'm not so sure anymore...
> there is not enough space for a word on the same line it needs to be >
wrapped. > What happens wh... i tried it with the HTC Browser, and the results were the same. So it seems like my memory tricked me ;) I was sure that the browser would justify the text, but it doesn't. So newsrob is working exactly like the browser does.
Do you think it makes sense to provide a zoom slider for newsrob? Because many times i have the case that the default view is a LITTLE bit to small to read, but zooming in to the next level is a LITTLE bit too large. Therefore having the ability to zoom by percentage or slider would help getting the exact font size i would like to have (readable but not too big). Especially when downloading webpages you have quite big differences in default text size, and the pre-set zoom levels are sometimes not fitting.
--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subs...
I was wondering why some articles weren't downloaded (I guess the process was killed) and have high hopes for 1.6. You know, the hope always dies last.
Do you think it makes sense to provide a zoom slider for newsrob?
> Because many times i have the case that the default view is a LITTLE > bit to small to read, but zooming in to the next level is a LITTLE bit > too large. Therefore having the ability to zoom by percentage or > slider would help getting the exact font size i would like to have > (readable but not too big). Especially when downloading webpages you > have quite big differences in default text size, and the pre-set zoom > levels are sometimes not fitting.
It may make a little sense to get he last juicy bit of control over the zoom magnification, but it would also mean to do something non-standard on the Android platform for one, and it means I need to implement and maintain that instead of putting time in NewsRob features like enabling global search. Apart from that the current zoom controls are from the OS and are hardware accelerated. So at the end of the day, in my opinion(*), the little bit more of control is outweighed by the non-standard implementation, the lack of hw acceleration and the need to implement it instead of a big bang feature.
(*) And as we all known, only my opinion matters, everything else can only prolong the conversation ;-) just kidding ... right?
> Apart from that the current zoom controls are from the OS and are hardware
> accelerated.
Ok, this is of course a big plus i didn't know about...
> So at the end of the day, in my opinion(*), the little bit more of control
> is outweighed by the non-standard implementation, the lack of hw
> acceleration and the need to implement it instead of a big bang feature.
Yeah, if the zoom is an OS feature and hardware accelerated, i don't
see the benefit for expanding the zoom functionality. I thought it
might make sense if this is something which is done in 2 hours work.
But if you have to make it from ground up, its not worth the effort.
> (*) And as we all known, only my opinion matters, everything else can only
> prolong the conversation ;-) just kidding ... right?
you got the control like the "master control program" from TRON! We
are just Users ;)
|
