F34.us Content Aggregator Prototype

The Inbox Before the Library

How MixMan combines bounded uploads, deduplicated imports, acquisition provenance, explicit human edits, quality gates, and recoverable promotion.

Adding music to a library looks like a small action until the library is expected to last. A file may arrive with incomplete tags. A pasted link may be a duplicate, include irrelevant playlist parameters, or resolve to a different canonical page. A search is even less certain: it describes an intention, not a recording. I designed MixMan's ingestion flow around that uncertainty. New audio goes to an inbox before it becomes part of the trusted collection.

The boundary begins at submission. Direct uploads are limited while their multipart data is still arriving, checked against allowed audio formats, and inspected for a plausible file signature. Link imports accept only supported providers, normalize common URL variations, and check both the main catalog and the review queue for an existing item. The job queue also deduplicates active work. This makes repeated clicks and equivalent links routine cases rather than opportunities to create parallel copies.

Search-based imports preserve an especially useful distinction: what the person typed, what the downloader was asked to resolve, and the permalink ultimately discovered are separate facts. Direct uploads similarly retain the submitted filename without treating it as catalog metadata. MixMan records these facts in an acquisition ledger alongside the provider, import mode, background job, and correlation method. The ledger follows an item from review to promotion, can follow it back into review, and detaches rather than disappearing when an item is rejected. The catalog can therefore answer not only “what track is this?” but “how did this copy enter the system?”

The audio itself receives a lifecycle identity in addition to its content hash. The hash makes an identical re-upload idempotent, while the lifecycle identity distinguishes a genuinely new review episode from an older one that happened to involve the same bytes. Files are written through a temporary path and atomically renamed into the review area. If database persistence fails, cleanup checks whether that exact lifecycle was committed before removing anything. These details matter because a database row and a media file cannot participate in one native transaction.

Inside the review queue, enrichment is assistance rather than publication. Background jobs can extract tags, analyze audio, and propose metadata while the item remains playable and inspectable. Promotion checks required fields, configured approval rules, analysis readiness, and severe quality warnings. A failed primary analyzer can fall back to narrower legacy analyzers instead of leaving the item permanently stranded. The queue is therefore a working surface: uncertainty can be reduced without giving incomplete material the same status as a curated track.

Human editing also has an explicit contract. The player submits only fields that were actually touched; merely displaying a hydrated form does not manufacture edit intent. A set operation records human provenance even when the visible value is unchanged, because submitting it is a claim of ownership. A clear operation removes both the value and its provenance, making the field available to later automation. All operations in a submission are applied together before MixMan re-evaluates promotion. That distinction prevents a familiar class of accidental overwrites in forms that resend an entire object.

Promotion is the sharpest edge of the workflow. MixMan stages and publishes the media before entering the short database transaction that creates the catalog track. A durable terminal-transition row, unique to both the review lifecycle and operation, fences promotion against simultaneous approval or rejection. An optimistic review revision catches edits that landed after the decision began. In the same commit, current analysis is copied to the new track, acquisition records are repointed, follow-up work is queued, and the review row is deleted. If the outcome becomes uncertain after a database error, the recorded operation can be reconciled instead of guessed.

This architecture turns “upload a song” into a controlled passage from evidence to trust. The lift is not just a cleaner queue. Duplicate work is bounded, origin survives catalog movement, human decisions outrank background guesses, and promotion has a recoverable meaning across storage and database boundaries. That gives every later feature—search, recommendations, sessions, and downloads—a more dependable library to work from.

F34.us Background Image