-
I'm seeing a lot of icons disappearing today. Like all the "New" badges, peoples flags/avatars.
It can also be due to intermediate servers, especially your local ISP, injecting RST packets due to very high local load.
(Once upon a time, they only dropped packets due to congestion, but ever since file sharing, large downloads, and HTTPS (TLS-secured transfers being impossible to peek into by ISPs), at least some ISPs do do that even if it is basically very nasty behaviour. Browsers see it as a failed transfer, and don't retry.) -
Site partly working for me, but images and graphics missing, basically seeing text only right now.
-
Yep embedded images are broken (external using the IMG tag) and internal images are download only and not showing on the forum proper.
I did have an issue on two PC's viewing the site where it seemed to drop some of the CSS images too in particular the 'new' one on the forum index and unread replies. -
Scrap that seems that Adblock Plus and the Top header adclick from doubleclick.net is misbehaving so it is a case of suck up the adds to see the actual forum or linked pics.
Any thoughts on this @Dave? -
Scrap that seems tht Adblock Plus and the Top header adclick from doubleclick.net is misbehaving so it is a case of suck up the adds to see the actual forum or linked pics.
Any thoughts on this @Dave?
No idea, I don't have ad block. -
No more OT after this I promise Gnif
Seems AdblockPlus got an 'upgrade' yesterday and is breaking SMF's image handling and CSS so not a site issue
-
It's not an Adblock issue.
I have the same problem on Brave. Sometimes it's the "Projects" page, sometimes it's the "Beginners", sometimes it's another page.
But it's on/off. Sometimes it's normal, then the icons disappear, a bit later the icons are back, but have disappeared somewhere else...
I thought it was an update running, but after two days I'm no longer certain.
-
It's not an Adblock issue.
I have the same problem on Brave. Sometimes it's the "Projects" page, sometimes it's the "Beginners", sometimes it's another page.
But it's on/off. Sometimes it's normal, then the icons disappear, a bit later the icons are back, but have disappeared somewhere else...
I thought it was an update running, but after two days I'm no longer certain.
There is some evidence of cached items blipping in and out from time to time without the filters being changed as most ad blockers just mask items rather than not download them. Discussion in the link here lest we irk GNIF
https://www.eevblog.com/forum/chat/anyone-else-seeing-small-images-from-forum-not-appearing-i-e-mostly-text-only/
Switched off the bit where EEVBlog was listed in 'Easylist' definitions file and no further issues. -
For the last few days the orange "New" button is missing from the unread threads. Is that just with me or does anyone else miss them too?
McBryce. -
For the last few days the orange "New" button is missing from the unread threads. Is that just with me or does anyone else miss them too?
McBryce.
Noticed that too. Seems someone slipped a too-general rule into one of the adblock lists. For now, if using UBP, add this to your custom filter:Code: [Select][url=http://www.eevblog.com#]www.eevblog.com#[/url]@#[data-pagespeed-url-hash][onload^="pagespeed"]
...Ah found it, it's in EasyList. Someone want to report it?
Tim -
Sorry if there is a more appropriate thread for this.
Can others replicate this image display problem:
https://www.eevblog.com/forum/chat/post-a-picture-of-a-cat!/msg4764302/#msg4764302
Clicking the thumbnail shows a different image, a SPICE circuit simulation instead of a picture of a cat. Well, maybe the cat isn't so important, but there was a problem years ago with image corruption and it's disturbing if it has returned. If so I think other images will also be affected. -
Sorry if there is a more appropriate thread for this.
Confirmed. I did see the original cat picture, and it was in my cache, but when I force-reloaded the large image from the server, it was replaced with a SPICE diagram.
Can others replicate this image display problem:
https://www.eevblog.com/forum/chat/post-a-picture-of-a-cat!/msg4764302/#msg4764302
Clicking the thumbnail shows a different image, a SPICE circuit simulation instead of a picture of a cat. Well, maybe the cat isn't so important, but there was a problem years ago with image corruption and it's disturbing if it has returned. If so I think other images will also be affected.
To repeat, https://www.eevblog.com/forum/chat/post-a-picture-of-a-cat!/?action=dlattach;attach=1741547;image (IMG_20230316_110455672_HDR.jpg) used to be a JPEG image of a cat on a shelf looking down, but is now a PNG format SPICE diagram. The cat post involved was not edited.
The poster is the same in both cases. The original image was attached to this message (only attachment), and the replacement image attached to this message (first attachment, charger-0v.png). -
Sorry if there is a more appropriate thread for this.
Confirmed. I did see the original cat picture, and it was in my cache, but when I force-reloaded the large image from the server, it was replaced with a SPICE diagram.
Can others replicate this image display problem:
https://www.eevblog.com/forum/chat/post-a-picture-of-a-cat!/msg4764302/#msg4764302
Clicking the thumbnail shows a different image, a SPICE circuit simulation instead of a picture of a cat. Well, maybe the cat isn't so important, but there was a problem years ago with image corruption and it's disturbing if it has returned. If so I think other images will also be affected.
To repeat, https://www.eevblog.com/forum/chat/post-a-picture-of-a-cat!/?action=dlattach;attach=1741547;image (IMG_20230316_110455672_HDR.jpg) used to be a JPEG image of a cat on a shelf looking down, but is now a PNG format SPICE diagram. The cat post involved was not edited.
The poster is the same in both cases. The original image was attached to this message (only attachment), and the replacement image attached to this message (first attachment, charger-0v.png).
No matter were I click or what I refresh, I see a brown+black cat under some LED lights, just that the picture is wrongly rotated with +90.
LATER EDIT:
------------------
- Using FF+Kubuntu+logged into EEVblog, I see the +90* rotated cat picture, either thumbnail, or enlarge inside forum, or only pic in another tab.
- Using LibreWolf (LibreWolf == Firefox with some stripped away tracing) and no EEVblog login, I see a schematic with 4 plots.
-
No matter were I click or what I refresh, I see a brown+black cat under some LED lights, just that the picture is wrongly rotated with +90.
Open the large image into a new tab, then press Shift while clicking the Refresh button. This causes a force-reload. Just clicking Refresh reloads the image from your local cache. -
It's the prevalent SMF 1st attachment bug introduced with a forum upgrade a few years back. It bites in a couple ways and at this time the only work around is to NOT use the 1st attachment < I haven't for some years.
-
No matter were I click or what I refresh, I see a brown+black cat under some LED lights, just that the picture is wrongly rotated with +90.
Open the large image into a new tab, then press Shift while clicking the Refresh button. This causes a force-reload. Just clicking Refresh reloads the image from your local cache.
Might be something else, now it's the wrong picture to my FF, too, with or without refresh, with or without shift click.
An hour ago, Firefox+logged into EEVblog was showing the correct cat picture, while LibreWolf+not logged in was showing the wrong simulation picture.the only work around is to NOT use the 1st attachment
I don't understand. What exactly to not use? What's a "1st attachment"? -
See attached screen capture.No matter were I click or what I refresh, I see a brown+black cat under some LED lights, just that the picture is wrongly rotated with +90.
Open the large image into a new tab, then press Shift while clicking the Refresh button. This causes a force-reload. Just clicking Refresh reloads the image from your local cache.
Might be something else, now it's the wrong picture to my FF, too, with or without refresh, with or without shift click.
An hour ago, Firefox+logged into EEVblog was showing the correct cat picture, while LibreWolf+not logged in was showing the wrong simulation picture.the only work around is to NOT use the 1st attachment
I don't understand. What exactly to not use? What's a "1st attachment"?
Forget the dragg and drop option and only manually attach files of the permitted types and always skip the first (Choose File) attachment box.
-
No matter were I click or what I refresh, I see a brown+black cat under some LED lights, just that the picture is wrongly rotated with +90.
Open the large image into a new tab, then press Shift while clicking the Refresh button. This causes a force-reload. Just clicking Refresh reloads the image from your local cache.
Might be something else, now it's the wrong picture to my FF, too, with or without refresh, with or without shift click.
Might be time to vacuum the cat fur out of the site server. -
All of this is nothing to do with the server or SMF (proper) and everything to do with a few Image handling addons that got installed several years ago which broke some of the code when installed on top of each other.
-
Nope, the exact same thing.
Might be something else, now it's the wrong picture to my FF, too, with or without refresh, with or without shift click.No matter were I click or what I refresh, I see a brown+black cat under some LED lights, just that the picture is wrongly rotated with +90.
Open the large image into a new tab, then press Shift while clicking the Refresh button. This causes a force-reload. Just clicking Refresh reloads the image from your local cache.
When you load anything over http or https protocol, the server can specify an expiry time, telling the browser how long the resource should stay unchanged. For the above file, the forum serves such an Expires header a year in the future, and also a Last-Modified header describing when the resource was last modified.
When you click Reload/Refresh, the browser only checks its own local cache; at most, it can send a HEAD request, which provides only the headers and none of the file data.
Thing is, the headers did not change. They still reflect the original image file, claiming MIME type image/jpeg and file name IMG_20230316_110455672_HDR.jpg. The actual data, however, is of image/png type, and not a JPEG file at all.
So, the browser just saw its cached data still valid, and re-showed the cached image. When you do a force-reload, Shift+Reload, you tell the browser to skip the cache and header check, and do a GET request from the source (or proxy), which provided the new content.
Depending on your browser cache settings, when you closed that Firefox session (last open Firefox window), it discarded that cached image. So, when you next opened Firefox and tried to look at the image, Firefox dutifully did a GET request because it didn't have it cached anymore, and bang, you see the replaced image.
You can trust me on this, because I can tell you exactly what is happening and how, even though I have never had access to an SMF implementation (source code). It runs on Nginx, and the image/attachment provider part is written in PHP – the headers I receive with the above URL tell me that. The image/attachment metadata in the database is not corrupted –– it still exists for both the old image and the new image, only the old image binary data was replaced with the new image binary data; you can verify that by looking at the headers of both the old (now switched) image, and the image that replaced it. I am not sure whether the binary data is stored in the database or in binary files, so I cannot tell for sure whether it is the data itself or just the reference to the data that got changed for the old image, but I'd bet it is the reference; and the root bug is in the database query updating the binary data reference to the attachment after the upload completes. Instead of updating just the one entry, it ends up sometimes updating the reference also for an older image. Again, image metadata (format, file name) are not similarly confused, so this must be a separate update.
(I do have a decade of commercial development experience in this stuff; I did it for years before switching back to academia, but still have kept up with the (rather small) changes since then.) -
Please be aware that I am performing some general system maintenance and there may be minor interruptions during this.
Edit: Work has been completed. -
Nope, the exact same thing.
Might be something else, now it's the wrong picture to my FF, too, with or without refresh, with or without shift click.No matter were I click or what I refresh, I see a brown+black cat under some LED lights, just that the picture is wrongly rotated with +90.
Open the large image into a new tab, then press Shift while clicking the Refresh button. This causes a force-reload. Just clicking Refresh reloads the image from your local cache.
When you load anything over http or https protocol, the server can specify an expiry time, telling the browser how long the resource should stay unchanged. For the above file, the forum serves such an Expires header a year in the future, and also a Last-Modified header describing when the resource was last modified.
When you click Reload/Refresh, the browser only checks its own local cache; at most, it can send a HEAD request, which provides only the headers and none of the file data.
Thing is, the headers did not change. They still reflect the original image file, claiming MIME type image/jpeg and file name IMG_20230316_110455672_HDR.jpg. The actual data, however, is of image/png type, and not a JPEG file at all.
So, the browser just saw its cached data still valid, and re-showed the cached image. When you do a force-reload, Shift+Reload, you tell the browser to skip the cache and header check, and do a GET request from the source (or proxy), which provided the new content.
Depending on your browser cache settings, when you closed that Firefox session (last open Firefox window), it discarded that cached image. So, when you next opened Firefox and tried to look at the image, Firefox dutifully did a GET request because it didn't have it cached anymore, and bang, you see the replaced image.
You can trust me on this, because I can tell you exactly what is happening and how, even though I have never had access to an SMF implementation (source code). It runs on Nginx, and the image/attachment provider part is written in PHP – the headers I receive with the above URL tell me that. The image/attachment metadata in the database is not corrupted –– it still exists for both the old image and the new image, only the old image binary data was replaced with the new image binary data; you can verify that by looking at the headers of both the old (now switched) image, and the image that replaced it. I am not sure whether the binary data is stored in the database or in binary files, so I cannot tell for sure whether it is the data itself or just the reference to the data that got changed for the old image, but I'd bet it is the reference; and the root bug is in the database query updating the binary data reference to the attachment after the upload completes. Instead of updating just the one entry, it ends up sometimes updating the reference also for an older image. Again, image metadata (format, file name) are not similarly confused, so this must be a separate update.
(I do have a decade of commercial development experience in this stuff; I did it for years before switching back to academia, but still have kept up with the (rather small) changes since then.)
This issue was thought to be fixed, I have just checked on disk and I can confirm that the file on disk contains the incorrect data. The file is indeed a PNG of a schematic, but the database thinks it is a JPEG.
The last time we had this issue it was identified to be a bug with the clustering filesystem (GlusterFS) which was causing inodes to be duplicated, upgrading the software resolved this and I do not see any duplicated inodes reported this time either.
If anyone figures out a reliable way to reproduce the fault and can provide step by step instructions so that I can dig deeper it would be greatly appreciated.
Edit: I have also contacted the OP of the message to try to obtain an exact copy of the image that it should be for further diagnostics
Edit2: It gets even stranger... I found the post the replaced image comes from, and it's even from the same user.
https://www.eevblog.com/forum/beginners/resistor-y-junction-calculations/msg4764878/#msg4764878
Edit3: Even stranger again... I pulled the two files from the server, they are the identical image, but they are different on disk. One has been altered/reprocessed? Starting to suspect a buggy image optimisation plugin or something.
-
The situation with attachments is a big mess and it looks like a forum bug.
It appears that posting an image occasionally overwrites the exact previous image posted by the same user, regardless of file format, thread or any posts in between made without attachments. No reliable trigger is known and it is unclear if the same could happen to non-image attachments.
A recent thread about it
https://www.eevblog.com/forum/chat/im-beginning-to-see-some-new-file-attachment-wrong-file-errors-again/
The inline images plugin got blamed last time and it has been half-disabled for over a year now. You can select the relevant option while posting, but the forum doesn't render resulting [ Attachment Invalid Or Does Not Exist ] tags. I seems to recall that Dave did an SMF upgrade shortly before the issue returned this year.
Sorry for not bringing this thread to your and Dave's attention earlier, I assumed that somebody (like maybe the OP) had already done so
edit
I'm not familiar with SMF internals and these plugins, but if you ask me, I would say that the location to write the attachment on disk gets written somewhere into the database, associated with the current user. Subsequently, a stupid race condition causes the file writing job to use the previous post's filename before the cached value is updated. Or maybe it doesn't get updated at all for some other stupid reason.
At any rate, the file name and path associated with the attachment doesn't seem to change. The contents are replaced. A few times we have seen XXX.JPG files with PNG contents in them or vice versa. -
Sorry for not bringing this thread to your and Dave's attention earlier, I assumed that somebody (like maybe the OP) had already done so
No, I was aware of it but I was under the impression it was resolved. It was far worse at one stage.I'm not familiar with SMF internals and these plugins, but if you ask me, I would say that the location to write the attachment on disk gets written somewhere into the database, associated with the current user.
The database just stores meta data and SMF writes each file to the disk with a name it generates, which is the unique primary key of the table combined with a hash of it's filename, the current time, and a random number.Code: [Select]$hash = sha1(md5($filename . time()) . mt_rand());
$filename = $id . '_' . $hash;QuoteSubsequently, a stupid race condition causes the file writing job to use the previous post's filename before the cached value is updated. Or maybe it doesn't get updated at all for some other stupid reason.
Yeah, I am still not sure as to the cause as this should be impossible. PHP isn't multi-threaded per request per request, and since the filename/hash used is guaranteed by the database and the filename generation method that SMF uses to be unique, it should never happen.
What is even stranger is the post times of this latest incident was about 1/2 an hour apart, which rules out a race also. And finally, the new file that is written to disk incorrectly, is different from the file that it should be if it were just overwritten, it has also been altered/processed (this confirms it's a PHP/code bug, not fs or database)
Also what is further strange, SMF generates thumbnails when you try to view the thumbnail on the fly, it doesn't do it at image upload time. For this to have worked, the file on disk's contents needed to be correct to begin with.
I am on break for a few days, but as I can I will try to debug this futher. -
I had a similar problem on another forum. I found that it depended on what software was used to create or convert the image. I think we finally decided that it was a problem with the EXIF data containing wrong data.
McBryce.