Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
dragon-engineer
@dragon-engineer
yes, that's why I didn't test it earlier, nothing suspicious around
when I use request->send(404, "text/html", "404 Not Found"); it's all good
Me No Dev
@me-no-dev
what id you just request->send(SPIFFS, "/404.html”);
dragon-engineer
@dragon-engineer
unfortunately I didn't take my ESP module to work again :clap: so I can either send you a zipped solution with html or I'll do it myself in the evening
Me No Dev
@me-no-dev
you do have “/404.html”in the file system right?
dragon-engineer
@dragon-engineer
yes :smile:
Me No Dev
@me-no-dev
please do try tonight
dragon-engineer
@dragon-engineer
it serves the file but leaks
ok I will do the test
Me No Dev
@me-no-dev
how big is that file?
dragon-engineer
@dragon-engineer
like 3kB
Me No Dev
@me-no-dev
hmmm then it’s not the SPIFFS bug we have been having...
dragon-engineer
@dragon-engineer
when serving large files?
Me No Dev
@me-no-dev
yes
dragon-engineer
@dragon-engineer
yes I wouldn't expect/torture the ESP with megabytes of files
Me No Dev
@me-no-dev
30K is enough to trigger it :)
dragon-engineer
@dragon-engineer
oh :smile: a different story then
however, I used to been using gzip compression in my project, and when I just updated SDK to the latest, it's all buggy
*have been, damn
I used this scheme: in SPIFFS just GZipped files, delete normal .css/.js . in the SPIFFS static file handlers was normal .js and path to SPIFFS file .js
this worked like charm until I updated
now it sends garbage (plain gzipped text, without decompressing in the browser)
Me No Dev
@me-no-dev
it still might be connected to the same issue. Does the file editor open fine?
if gzip has errors it would not be recognized and decompressed so it will spit crap
dragon-engineer
@dragon-engineer
I haven't try the editor actually..but will do tonight
Me No Dev
@me-no-dev
editor runs from flash and is gzipped
not SPIFFS ;)
dragon-engineer
@dragon-engineer
I thought the memory might have been corrupted somehow so I even tried another NodeMcu module but with the same result. Then I changed the SPIFFS static handler so that it points to the file .js.gz in the filesystem, then it works a little better, no garbage, but it's a 48kB file and two characters in the javascript are wrong.. instead of quotes there is | character, therefor the script won't work.
I triple checked and reuploaded to the flash but still same, cleaned cache but still sends wrong characters (just the same ones)
Me No Dev
@me-no-dev
@matasondrak fixes for SPIFFS are coming ;) hang tight :)
dragon-engineer
@dragon-engineer
great to hear it because it's actually worse than older releases which worked fine :smile: looking forward to it
Me No Dev
@me-no-dev
it’s a brand new bug :D anjoy :D
dragon-engineer
@dragon-engineer
so (no critically important) update created much worse bugs ? :smile: windows users like me know that very well
Me No Dev
@me-no-dev
:D:D:D:D exactly
dragon-engineer
@dragon-engineer
alright, I'll be available for tests when you release some update, I have both 32Mbit and custom resolderes 64Mbit flash variants
when will we be able to use 64Mbit btw?
Me No Dev
@me-no-dev
@matasondrak PR is esp8266/Arduino#3623
oh.. I got some 16MB wemoses as well to test this :) I vote for extending the day to 36 hours instead of 24
24 are way not enough...
dragon-engineer
@dragon-engineer
indeed
all in all, the bug is both in mkspiffs and in sdk?
Me No Dev
@me-no-dev
yes. update was synced across both (well add ESP32 to that too)
dragon-engineer
@dragon-engineer
and the fix is already in release ? I read that you were about to do it 'tomorrow', and it was 2 days ago :smile:
Me No Dev
@me-no-dev
I have actually done it in IDF (work repository and not github) and it’s on it’s way to be merged in IDF any moment/day now. The same is true for ESP8266 and mkspiffs (though the PR is not mine)
dragon-engineer
@dragon-engineer
ok thx for info
Me No Dev
@me-no-dev
so I kept my word :D
Bryce Schober
@bryceschober
@me-no-dev : Do you have any comment on the UDP broadcast being limited to 25ms packet rate vs. UDP unicast?
Me No Dev
@me-no-dev
@bryceschober I was not aware of such limitation
Bryce Schober
@bryceschober
@me-no-dev : I spent a whole bunch of time characterizing the UDP Tx performance of ESP8266 in SoftAP mode, and for some reason broadcasts are essentially limited to a 25 millisecond packet rate, resulting in an effective bandwidth limit of ~58kBps. Unicast transmissions have no such limit, and I've hit a soft limit of around 2.5 MBps.
Which I achieved using your ESPAsyncUDP lib... I could only reach about ~500kBps with the default library.