Jump to content

The A-Team

+Premium Members
  • Posts

    7768
  • Joined

  • Last visited

Everything posted by The A-Team

  1. Same thing here, so it's almost certainly an issue on the HQ side.
  2. 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.
  3. 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.
  4. 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.
  5. 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. There has been no change with these. This has been fixed, and works more logically now. 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. 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.
  6. 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.
  7. 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
  8. 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.
  9. 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.
  10. 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).
  11. 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.
  12. 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.
  13. 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.
  14. 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.
  15. "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.
  16. 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.
  17. 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.
  18. 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.
  19. 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.
  20. 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.
  21. Yep, that shouldn't apply this month. From the original post about Wheel of Challenges:
  22. 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.
  23. 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
  24. This is awesome and very timely. I just got back from a trip and have a bunch of Waymarks to log, so this will greatly save time by not having to go back in and edit the date on each one. Thanks for this and the other fixes!
×
×
  • Create New...