Thumbnail preview cleanup not calculating correctly?

[naivchan]

hello, I was testing the new Thumbnail Cleanup feature in version 0.8.0, and I see some odd behavior where it's not calculating the number of thumbnails to cleanup properly:

I haven't cleaned up anything, so all of these thumbnails are from after 4/10/2026. It initially showed 240-ish thumbnails when I picked a date like 4/17, but now it's only showing 1-4 items, even when I try to refresh and hit the preview button again.

I haven't clicked the "clean" button once in the new feature.

I ran my own check media script,

#!/bin/bash
echo "--- System Vitals ---"
df -h -x overlay -x tmpfs | grep '^/'
echo ""
free -h | grep -E "Mem:|Swap:"
echo ""
echo "--- Media Breakdown (Postgres) ---"
docker exec -it hollo-social-db-1 psql -U hollo -c "
SELECT
 CASE WHEN url LIKE '%pomnavi.net%' THEN 'Local (Yours)' ELSE 'Remote (Cache)' END AS type,
 COUNT(*) AS count
FROM media
GROUP BY 1;"

and got this output:
--- System Vitals ---
/dev/sda1 75G 17G 56G 23% /
/dev/sda15 253M 146K 252M 1% /boot/efi

Mem: 7.6Gi 2.5Gi 803Mi 635Mi 5.2Gi 5.0Gi
Swap: 2.0Gi 1.2Mi 2.0Gi

--- Media Breakdown (Postgres) ---
type | count
----------------+-------
Local (Yours) | 35
Remote (Cache) | 4980
(2 rows)

[naivchan]

I ran the preview for 4/12 and it only found 1 item.

I ran the cleanup for 4/12 and it only cleaned up 1 item as well:

I then ran the preview again for 4/14, and it found a more reasonable number of items that it didn't find on the later date, 4/25.

[aliceif]

local vs remote in this logic is counted by whether the originating post was made by a local user or not - not by the URL

the top statistic is to just give an overview of the total number of thumbnails involved, not how many are cleanable (in order to not slow down page loads, it only does the age and not already clean checks - not the extra checks across multiple tables that check for bookmarks, likes, etc.)

This is what my intended resulting SQL should about be like, and I too get a mismatch between what the preview method does and what this gives (by tens of thousands) ... so there must be something wrong with the query as written in ORM syntax, probably.

select 
media.*
from media
inner join posts mp on media.post_id = mp.id
inner join accounts on mp.actor_id=accounts.id
where(
not media.thumbnail_cleaned
and media.created < '2026-04-01'
and media.thumbnail_url ilike 'https://minio-hollo.x27.one/hollo-live%'
and not exists (select * from account_OWners where accounts.id = account_OWners.id)
and not exists (select * from bookmarks where mp.id = bookmarks.post_id)
and not exists (select * from likes where mp.id = likes.post_id and exists (select * from account_OWners where account_OWners.id = likes.account_id))
and not exists (select * from reactions where mp.id = reactions.post_id and exists (select * from account_OWners where account_OWners.id = reactions.account_id))
and not exists (select * from posts as sharing where mp.id = sharing.sharing_id and exists (select * from account_OWners where account_OWners.id = sharing.actor_id))
and not exists (select * from posts as quoting where mp.id = quoting.quote_target_id and exists (select * from account_OWners where account_OWners.id = quoting.actor_id))
);

[dahlia]

I think there are two separate issues here.

The difference between the statistics table and the preview result is expected. The statistics query only checks thumbnail_cleaned, whether the thumbnail URL is under STORAGE_URL_BASE, and whether the owning post is remote. The preview/cleanup query also excludes bookmarks, local likes/reactions, local boosts, and local quotes.

The very small preview numbers look like a separate display bug. In the preview POST, the count is stored in the redirect URL using mediaWithThumbnailToClean.length.toLocaleString("en"). So a count like 4,980 is written to the query string. The GET handler then reads it with Number.parseInt(c.req.query("fileCount") ?? "0"), and Number.parseInt("4,980") returns 4. Likewise, 1,234 displays as 1.

That lines up with the report: counts below 1,000 would look reasonable, while counts at or above 1,000 would display as a one-digit number from the start of the formatted string.

I also checked the SQL generated by getMediaWithDeletableThumbnails(). It matches the SQL intended by the comment above. In particular, posts.accountId maps to the posts.actor_id column, so that part is not a separate issue.

The /thumbnail_cleanup/clean path calls getMediaWithDeletableThumbnails() again and creates job items from the raw array length, so this specific comma/parseInt bug should only affect the preview display, not the cleanup job size.

The minimal fix is to put the raw number in the URL, for example String(mediaWithThumbnailToClean.length), and only call toLocaleString() when rendering the count.

[dahlia]

This has been fixed in Hollo 0.8.1. The cleanup preview now keeps the raw thumbnail count through the redirect and only formats it when rendering, so counts over 999 should no longer be truncated.