Load to RAM failure on large project file

[zfi]

I am testing an issue with a large project and have hit a snag with the released version of the Launcher 1.0.1. I am seeing a large percentage of load to RAM and load to EEPROM errors with this project. If I revert back to the Launcher 1.0.1 Chrome app, it works perfectly.

After I wrote this up, I went back and tested against a smaller project. Everything worked as expected. I closed the Chrome version of the Launcher and started the MacOS version 1.0.0 and tried it against a small "hello World" project and the larger attached project. Initially, the Launcher would not connect at all. Quitting the Launcher and restarting it didn't seem to help. I abandoned the current project, returned to the SoloDev home page; started the Launcher; then loaded a small project. I was able to load successfully. The same with the larger project attached below. It now loads and runs successfully.

I will continue testing, but there appears to be something different between the Chrome version and the MacOS version.

Also seeing a few of these "Propeller not Found" messages.

Pixy2_X-Y-Axis_Roaming Working Get Object.svg.zip

[zfi]

Spotted more trouble after leaving the AB plugged in for a few hours (not sure that is relevant). I was able to compile a simple hello world project. Loaded another simple project and the compile to RAM failed when loading to the AB. I also switched ports to a FliP module and it was also unable to load to RAM. (Second screen shot).

I quit and relaunched the Launcher 1.0.1 for MacOS Catalina while the simple project remained in Solo. I can now load to RAM and to EEPROM on both devices. I will let this test rig sit overnight to see if I can reproduce the errors again.

[PropGit]

Thanks @zfi.

That's very disturbing. Just to confirm from what I think I see above... the problems only happen with the macOS packaged v1.0.1 and do not happen with the raw v1.0.1?

Testing with your attached object. v1.0.1 packaged app on Windows: 25 download attempts, all successful v1.0.1 packaged app on macOS: 55 download attempts, 1 failed

IMPORTANT FINDING: I noticed that the more downloads I attempted, the slower the whole download process went, though it still succeeded in all but 1 case (which was attempt 14). The download process is generating a lot of log view messages (I have verbose turned on). This makes me think that the log view handling is becoming bogged down by the size of the log; a cumulative time-consumption issue for every new log entry that is added. Since letting it sit there for a while (connected) still generates log entries (for "Sending port" and for "User selected preferred port" events), it stands to reason that there is more likely to be a download problem after simply letting the "connected" system sit for a while.

[zfi]

Correct. The errors occurred only when I used the packaged app on MacOS. The version of the Launcher that is started from within the Chrome browser through the 'Apps' link does not exhibit these errors.

[zfi]

I can also confirm that, when leaving the packaged launcher sitting idle with the logging window closed for hours (571 minutes), it is unable to load even a simple project to RAM. The time it spends loading before failing is a few seconds. Normally this happens much faster.

[PropGit]

Please install BPL v1.0.3. This version limits the log view to 250 most-recent lines (to cap off cumulative processing time) and doubles the end-of-packet timeout to 1000 bytes.

Please report here how this version affects the issues reported.

NOTE: The view log cap causes known problems with scroll bar (user can scroll back, but view shifts for each line removed from the top of the view once it reaches max 250 lines).

[PropGit]

BPL v1.0.4 restores proper log view scroll bar operation while maintaining v1.0.3 changes.

[PropGit]

@zfi - were you able to retest BPL v1.0.3 to see if it resolved the download failures you were having?

v1.0.4 was delivered as a side-load, rather than a wrapped app. If 1.0.3 solves the Mac download issues, I will wrap and release v1.0.4 as it contains the same fixes.

[zfi]

I have been testing BPL 1.0.4. It does not exhibit any issues with projects of any size after 10 hours of operation. Do I also need to test 1.0.3?

[zfi]

And immediately after I posted the comment, I see an anomaly. Launcher is sending port lists after it has detected a site disconnect. I'm not sure if this has any impact on Solo. Also, this is a one-off so far. I will report back if I see more of these.

[PropGit]

Turn on Verbose Logging to see if it's transmitting port lists to a different Socket ID than was is disconnected... of course, you'll have to create the disconnect condition manually to test.

On the v1.0.3 question; not if changes in v1.0.4 are vital to your current testing. I'll wrap v1.0.4 (or v1.0.5) later this week.