Consistent "Service Unreachable" Warnings When Uploading 2K PBR Materials
tracked
NODNOL Jameson
Since June 10th, I have been experiencing a significant increase in "Service Unreachable" warnings while uploading 2K PBR materials exported from Adobe Substance Painter using the glTF PBR Metal Roughness workflow.
The problem seemed to be concentrated between June 10th and June 12th, then improved and became limited to just a few random errors.
Today, June 25th, the problem is back on my end.
I have checked my internet connection, restarted my fiber router, and confirmed that my connection is stable, yet the issue continues to occur.
I can log out and back in, successfully upload one material, and then immediately receive the warning when trying to upload a second one.
If I bulk upload an entire material set, some materials upload successfully while others fail. Sometimes the material upload window gets stuck trying to save, and I can't close it because it appears to still be processing one of the texture maps. At that point, I have to relog.
This issue seems to happen much more frequently with 2K textures. Since my UVs are optimized for that resolution, switching to 1K is not a practical workaround.
Normal maps seem to be affected the most and fail more often, but on days like today I'm also getting errors when uploading base color and metallic-roughness maps.
I know there have been previous posts about this issue, but I believe it continues to resurface and may still require investigation.
Photo Viewer
View photos in a modal
Log In
Maestro Linden
updated the status to
tracked
Maestro Linden
We did some more investigation, and have identified the irritating factor: the L$ service issues blogged at https://status.secondlifegrid.net/incidents/dgl6hn7w19bh are causing some material imports to fail on the initial attempt due to a timeout. The viewer has some retry behavior in place, but is not quite right, resulting in the "Service Unreachable" error.
This issue has been reported previously at https://github.com/secondlife/viewer/issues/4094 , but has resurfaced due to the recent outage.
NODNOL Jameson
Today, June 26th, both Tay Doll and I tried to upload the same .glb file.
This file has two 2K PBR materials inside, we were uploading as "all".
I am attaching both our screenshots, I am in Brazil and he is in USA.
We keep getting the same errors.
Photo Viewer
View photos in a modal
Tay Doll
I also notice that I am having more and more individual failures when uploading materials in addition to more complete failures.
Maestro Linden
Okay, I hit what looks like the same 'Service unreachable' failure mode, after more testing with other materials from that same Khronos samples repo. In this example, I got a "Service unreachable." error when importing AnisotropyRotationTest. This material is comprised of a mix very low resolution (think 1x1) maps, 1024x1024 maps, and a single 2048x1 map.
A given failure event looks like this in the viewer log:
2026-06-26T00:42:26Z WARNING #CoreHttp# llcorehttp/_httppolicy.cpp(403) stageAfterCompletion : HTTP request 0xc13aadc18 failed after 1 retries. Reason: Not Found (Http_404)
2026-06-26T00:42:26Z INFO # llmessage/llcorehttputil.cpp(276) onCompleted : Possible failure [Http_404] cannot POST url 'https://simhost-0bae131d174f83bb3.agni.secondlife.io:12043/cap/d7c051b2-8ee4-e5f9-3199-c840c9084ca4' because Not Found
2026-06-26T00:42:26Z INFO # llcommon/llsdserialize_xml.cpp(411) parse : LLSDXMLParser::Impl::parse: XML_STATUS_ERROR parsing:cap not found: 'd7c051b2-8ee4-e5f9-3199-c840c9084ca4'
2026-06-26T00:42:26Z WARNING # newview/llviewerassetupload.cpp(987) HandleUploadError : <llsd>\n <map>\n <key>http_result</key>\n <map>\n <key>error_body</key>\n <string>cap not found: 'd7c051b2-8ee4-e5f9-3199-c840c9084ca4'\n</string>\n <key>headers</key>\n <map />\n <key>message</key>\n <string />\n <key>status</key>\n <integer>1</integer>\n <key>success</key>\n <boolean>0</boolean>\n <key>type</key>\n <integer>404</integer>\n <key>url</key>\n <string>https://simhost-0bae131d174f83bb3.agni.secondlife.io:12043/cap/d7c051b2-8ee4-e5f9-3199-c840c9084ca4</string>\n </map>\n <key>state</key>\n <undef />\n </map>\n</llsd>\n
2026-06-26T00:42:26Z WARNING # newview/lltoastalertpanel.cpp(197) LLToastAlertPanel::LLToastAlertPanel : Alert: Unable to upload AnisotropyRotationTest (Aniso Tangents): GridWithMarkers (Base Color) due to the following reason: Service unreachable.\nPlease try again later.
Maestro Linden
updated the status to
under review
Maestro Linden
I was able to reproduce _an_ error with Second Life Release 26.2.0.25386466510 (64bit) on SLS 2026-06-12.27437375581.
I used the models from here for testing:
I used the Avocado and AntiqueCamera gltf materials, after verifying that they use 2k textures for all materials.
- My first upload, of Avocado.gltf, was successful.
- My second upload about 30 seconds later, of AntiqueCamera.gltf (all materials) failed partially:
- 'AntiqueCamera (tripod)' material uploaded successfully. A material asset was created in my inventory for it, and has populated textures.
- 'AntiqueCamera (camera)' material initiallyfailed to be created properly. A material asset was created in my inventory for it, but all of the textures are missing in the material slots.
- The error message shown by the viewer is "Alert: Unable to load material". This appears to be caused by the material getting a 403 result when it tries to GET the material asset from the asset CDN - perhaps it tried to GET the material before it was created?
- Looking at the uploaded textures, the 3 textures from 'AntiqueCamera (camera)' were actually uploaded successfully - they just weren't applied to the material item in my inventory for whatever reason.
- When I closed and reopened the (seemingly empty) 'AntiqueCamera (camera)' material in the inventory browser, it appeared properly with all 3 of its associated maps. This makes me wonder if the case I'm seeing is purely a viewer-side bug - perhaps it tried to view the material before it all the assets were in place.
NODNOL Jameson
Maestro Linden Thank you for taking the time to investigate this and for reproducing a similar failure.
Your findings are very interesting, especially the HTTP 404 "cap not found" response and the case where reopening the material later showed all of the maps correctly. That certainly sounds like a viewer/backend synchronization issue.
My experience seems to be slightly different, though, and may indicate an additional problem.
In my workflow I'm uploading large batches of production PBR materials exported directly from Adobe Substance Painter, often hundreds of materials over the course of a project. Once the issue starts occurring, the first upload after logging in will often succeed, but subsequent uploads begin failing with "Service unreachable." Eventually the upload window may become stuck processing one of the texture maps, forcing me to relog before I can continue working.
Unlike the case you described, many of my failed uploads never appear in inventory at all. In other cases, only part of a bulk upload succeeds while the remaining materials fail completely. Relogging temporarily restores normal operation, but the failures return after a few uploads.
Regarding the delay between finishing the texture uploads and the material becoming fully available, I upload hundreds of maps daily. When performing a bulk "All Materials" upload, I always wait for every material to finish loading in my inventory before using them. I know that applying them too soon either results in a warning when I double-click a material in the inventory or causes a blank texture to be applied to the surface.
madi Fray
so hard to keep the business running without being able to perform these tasks. I hope a fix is in the works!