The A-Team
-
Posts
7769 -
Joined
-
Last visited
Posts posted by The A-Team
-
-
Same thing here, so it's almost certainly an issue on the HQ side.
-
Occasionally, when trying to add a photo to a log (after it has been submitted), the upload will just hang. The spinning indicator will just keep going forever (I've left it for as long as 10 minutes before). I can click the X to seemingly cancel the upload, but reloading the log page will show that the image successfully uploaded, albeit without the "Image name" I had entered. I'll then have to edit it to add the Image name again.
This may be a tricky one to troubleshoot, because it's intermittent. I haven't noticed any patterns for which ones work or fail. If I had to estimate, I'm seeing it roughly once every 20 images. Just now, I had a failure as per above, but then accidentally uploaded the same image again. It worked fine the second time, so it doesn't seem to be an issue with the files themselves. I'm using Firefox 122.01 on Win 11.
-
After seeing the last post, I decided to not delete the file after my last caching day to test this out. I just uploaded it after finding some more caches, and the old drafts still uploaded, so the issue hasn't been fixed yet. Or it was fixed and has since regressed.
-
2
-
-
IIRC, the stats update at the next find log submitted, or after 24 hours, whichever comes first. I didn't think the find count was part of those stats, though, and should update immediately. Maybe it doesn't for existing logs changed to finds, but I didn't think that's how it worked. Waiting for 24 hours would answer this one way or the other.
-
I just went back to check on the status of the other outstanding issues I had reported, to see if they had also been quietly fixed. It seems that there has been some progress that hasn't been reported. If anyone else has reported issues with this release, you might want to test to see if they have been resolved.
On 11/6/2023 at 10:04 PM, The A-Team said:- After I drag in an image and add a caption, hitting Enter on my keyboard activates the "Rotate 90 right" button. This seems like unintended behaviour, or at least isn't what users would expect. The logical expectation for hitting Enter would be to either submit the image, or do nothing.
- After uploading an image to an existing log, it used to be that the just-uploaded image would be shown. Now, it takes you to the log view with the first image displayed. It might make more sense to display the just-uploaded image, so the uploader can confirm that things look right.
There has been no change with these.
On 11/14/2023 at 9:33 PM, The A-Team said:I found another bug. I selected the date for a log first (3 days in the past) and then selected the log type, and it reset the date back to today. By testing, it appears that any change of the log type (either from one type to another, or from blank to a log type) sets the date to today. It should only do this for the OAR or RAR log types. When setting to the other log types, there's no reason for the interface to change the date from what has been selected by the user.
This has been fixed, and works more logically now.
On 11/15/2023 at 9:50 PM, The A-Team said:Related to this, the date isn't being forced to the current date for the OAR and RAR log types like it's supposed to. The date is set to the current one after the log is submitted, but the user is misleadingly allowed to change the date in the interface, even though that will ultimately have no effect. The date should be locked to the current date when these log types are selected, similar to how it works when you log an Attended on an Event.
This hasn't been fixed yet. The user is still able to select a different date for OAR and RAR logs (and I noticed also Disable/Archive), even though that selection will just be ignored when the log is submitted.
On 11/23/2023 at 8:03 PM, The A-Team said:...
In an attempt to work around the error above, I attempted something that Viajero Perdido mentioned: rotating the image. By doing this, it did allow the images to upload. However, I discovered that the rotate and flip functions are misleading. In the upload interface, you can click these buttons multiple times and they progressively rotate or flip the preview image, implying that you can flip/unflip or rotate 180/270/360. However, once you upload, the resulting image reflects a single action of the rotate/flip buttons. For example, if you click the "Rotate 90" button twice to rotate 180 degrees, the result will only be rotated 90 degrees and not match the preview that had been displayed. Likewise, if you click the "Flip horizontal" button twice to flip and then flip back, the result will be flipped once horizontally.
These functions should either be updated to perform the action multiple times according to what's being shown to the user in the preview, or be changed to toggles to indicate their "single-action" function (in which case the preview image code would also need to be updated to reflect this).
This has been fixed. Each click of these buttons now applies the action progressively, so multiple rotations can be applied, flips can be unflipped, etc.
-
3
-
11 hours ago, SnowstormMK said:
We released a fix that increases the allowed size for images to 10MiB. This fix also addresses the issue players had with uploading images.
That's great! I just tested and confirmed I could upload images to a cache listing which had been failing earlier. The increased limit is also appreciated. I'm looking forward to seeing the other outstanding issues resolved.
-
2
-
-
6 hours ago, brendan714 said:
Also, when I try to upload images to my cache page, I randomly get this error:
It's not related to image size - my image is less than 5 MB. If I refresh the page, the image uploads properly.
Interesting. I just did more testing to see if anything had changed from my earlier attempts, and I can't get any images to upload to the cache listing. I even tried refreshing like you suggested, but it still gives that error.
Then I considered what SawaSawa said above about different browsers. All of my testing has been in Firefox, and it simply doesn't work. I then tried Chrome, and got different results. On the first attempt in Chrome, the same image uploaded successfully on the first try. I then tried uploading another of my test images and got the error. After refreshing the upload page and trying that same image again, it worked.
So, the upload page is buggy but sometimes works in Chrome, and doesn't seem to work at all in Firefox. Hopefully this helps the devs to narrow in on the cause.
Edit to add: I'm using the latest version of each browser: FF 120.0.1 and Chrome 119.0.6045.200
-
.png)
1
-
5
-
-
7 hours ago, Optimist on the run said:
I've just been unable to upload a photo that is 4.9MB, and it's asking me to use a photo that's less than 5MB. Er - it is!
The limit right now is actually 5 million bytes (MB), which is roughly 4.77 megabytes. We've been told that the limit will be increased to 10 MiB (mebibyte), which is the unit typically shown by phones and computers as MB, so it should make more sense to users in addition to giving more wiggle room.
-
1
-
3
-
-
On 11/25/2023 at 2:05 AM, MartyBartfast said:
When you've pasted the image click the "Rotate 90 Right" and rotate it 4 times so it goes back to upright and then upload it, that seem to work.
It might also work to click the Flip Horizontal/Vertical twice (2 fewer clicks
)
See my post a few up. At least for me, the buttons don't act the way you'd expect.
-
On 11/19/2023 at 4:42 AM, Eric van Graveheart said:
At least, this workaround, to upload older images via the "Edit Log" dialog was working now for me. I just tried it again for an older log of 21/06/2023 : I removed the images which were recently uploaded with the wrong date and then uploades them again. And now these images show the corrct date of the find!
This wasn't working before, but I see that it is now. I guess this issue has quietly been fixed, and I now wonder what else might have been changed too.
-
I found another couple of bugs with the image uploading.
I was attempting to upload some images to a cache listing, and the interface was giving errors for many of the images. These are simple JPG images that aren't big in dimension or file size, so I have no idea why they're being rejected. The underlying upload code seems to have some overly-stringent restrictions on it, but gives no feedback to the user regarding why the image can't be uploaded. Things need to be tweaked there to either be more lenient, or at least give the user some info that they can use to resolve the issue. An example of an image that I can't upload is a 10KB, 600x200 file, created by pasting an image into Paint and saving as a JPG, which should be "clean" of any odd metadata. Heck, even a simple hand-drawn smiley in Paint and saved as a JPG is failing to upload. Something is really wrong with the upload function. NOTE: As I was typing this up, I decided to try uploading these same images to a cache log, and they all upload fine. It seems like it's specifically the cache listing image upload feature that has a major issue.
That isn't even what I was originally going to report.
In an attempt to work around the error above, I attempted something that Viajero Perdido mentioned: rotating the image. By doing this, it did allow the images to upload. However, I discovered that the rotate and flip functions are misleading. In the upload interface, you can click these buttons multiple times and they progressively rotate or flip the preview image, implying that you can flip/unflip or rotate 180/270/360. However, once you upload, the resulting image reflects a single action of the rotate/flip buttons. For example, if you click the "Rotate 90" button twice to rotate 180 degrees, the result will only be rotated 90 degrees and not match the preview that had been displayed. Likewise, if you click the "Flip horizontal" button twice to flip and then flip back, the result will be flipped once horizontally.
These functions should either be updated to perform the action multiple times according to what's being shown to the user in the preview, or be changed to toggles to indicate their "single-action" function (in which case the preview image code would also need to be updated to reflect this).
-
3
-
1
-
-
On 11/20/2023 at 8:03 AM, Tundra Wolf said:
Not a bug. There is a little pin above the date. Click that to set the date as "sticky". In other words if you do that then as long as the browser session stays open, the date will be the same on each log (whatever date you set) until you change it manually, or until you unclick that pin.
I think you misunderstood. This isn't a matter of the sticky pin functionality, where the initial date can be "stuck" for future logs. The issue I described is that I can choose a date from the selector (regardless of what date the page opened to initially), change the log type, and it resets the date I selected back to today. If I select a date, the interface shouldn't undo that, except if I select the log types that force the date (OAR or RAR).
FWIW, selecting the date, pinning it, and then changing the log type does retain the selected date, but that's a workaround at best. It shouldn't be necessary to select the date, pin it, change the log type, then unpin the date.
-
3
-
-
On 11/14/2023 at 9:33 PM, The A-Team said:
I found another bug. I selected the date for a log first (3 days in the past) and then selected the log type, and it reset the date back to today. By testing, it appears that any change of the log type (either from one type to another, or from blank to a log type) sets the date to today. It should only do this for the OAR or RAR log types. When setting to the other log types, there's no reason for the interface to change the date from what has been selected by the user.
Related to this, the date isn't being forced to the current date for the OAR and RAR log types like it's supposed to. The date is set to the current one after the log is submitted, but the user is misleadingly allowed to change the date in the interface, even though that will ultimately have no effect. The date should be locked to the current date when these log types are selected, similar to how it works when you log an Attended on an Event.
-
1
-
1
-
-
51 minutes ago, Fields111 said:
So, my concern now is not about renaming the logs reporting problems, but about the need to make two separate logs... one with my Found, DNF or Note and another to report a problem with the cache. I don't see this as an advantage to the "players", on the contrary. And for owners and reviewers... they end up receiving the separate logs with the problems, as before, the only difference may be the quantity... fewer problem records, as many people will avoid, or forget to do them.
The owners were already receiving separate logs, so nothing changes there. The "Report a problem" was simply a shortcut in the logging interface. On the other end, everything acted the same as it did before that feature existed, and how it works now. There wasn't anything magical about the feature.
As has been mentioned by others, the logs that come from the new method are much more meaningful and useful, rather than simply the pre-canned "something is wrong". I see it as a positive change.
-
6
-
1
-
-
- Popular Post
- Popular Post
I found another bug. I selected the date for a log first (3 days in the past) and then selected the log type, and it reset the date back to today. By testing, it appears that any change of the log type (either from one type to another, or from blank to a log type) sets the date to today. It should only do this for the OAR or RAR log types. When setting to the other log types, there's no reason for the interface to change the date from what has been selected by the user.
-
10
-
1
-
8 hours ago, Fields111 said:
I have already used the new page for logging but only with "Founds". Now I saw the explanations of all the changes and I have some doubts.
1 - If I want to log a "Found" and report the cache needs maintenance, I deduce I have to choose now the "Owner attention Requested" (OAR) right? What is the result in terms of logs history? It will make two logs, one "Found" and one OAR? I know there's some issues with the dates of OAR logs, but in this case, the "Found" log will have the correct (found) date, right?
2 - In case there would be two logs, if the owner deletes the OAR the "Found" log remains in it's place?
3 - Related to question 1, if I just want to log a OAR, without a found, I would select the OAR type, but how the system knows it's just a "note" and not a "found"?
"Owner attention requested" is just a renamed "Needs maintenance" log. It isn't tied to any other logs, so it can be logged/edited/deleted/whatever without affecting any other logs like finds. Likewise, "Reviewer attention requested" is a renamed "Needs archived" log.
-
2
-
-
6 hours ago, ari54321 said:
Thank you for reporting this issue of incorrect gallery dates. It appears this issue only affects images uploaded from the view log page. For now, there is a workaround: if you upload image(s) on the edit log page (open your log, select "Edit log", then drag and drop or select photos to upload), these images will have the correct date (log date, not today's date).
If you wish to correct the dates of already-uploaded images, you can delete the images and re-upload them through the edit log page. We are looking into a fix for the upload button on the view log page.
Thanks for the suggestion of a workaround, but I get the same result as 99celing, in that it still uses the current date rather than the log date. It looks like both upload methods have the same issue.
As long as I know it will be fixed, I'm fine to wait.
-
4
-
1
-
-
- Popular Post
- Popular Post
7 hours ago, Eric van Graveheart said:...
But now, with the recent change, these newly uploaded fotos are inserted in the gallery with the TODAY date! And I do not see any way to edit this "image detail" - namely the DATE ... ...
I can confirm this regression. For a number of years prior to this change, images would inherit the date of the log by default, and you could go in to edit it later to change the date if necessary. It now uses the date of upload, and there's no option to change the date. At the very least, the behaviour of using the log date by default should be restored. It would also be appreciated if a date selector was added so the date can be changed after-the-fact as relevant.
I uploaded a number of images over the last few days for caches I found over a week ago, so they have been given the incorrect date. Since I don't know if there will be a way to correct these later, I'll delete them and save them locally for now until the issue is resolved and they can be uploaded with the correct date.
I would consider this issue a higher priority to resolve, since every passing day means more images mis-dated.
-
17
-
2
-
I just found that the 5 MB limit is misleading. I tried uploading an image that was reported as 4.89 MB by Windows, and it got rejected. I suspect the limit is really 5000 KB or 5000000 bytes, either of which my image would have been over. It would be good if the limit was set to 5242880 bytes (5 MiB), so users don't have to worry about fractions of a megabyte and can base things off of what their device is reporting for the image size.
-
8
-
-
A couple of notes about the new image uploading:
- After I drag in an image and add a caption, hitting Enter on my keyboard activates the "Rotate 90 right" button. This seems like unintended behaviour, or at least isn't what users would expect. The logical expectation for hitting Enter would be to either submit the image, or do nothing.
- After uploading an image to an existing log, it used to be that the just-uploaded image would be shown. Now, it takes you to the log view with the first image displayed. It might make more sense to display the just-uploaded image, so the uploader can confirm that things look right.
-
4
-
2
-
I just noticed the new logging experience. Overall, I like it. It shows that the requests of the members were heard and implemented.
I understand that the limit on size and number of images is likely with the intention of cutting storage and bandwidth cost. The limit of 5MB seems too low, though. By just looking at the recent photos I took with my iPhone, about half are over that limit. I don't upload those directly, but many do. This limit will mean members either have to go through several steps to reduce the size first, or will simply give up and not upload. There's a good chance that more would head toward the latter. What might have been a valuable addition to the experience (for the finder, owner, and later cache viewers) is lost.
If storage costs are becoming so problematic that a very-restrictive limit needs to be put in place, I'm not sure how else to deal with it. Increasing the limit to something like 10MB would allow most photos to be uploaded, but then we're just back to where we started. Maybe somewhere in between?
I upload many photos and can adjust my workflow to make them fit within the limit, but I worry that this limit will severely restrict things beyond what's necessary for many members and the overall experience will suffer.
-
3
-
3
-
-
Yep, that shouldn't apply this month. From the original post about Wheel of Challenges:
QuoteEach challenge will begin on the first Monday of the month. For challenges that involve the Leaderboard, those challenges will begin on the first Monday of the month at noon UTC (convert to your local time here).
-
Oh good, it isn't just me. I started seeing this sometime in the last week or two. Like LostSparky, I tried deleting the visits file, but the issue is continuing with the new one. The two caches from my previous upload showed up again tonight.
-
4 hours ago, The Snowdog said:
A minor glitch in the new Coordinate box - if you edit the WM and change ONLY the coordinates, it fusses that you haven't made any changes and you have to go back and alter some text as well. This has also been a long-standing problem with the "Private Message" field.
In a similar but possibly related bug, I just went in to edit the coordinates of a Waymark that had a very inaccurate position, and it's telling me I need to provide a reason for changing the address. I didn't touch the address fields. I even started over and made sure I didn't inadvertently click an address field, and it's still wanting a reason.
Edit to add: It may or may not be pertinent, but the address fields were blank at the time
.png)
)
There is no image with that ID
in General Waymarking Topics
Posted
This is happening yet again. Whatever's being done to fix it isn't sticking.