Offline Video On-Deck Queue
While one local video plays, a separate on-deck queue lets operators search, order, and temporarily insert multiple files, then continues automatically through the queue.
Karaoke hosts, teachers, and event video operators are often handed the next song or another clip before the current video has finished. They cannot interrupt the full-screen output, yet must browse folders, remember the order of requests, and make a rushed switch at the end. This offline player moves on-deck work to a separate sidebar while the current video keeps playing. Hosts can search local files, preview thumbnails, and add multiple videos in succession.
Each queued item is a draggable card showing file duration, audio tracks, and estimated playback time. A last-minute request can be marked as a one-time insert: it plays after the current clip, then the player automatically returns to the original queue. To skip a segment, the operator changes only the queue, without risking the projected image. Files likely to fail playback are flagged before their turn, leaving time to swap in backup material.
After an event, the queue can be exported as a reusable playlist or retained as a record of who requested which clip and when. The first release starts with local folders and common video formats, with no streaming song requests or cloud collaboration. It addresses a specific live-use problem: handling a steady flow of next-video requests calmly while one offline computer keeps playing video.
Why now
A September 1, 2026 post in r/androidapps asked whether multiple local videos could be queued while the current video is playing. S1 When recorded that day, the comments had not identified an existing solution, leaving an unmet need for an editable offline on-deck queue. S1
Target user
The primary users are karaoke hosts, classroom teachers, and small-event video operators. They need an on-deck sidebar when a video is already output full-screen and someone hands them the next clip. Opening a new file directly can interrupt the image, while managing the order from memory can cause clips to be missed. Remote and touchscreen use also demands few controls and an unambiguous sequence.
Minimal entry point
Build the first release as a landscape Android app in Kotlin and Jetpack Compose, with a playback area and fixed on-deck sidebar. Use Media3 ExoPlayer as the playback engine; it supports adding, moving, removing, and replacing items during playback. S2 Let the app read user-selected local files through system directory permissions. Keep the original queue and one-time inserts as separate business-layer state rather than merging them into one list. Read thumbnails and durations one file at a time in the background, checking files that are about to play first. Exclude streaming, accounts, and cloud sync; export playlists as local files first.
Punching above its weight
The first users are already active in offline-player, Android app, and home karaoke communities. Demonstrate the workflow in a real landscape screen recording: video keeps playing while clips are added in the sidebar, then a one-time insert plays and the original queue resumes. Return to the original help post to collect feedback on file formats and remote-control use. App store copy built around “queue the next video without interrupting the current one” should better match related searches.
Competitors & gaps
- mpv and its script-based front endsGoogle
- mpv already offers comprehensive playlist commands: it can append files, insert them as the next item, move entries, and delete entries. S3 Adjusting the queue does not have to stop the current playback, making it a viable playback engine. Its JSON IPC also lets external programs control playback and receive events. S3 But these are command-level capabilities. Developers still need to build file search, thumbnails, drag-to-reorder, and estimated start times. One-time inserts require separate state management and restoration of the original queue after playback. Failure preflight, safeguards against accidental actions, and event logs also need to be built separately. The gap is not decoding capability, but a complete control desk for live operators.
- Kodi temporary playlistsGoogle
- Kodi can add selected videos to a temporary playlist and open that playlist from the sidebar. S4 It can also read file details such as duration, audio tracks, and codecs. S4 These capabilities work well for organizing content in a media library ahead of time. But the official documentation centers on browsing pages and sidebars, so a live operator must switch among finding files, checking the queue, and monitoring playback. The documentation also does not describe request sources, estimated start times, or one-time insert behavior. This product can consolidate those actions in a persistent on-deck panel. The current image stays stable, and queue edits do not become playback controls. Reusable playlists and failure alerts further fit classroom and event playback.
How it makes money
Use a one-time purchase model. The base version includes local playback, queue ordering, and playlist export; the premium version unlocks dual-screen output, queue templates, and full event logs.
The case against
Recognizing a local file does not guarantee smooth playback at an event. Unusual containers, corrupted files, or hardware-decoding differences may only surface when playback switches. Checking every file in advance adds battery use, waiting time, and cache-management overhead. If a one-time insert resumes at the wrong position, the rest of the queue shifts out of order. Full-screen output and sidebar focus must also be isolated, or remote-control buttons may accidentally trigger playback controls. When event logs include requester information, users must be able to disable and clear them. Unless recovery from failures is simple enough, this kind of tool will struggle to earn trust in live settings.