A movie-night planner looks like a small recommendation feature: choose a few titles and display a schedule. The interesting engineering problem appears when the user adds an end time. Now a recommendation must be feasible, explainable, and honest about missing data.
Consider a Halloween double feature. The user has a 240-minute window, wants two films, and needs a break between them. Sorting titles by popularity does not tell us whether the resulting plan fits. We need to separate candidate selection from scheduling.
Define the time budget explicitly
Represent runtimes and allowances as integer minutes for this small planning model. Keep the session budget, initial setup allowance, and break duration as separate values. A break belongs between two screenings; there is no automatic break after the final film.
For a nonempty schedule containing n films, the required minutes equal the sum of runtimes, plus the setup allowance, plus (n minus 1) times the break duration. Handle an empty selection separately so it produces zero screening time rather than a negative break count.
With a 240-minute window, a 10-minute setup allowance, a 15-minute break, and hypothetical films lasting 95 and 110 minutes, the plan requires 230 minutes. It fits with 10 minutes remaining. Changing the second runtime to 125 makes the requirement 245 minutes, so that pair must be rejected.
The remaining time is useful slack. Do not silently stretch a break to consume it or claim that a full budget is always the best result. The user may prefer a shorter evening.
Treat unknown runtime as unknown
A missing runtime must not become zero. That would make an incomplete record look unusually attractive to the scheduler. Store an explicit missing value and exclude that candidate from schedules advertised as confirmed to fit.
An application can offer an estimate mode, but the interface should identify which runtime is estimated and how it affects the finish time. The user must be able to distinguish a provisional plan from a schedule based on checked values.
Runtime also belongs to the selected version. A title with different cuts may need multiple edition records. A collection's combined runtime is not a substitute for the runtime of one film inside it.
Filter before ranking
Apply hard constraints first: supported playback format, known runtime, the user's excluded content, and any explicit requirement about which titles must be included. Then rank the remaining feasible choices according to preferences such as variety or continuity.
Content exclusions require deliberate treatment of missing metadata. If a user requires a verified exclusion and a candidate's content information is unknown, do not quietly treat “unknown” as “absent.” Ask for review or omit the candidate from automatic selection.
Keep preference scores separate from eligibility. A very high recommendation score should never override the user's declared end time or a required exclusion.
Start with pair enumeration
For a double-feature planner, an elaborate optimizer is unnecessary. Enumerate each distinct unordered pair of eligible titles, compute its required minutes, and keep only pairs within the budget. With m candidates, that means m times (m minus 1) divided by 2 pairs and quadratic time complexity.
Score the feasible pairs and apply a stable tie-breaker, such as their identifiers, so repeated requests with the same inputs produce the same result. If viewing order affects the experience, evaluate the two possible orders separately after checking the pair's basic time feasibility.
Do not quietly reuse the same film twice unless repetition is an explicit feature. Likewise, do not assume every feasible pair satisfies a requested story sequence. A franchise-order requirement needs its own validation.
Explain the result and the failure
A result should show each runtime, setup time, the break, total duration, and remaining minutes. “Fits your four-hour window with ten minutes to spare” is more useful when the numbers immediately underneath let the user check it.
When no pair fits, return an explicit no-result state. Offer changes the user can choose: one film, a wider window, or a different shortlist. Automatically dropping the break or extending the end time would change the request instead of solving it.
For calendar integration, turn the duration plan into timestamps using the user's chosen date and time zone. A same-evening local prototype can work in relative minutes, but a production calendar feature must handle midnight and offset changes deliberately.
Verify the boundary cases
Check that an exact fit passes, a one-minute overrun fails, and an empty selection produces an empty plan. Check that a one-film plan has no intermission, missing runtimes remain ineligible, and invalid negative or fractional inputs are rejected if the model requires whole minutes.
Finally, distinguish catalog browsing from structured scheduling data. Our DVDWholesaleShop US horror catalog provides the retail context for this example; it is not presented here as a runtime API or a verified machine-readable dataset.
The planner's real promise is modest: given explicit inputs and constraints, produce a schedule the user can understand. Keeping unknown values, hard limits, and editorial preferences separate makes that promise much easier to keep.
Top comments (0)