Slow loading

[wakkedoff-sys]

Description of the Bug

After upgrading to version 0.1.0 [80097c0], everything loads up slow. I knew that I had to recreate a new[er] DB, no biggie. I slowly started to add libraries and indexing covers. No issue whatsoever, but as the libraries started to increase. The performance took a hit, it started running slower and slower.

When I log in, I see the progress bar on the page start to load from the top left. It slowly creeps to the right to render the items in either "Home" or "Explore". If I try to load a specific library it does the same time. If I leave it there long enough, it will eventually render the items. However if you try to dig in any of the items, to get more details. The page just errors out. I then try to read the log, to see what's going on. But no dice, the log isn't captured at all.

Based on this I stopped adding the rest of the libraries I have. This is what I currently have set up.

Now before any one ask, yes I have restarted Stump & the Mac Mini as well. Nothing else is running on this Mac[hine] expect Stump and Mylarr. Everything was good in the hood & still is. Just this Nuevo issue with Stump.
I've even started over with a nuevo DB and still ran into the same issue; regardless if it's on Web or iPad app. Additionally files are on an attached SAS drive, so I know it's not a speed issue [I/O]. This build was running fine with the prior version of Stump. So I don't know how to fix it? If there is anything you need from my end to help identify the issue, hit me up. More than glad to help out to continue making this app better & better.

MacMini 2018
3.2 GHz 6 core i7
64 GiGs RAM
Sequoia 15.7.5

Expected Behavior

Loading of Libraries, Home or Explore to be somewhat fast. Not loading up a blank page and waiting for it render to continue. Once it loads, if you dig into any of the items, the server app faceplants!

Steps To Reproduce

1. Sign into Stump, either an Admin account or User account. Same issue.
2. Click on either Home, Explore or any Libraries to within the loading/rendering of items.
3. Try to click on any item to get more details on it, once it loads.
4. Page errors out, crashes & when you try to look at the logs. No dice, they ain't there.

Where is this issue happening?

• Web App
• Mobile App
• Server

Server & Client Details

Server Details:

• Release Channel: release
• Server OS: macOS Sequoia 15.7.5 [Intel]
• Using Docker: No
• Server Version: 0.1.0 [80097c0]

Client Details:

• Device: macOS 26.4 [MB Airs, MB Pros] all M-Class
• OS: iOS 26.4 iPadPro
• Browser: Safari [21624.1.16.11.4]

Additional context

No response

[aaronleopold]

So first I wanna say that you aren't alone, I have gotten at least one other report of similar performance but the person had a library magnitudes larger than yours (which is relatively close in size to mine) with something like 160k+ books so I kinda assumed it was exacerbated because of that. I haven't quite sussed out what might be happening, though, since functionally I don't think things have meaningfully changed which would impact performance from the big SeaORM migration away from Prisma.

I think this is something that will just, unfortunately, take some time to do thorough debugging. If you don't mind, I think a start could be:

1. Bump the verbosity of server logs, clear it, and try loading up the home page to capture its output
2. Send me your database so that I can try to see if maybe there are inefficiencies in queries
3. Try and fudge all the paths in the database for books so that we can isolate thumbnail issues from database issues (e.g., it would make the UI not load any images if no thumbnail_path is set and the path is not pointing to the book)

Since you said it happens for both the web app and the mobile app, I am inclined to think this is a server-side issue to sort out.

I'd also appreciate anyone onlooking with comfort on that side of the stack to help with the investigation, as I expect it to be a bit of a long-tailed investigation just by myself.

[wakkedoff-sys]

Aaron, Fair e’nuff & it sounds like a plan. I dig the changes with version 0.1.0. It looks better! So I’m digging it. Sure thing, don’t mid helping & understood these things will take time to suss out. 1. Bumped to leve 3 in .toml 2. Will send db shortly, trying to see if I can capture a log. So I can attach it as well. 3. I a little lost on this step. Can you provide some more guidance with this step. ~L0$

…

On Apr 4, 2026, at 2:22 PM, Aaron Leopold ***@***.***> wrote: aaronleopold left a comment (stumpapp/stump#1047) <#1047 (comment)> So first I wanna say that you aren't alone, I have gotten at least one other report of similar performance but the person had a library magnitudes larger than yours (which is relatively close in size to mine) with something like 160k+ books so I kinda assumed it was exacerbated because of that. I haven't quite sussed out what might be happening, though, since functionally I don't think things have meaningfully changed which would impact performance from the big SeaORM migration away from Prisma. I think this is something that will just, unfortunately, take some time to do thorough debugging. If you don't mind, I think a start could be: Bump the verbosity of server logs, clear it, and try loading up the home page to capture its output Send me your database so that I can try to see if maybe there are inefficiencies in queries Try and fudge all the paths in the database for books so that we can isolate thumbnail issues from database issues (e.g., it would make the UI not load any images if no thumbnail_path is set and the path is not pointing to the book) Since you said it happens for both the web app and the mobile app, I am inclined to think this is a server-side issue to sort out. I'd also appreciate anyone onlooking with comfort on that side of the stack to help with the investigation, as I expect it to be a bit of a long-tailed investigation just by myself. — Reply to this email directly, view it on GitHub <#1047 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AUM6SHYP456BYQBO6E5DM4T4UFHFLAVCNFSM6AAAAACXMYOYIWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DCOBXGUZTKNBWGQ>. You are receiving this because you authored the thread.

[aaronleopold]

I a little lost on this step. Can you provide some more guidance with this step

If you could do something like:

update media set thumbnail_path = NULL;

update media set path = '/somefakepathtomakeitfail' || path;

The first one just kills the path reference to each books corresponding generated thumbnail, the second prepends a string to the path that will definitely make it fail to resolve and mark books as missing. Together, no thumbnail path + unable to locate file, stump will not be able to send thumbnails to the client and therefore provide a scenario for us to test the loading of your libraries without thumbnails in the mix.

Edit to add that obviously this is manual database manipulation, so of course only do it if you are okay either manually correcting or starting from scratch