Viewing statistics - anomolies with jpegs & pdfs

Project:RUcore/NJDH/Partner Portal Search
Component:Searching - Service Agent
Category:bug report


Noticed in "test" that viewing images w/ generated thumbnails - resulted in more than "1" view being added to total jpeg views. This needs more testing - is it appears to be a somewhat irregular behavior on dev system. PDF downloads increment to PDF once, and then again for the jpeg. Jpeg downloads increment the jpeg twice.

On production NJDH site, this is is a constant behavior.



Project:New Jersey Digital Highway(NJDH) Website» RUcore/NJDH/Partner Portal Search
Version:<none>» 7.5
Component:Code» Searching - Service Agent

This can be said for any stillimage in the repository.

On the full record view the image provided by default comes from the JPEG-1 datastream, so just viewing the record increments the count by 1. Then if you click on the image or JPEG-1 link this will increment the count again.

The best way to resolve would be to increase the default size of our thumbjpeg datastreams so they could be used instead of the JPEG-1 and then not counted.

This was outlined in a proposal last year but was never finalized. An issue came up with how large can a JPEG be on an embargoed JPEG-1 datastream before is exceeds "fair use" or might be considered a copyright violation or a violation of the use that caused the initial embargo.

Perhaps Rhonda can weigh in with where we are at, she was going to contact Janice.

I am attaching the initial proposal as a reference.


Assigned to:Anonymous» rmarker


Assigned to:rmarker» chadmills

For the current image collections, we should use the thumbjpeg datastream on both the brief (results list) and full record displays. This will solve the problem of "double counting" the jpeg-1 datastream in the statistics. If the public user wishes to view a larger image, the links are on the full record display to make them available.

Yes, we need to address the copyright implications of providing additional sizes of "thumbnail" images (for gallery view, for jpeg-page-turner). Rhonda is following up on that separately in discussions with the Copyright and Licensing Librarian.


Version:7.5» 7.6

I won't be able to do this in 7.5. It's not a simple change and it isn't the cause of something else I did in the this release.

I understand it's not desirable, but this behavior has been in place for over a year. One of the reasons I suggested moving to a larger THUMBJPEG last year was to correct this issue. We really need to get this thumbnail JPEG resized to more useful dimensions.


Version:7.6» 7.5
Assigned to:chadmills» langschi
Status:active» test

So I thought about this a little more, from a different perspective. I figured if I could centrally distinguish the calls that were used to make this full record view thumbnail I could then exldue them from being counted. Since this was rolled out last year some additions to the URI syntax have made this possible.

Long story short, they shouldn't be counted now. It's mostly a configuration change and a change to the central script used to generate the resized jpeg so it's not a very pervasive change.

Please test by viewing a record that is a still image. Note the number of downloads for the JPEG-1 datastream. Refresh the page, the number of downloads shouldn't change. Then either downlaod the JPEG-1 or click on the large thumbnail, check the download count and it should increase accordingly.


RJM here: in my test, I observed the jpeg and pdf download statistics being counted accurately. Over to Linda for final test in


Status:test» fixed

This looks OK to me. I opened a page with only a JPEG and 8 downloads. I viewed the JPEG and the count incremented to 9. I reloaded the page and the count remained at 9. Then I tested an object with multiple JPEGs and 2 PDFs. Interestingly, the first JPEG had 102 downloads and all the other datastreams had downloads under 10. I downloaded JPEG 2 and its counrt went up though JPEG 1 remained at 102. The same happened when I downloaded a PDF and reloaded.


Statistics look ok now. However, on Test, the links (jpeg, pdf) under the thumbnail pic are overlapping the image. Chad has seen this and will investigate.


I suppose that positioning is properly a separate issue.


Status:fixed» closed

Back to top