Showing no items and/or a 404 error.
Failed for me too - same outcomes. This was on Android, where I used to get an “unresponsive script” error.
Could you send in screen shots (to the ispot inbox or me personally) when this happens, make sure to include the time and date so we can track this down. We have been looking but not found specific cause yet.
Just sent you a couple of screen grabs. Thanks.
This is five days old, it would be nice to see the Screen shots and news of the cause or the solution
I have found that when these problems occur, the screenshots will not post in. They bottom of the page says “Upload 100%”: but the spinner still spins, and no preview will appear.
Sorry, not going to post these on a public forum because of some of the peripheral detail. I don’t know if anyone at iSpot has seen them but no response so far.
I’ve been trying both the Activity and Changes Trackers at different times of the day over the past week and haven’t experienced issues with either. Given for me each page loads within a second or two, the slowness or non-response that some users are experiencing may be down to the sheer volume of interactions you’ve had with the site - I only have something like 8 pages despite having been a use for many years. We don’t think its an issue with the code, but it could be something in the data - perhaps one particular observation or comment is causing problems with the database queries. Suffice to say this is something we are currently investigating.
YOU are very welcome here Chris the Coder! I am certain you are right. The click forces the code to trawl ALL our activity, the result would contain a change made to a 2010 post, for example. So yes, we are asking a lot.
The same difficulty occurs when refreshing the Map in Projects where there are as many as, often more than, 8000 - 8 clicks then. As for the Gallery at 49 per page, a very long afternoon!
Here’s one (Try the Gallery Refresh) ✳️ ALL UK INVERTS WITHOUT ID ✳️ | Project | Observations Map | Page 1 | UK and Ireland | iSpot Nature it begain with eleven THOUSAND observations, now down to about 4000.
.
Not entirely unrelated is that Other Observations are displayed with every Observation BUT only ever shows the most recent 49 and, unless, you are ingenious, it is hard to see the other 500.
I do hope you are UP for a laugh!
One thing I’ve noticed is that the browser tab title on an observation starts of with the URL (a natural state for when the browser hasn’t yet got the page from the server), switches to the observation title, switches back to the URL, and finally switches to the observation title. I’ve no reason to believe that this is a major contribution to the performance issues, but it does look like the client side scripts are doing redundant work.
Hmm. Probably not a data problem or we would expect it to happen every time (and that’s likely to apply to code problems too because I always use the same route into the changes tracker - a bookmark.) For a similar reason I don’t believe it’s down to sheer volume of data (and in this case others would be affected more than me.) What about a load / timing issue? I wonder if the system logs would provide more clues.
.
One note I would make is that it seems to be happening at a point in the process after the changes tracker has been populated but before it is displayed. I say this because when I eventually get the tracker to display, none of the entries show up in yellow (a change not previously displayed in the tracker) though some of them should have been highlighted. This suggests to me that they had already been selected and the relevant flags cleared.
With regards to general sluggishness the problem may be with downloading all the images before displaying the page. (More often than not I don’t need to look at the full size images, so downloading them is a waste of time.)
Recently I looked at an “other observations” observation. When I went back to the original observation it was sluggish about redrawing the page which seemed to be related to the images. I’ve also noticed that when I agree with an identification it reloads the page, and takes a long time about it. (It takes a fair amount of time to admit to have added the agreement successfully, but takes even longer to redisplay the page.) Apart from the question as to why it is necessary to reload the page (marks 1 and 2 didn’t do this, and mark 3 doesn’t do this for favouriting), it looks as if images aren’t being cached on the client side.
I’d guess that the failing changes tracker is a timeout issue. Hanging carousels might also be related. I’m wondering whether the server running out of threads is an issue.
THAT looks like valuable info for the coders. It is quite noticeable how everything related to Trackers and Galleries has been degraded, somehow, over the recent two or three weeks.
That page certainly does take a long time but in this instance I think its down to the Google Maps API clustering facility. I not that when it finally loads it says its “Showing 1000 observations” which sound to me like its reached a limit itself rather than running out of data.
[quote=“dejayM, post:9, topic:1093”]
Not entirely unrelated is that Other Observations are displayed with every Observation BUT only ever shows the most recent 49 and, unless, you are ingenious, it is hard to see the other 500.[/quote]
Are you referring to the observations list page(s)? eg:
IMHO that page has too many entries on it - and the pager is rubbish because it doesn’t give you any idea of how many records or pages there are.
[quote=“lavateraguy”]
With regards to general sluggishness the problem may be with downloading all the images before displaying the page.[/quote]
The system produces up to four other versions of every image uploaded to an observation or project: small, medium, large and zoom - as well as retaining the original image. It does this using a scheduled task and once done, never goes back. Nowhere should it load an image larger than it really needs to display it so, for example, the observations list page for example shows all medium images.
We have requested a doubling of the RAM allocation to each of the servers and are also going to double the storage allocation for photos. I’m hoping at least the former will make a difference to the responsiveness, but the next stage is to look at the database queries to see if any are specifically causing issues. The table structure is very complex and, IMHO, not very efficient.
“Are you referring to the observations list”
Yes @Chris_Valentine (thanks), where Other Observations appear in any Observation, ONLY the most recent 49 are displayed. One can can never get to the 50th and beyond. https://www.ispotnature.org/communities/uk-and-ireland/view/observation/788010/jay - I think we can live with that though.
YOUR link above works well (it’s not fair). But try mine Click on Observations here https://www.ispotnature.org/communities/uk-and-ireland/species-dictionary/NHMSYS0000530374/garrulus-glandarius - only ever gets 49 thumbs (cannot be refreshed) there is only one page. There are 338 Other Obs (7 pages?).
Other Observations:- I think this is limited in records number because they are all retrieved as the entire page is loaded - so if you wanted more, the page would take longer to load. Its appears to be the same approach as the home page where the two sliding panels at the top are limited to the number of records. We have a new developer joining us soon and if he’s up to it, he could change the code so that those scrollers were loaded independently of the page (a process called Ajax) and could therefore retrieve all records, one set at a time, without affecting the page load time.