I had the same problem when I tried a couple days ago, but didn’t report because I thought maybe due to conference WiFi. Will try at home this morning
Any news for this topic?
Regards, Holger
I’ll push a new build soon to see if we can still trigger this.
For now you can use manual method. Update file here
http://download.moddevices.com/releases/testing/modduo-v1.5.0.498.tar
Ok, thx!
Played around with the SDK briefly. I happened to choose the SooperLooper to modify, which was a little awkward without being able to swap the knobs with footswitches:
One minor caching issue is that the thumbnails for the pedalboards containing the modified plugin still have the old GUI:
The SDK wizard only has knobs, and combo-boxes for the ‘boxy’ style.
The screenshots are not a caching issue. You just happen to still have old thumbnail images in place.
Open the pedalboard and save it to trigger a new thumbnail.
SDK wizard only has knobs, and combo-boxes for the ‘boxy’ style.
The choice of Boxy was arbitrary, but AFAICT all the choices only had knobs / sliders available for their controls.
still have old thumbnail images in place
The preview images contain out-of-date information at time of use. In my realm that qualifies as ‘caching issue’. 
Semantics aside, the stale images are a minor visual annoyance but re-saving all affected pedalboards isn’t the best experience. I realize that re-generating all affected pedalboard thumbnails might not be trivial (background process, headless browser, etc.) but could provide a smoother user experience.
1 Like
Yes, that’s what I meant. There’s usually only knobs for all the provided templates, sometimes also have a combo-box.
I’d say, the thumbnails contain an image that matches the setup you had at that point.
Plugin store updates to plugins might change their appearance, which is kinda the same situation here.
In any case, rendering a screenshot is an expensive operation CPU-wise (we’re basically opening a browser window in the background, in the Duo), so this is not going to be automated.
build 502 is here:
- Delete control chain update file if dialog is closed manually
- Fix MIDI CC unaddressing not properly removed from pedalboard
- Initial implementation of backup&restore of user data (via usb stick)
The last item is very experimental. we’re just testing if it actually can work or not.
We also wanted to push a new build to see if the download failure still happens.
Please try to update and report back. Thank you!
Tried a couple times, still getting the download failure for 502. Chrome on MacOS here.
The .tar binary appears to download successfully to a local file blob. The error is coming from the subsequent request to update/download/, which appears to be returning immediately with a status of 0. That status is a bit unusual, but generally indicates that the request was never sent at all either due to DNS failure or CORS problem (among other causes).
I’ve tried in Safari and in Incognito mode to rule out browser extensions.
having the same problem here.
both in firefox and chrome on ubuntu.
coming from build 481 to 502.
I haven’t seen any recent changes in mod-ui that look like they would contribute to the outcome we’re seeing. Not sure if I’m going down the right path, I made some slight changes to how the file data is getting sent, which results in update/download/ succeeding with {"ok": true, "result": true}, followed by a request to update/begin. However, now the device ends up in manual update mode - so the file data probably isn’t getting copied properly. I’m guessing there’s some mismatch between the content types in the backend with the endpoint expecting JSON https://github.com/moddevices/mod-ui/blob/master/mod/webserver.py#L491
I think we’re getting past some limit of file download or copy from browser to ajax (received by tornado webserver).
aaand seems to be the case. there’s a 100Mb file limit
this has some discussion on the topic:
https://groups.google.com/forum/#!topic/python-tornado/izEXQd71rQk
pushed a new build, #503
this one does not have the mod-sdk, thus the update file size is smaller, and auto-updates actually work again.
have to wonder if mod-sdk inside the Duo is worth pushing for or not…
what do you guys think?
Thanks, @falkTX for the updates! IMO having mod-SDK inside the Duo is a nice to have feature and I’d prefer having it. Is is possible to split the files somehow during installation? Or even better: upload the SDK separately via the new settings page?
good news, I was able to reproduce the issue, and fixed it as well.
new build #505 has the fix.
OS updates now stream the data from the browser to the Duo in parts, instead of sending everything at once.
I need a few people to update to this version as soon as possible, so I can put back the mod-sdk into the OS image and test if the update works.
Please let me know when you’ve updated to 1.5.0.505. When we have 5 people with the update installed, I’ll push the next update that includes mod-sdk so we can test it.
success with 505!
…also bumped my external footswitches to 0.2.2…
Success updating to 505
1 Like