• Scam Alert. Members are reminded to NOT send money to buy anything. Don't buy things remote and have it shipped - go get it yourself, pay in person, and take your equipment with you. Scammers have burned people on this forum. Urgency, secrecy, excuses, selling for friend, newish members, FUD, are RED FLAGS. A video conference call is not adequate assurance. Face to face interactions are required. Please report suspicions to the forum admins. Stay Safe - anyone can get scammed.
  • Several Regions have held meetups already, but others are being planned or are evaluating the interest. The Calgary Area Meetup is set for Saturday July 12th at 10am. The signup thread is here! Arbutus has also explored interest in a Fraser Valley meetup but it seems members either missed his thread or had other plans. Let him know if you are interested in a meetup later in the year by posting here! Slowpoke is trying to pull together an Ottawa area meetup later this summer. No date has been selected yet, so let him know if you are interested here! We are not aware of any other meetups being planned this year. If you are interested in doing something in your area, let everyone know and make it happen! Meetups are a great way to make new machining friends and get hands on help in your area. Don’t be shy, sign up and come, or plan your own meetup!

Difficult Picture upload... again

Suggjestion Type
  1. Forum Software

Susquatch

Ultra Member
Administrator
Moderator
Premium Member
Sir, your pictures will not expand for me.

This is an ongoing challenge for many members. The images system has been messed up for quite some time on the forum with no sign of hope for the future.

The best way to improve the situation. Is for the poster to select thumbnail when uploading a photo.

Screenshot_20250630_102705_Chrome~2.jpg
 
Can someone provide me with examples of where this happens? A particular thread with these images? I can help narrow down this sort of problem if I can recreate it.
This thread:
 
Following up on this with a thought. Susq / David have you tried turning off all caching on the server?

When the forum was moved to a new host, we lost ability to do things like that.

https://canadianhobbymetalworkers.com/attachments/20181206_191233-jpg.66779/

So is this link broken for everyone? Or is it inconsistent and works for some people and not others?

Works fine for me. I think that answers your question.

I'm not at home right now so I can only test it using my mobile phone.
 
So assuming it's $250USD/month we need 68 paying members.

As of today, we have just over 50. That has been slowly but consistently growing as the years pass by.

Although we can't afford that today, it will be within reach in a year or two. I think the biggest issue isn't really reaching a threshold. It is maintaining that threshold over a long period of time. The last thing we need is to move and then not be able to pay the bill.

Membership drives might help, but that isn't an ideal model. Ideally we want to increase our regular membership by increasing the value they derive from being a member here. Enough value that they want to contribute as an expression of gratitude and appreciation.

We already balance appreciation with member perks. Maybe we could do a better job of that, but I'm inclined to think the balance that was struck by you guys before I arrived is pretty darn good.

Right now, Friday morning, 16 members and we have 266 guests. How many of those guests are 'bots' web crawlers and the like? Do we have too much load and it's more than our server allotment can handle?

Total: 282 (members: 16, guests: 266)

I believe there is a mix of crawlers, bot, and unregistered viewers in the current viewers.

I don't think this load is all that big a deal. Every website, big or small, has to deal with that reality. For us, I think the biggest deal, is all the photos that all have to be stored and be accessible. We do love our pictures! I believe that's why our hosting service targeted our photos.
 
Following up on this with a thought. Susq / David have you tried turning off all caching on the server? Maybe you already ran down that path already sorry if it is a FAQ.

https://canadianhobbymetalworkers.com/attachments/20181206_191233-jpg.66779/

So is this link broken for everyone? Or is it inconsistent and works for some people and not others?

I tried opening the above image on my mac, safari, in a new window, and found I get a few lines of the top of the image but not the whole image. It then errors with a lost network connection.

Then I tried the same URL on my phone but only used the telecom network and turned off my wifi. It very slowly loaded the picture until nearly the end and then also failed with an error network connection lost. Screenshot below.


View attachment 66786
On my iPhone 14+

IMG_9993.png
 
One of the challenges with sorting this out is replicating the problem. I have no issues on Win10/FF or Android/FF.
 
Probably not related but sitting here in Timmie’s I clicked on a link and saw something I never saw before the bar moving as I scrolled.
IMG_1576.png


IMG_1575.png

I turned the wifi off & on and it was back to normal WTF
 
Came down to office (M1 2020 MacBook Air, Sequoia 15.5 - latest MacOS) and got blank screen. Checked connection:
Screenshot 2025-07-04 at 6.49.52 PM.png


iPhone 14+ also running latest iOS (18.5).

Both on Safari.

However, fired up FireFox, pasted the link in and immediately loaded:
Screenshot 2025-07-04 at 6.55.55 PM.png


Then tried DuckDuckGo on the iPhone and got this:
IMG_9996.jpeg


In my case, it seems to be an issue with Safari; or more correctly, Xenforo has an issue with Safari: many websites are not configured to work 100% with Safari, but usually they tell you that "for best results" you should use . . . In those few cases I use FireFox since I do not use Google anything unless there is no workaround (like YouTube).

However (again), I don't have these issues with HMEM or H-M (although they have had other, server-related [I think] issues), which both use Xenforo, nor with HSM, which uses vBulletin®.
 
.
Our biggest PITA issue IMO. Is there a way to provide immediate feedback to a user when they attempt a picture upload which appears to load OK based on thumbnail, but inevitably leads to the dreaded 'unable to display' for the next 1000 people who click the image & trip on the same problem over & over again? Like if the issue is file size, a popup message comes up & immediately says 'sorry maximum image size = X MB' & poster knows he has to reduce it on his end.

That is the way it works now. The problem isn't the uploaded file size. It's the subsequent image optimization that is out of our control and out of the users control.

Or if our web app is fussy about file extension type, same idea.

Yup, that's how it works now. As, said above, the upload isn't the problem. It's the way the image optimizer and server server handles the images after that.
 
That is the way it works now. The problem isn't the uploaded file size. It's the subsequent image optimization that is out of our control and out of the users control

I just suggested size & type as an example culprits & I know you guys have pulled your hair out already. So if the subsequent image optimization is the culprit & buggering up the image so it cant be click viewed, isn't there some common thread or parameter as to what we can screen for or avoid uploading? Worded another way, I don't think (or at least nobody has complained) that they cant see my pictures. They are plain vanilla jpegs resized to max 500 pix just for posting convenience. Here is sample attached & embedded. So if this works across various browsers or hardware, what is uniquely different about these vs the problem pics?

embedded
1751684319850.png
 

Attachments

  • EDT-04-07-2025 8.16.43 PM.jpg
    EDT-04-07-2025 8.16.43 PM.jpg
    47.1 KB · Views: 0
This thread:

So the resource is there server side and can load fine if you go to the direct url for the attachment:


However, despite returning a 200 (http success) there's another error ERR_QUIC_PROTOCOL_ERROR, which seems to be a quick udp internet connection that is being used to async load the image resource on demand. Going to try disabling this protocol in chrome and see what it does (needs a browser restart)

1751685903857.png


1751685876777.png
 
So the resource is there server side and can load fine if you go to the direct url for the attachment:


However, despite returning a 200 (http success) there's another error ERR_QUIC_PROTOCOL_ERROR, which seems to be a quick udp internet connection that is being used to async load the image resource on demand. Going to try disabling this protocol in chrome and see what it does (needs a browser restart)

View attachment 66819

View attachment 66818

After a restart with the quic disabled it switches to an http2 error and doesn't load the resource:

1751686778448.png

I'd have to see the server side logs to get any further probably, the http request headers are different between a straight get on the attachment itself and the get when it's embedded, and I suspect the server is not responding the same way based on this. XenForo is obviously doing something to craft a request that does the load of the image without a full postback different than just a plain javascript get on the resource and displaying.
 
Back
Top