mirror of
https://github.com/yusufipk/OpenFrame.git
synced 2026-09-11 09:36:08 +00:00
yusufipek
63288761ed
Two reasons the number on the storage page could read as nothing. The per-user Bunny figure was computed inside a two minute cache. The declared size lands on the row in the same transaction that deletes the reservation, so for up to two minutes an upload that had just succeeded counted as nothing: usage fell back towards zero and the next upload was measured against a total that ignored the one before it. The call to Bunny stays cached, because it is the slow half and its answer is the same for everybody. The join against our own rows is now read fresh, per user, on every check. A failed call to Bunny returned an empty map before it had looked at a single row, so an account with gigabytes of declared uploads read as empty whenever Bunny was unreachable. Bunny's figure being gone is not a reason to forget the sizes we wrote down ourselves. The rule for which of the two numbers to charge is unchanged, and the comment above it now says why rather than guessing. What Bunny reports mid-encode is partial: storageSize counts what has been written so far and climbs as each rendition lands. A six minute cut uploaded at 2.5 GB read as 475 MB halfway through and settled above 3 GB once it finished, because Bunny keeps the original alongside every rendition. Taking the larger of the declared size and Bunny's is right at every point on that curve; taking Bunny's whenever it is non-zero would hand most of the quota back in the middle of an encode. The settings card also claimed a 200 GB limit while showing a 3 GB one, and told a trial account to delete files or contact support.