DVR Pro

Watch out

• Deleting a recording deletes the file. DELETE on a timer removes recording_path from disk plus its .original*.ts and .overcut*.ts siblings, then the DB row. To stop a running recording and keep it, use "Finish", never "Discard".
• Each AI end-of-programme check is cut off after 25 s, so a slow AI service can no longer hold up other timers. Two failed checks end the recording on its scheduled time.
• Detection, subtitles and cuts wait while a recording runs or someone is watching, even inside the quiet window; a job that is already running stands down and is re-queued when a viewer appears. The AI render queue card's own help text still says only a recording holds jobs back inside the window — ignore it.
• While a cut is scheduled the review is frozen; press "Run now" or "Cancel cut" to edit again.
• The Comskip lane in the editor is always empty: Comskip is not part of the AI image.
• Deleting a recording that has been published to the library is refused with 409 ("This recording is published to your library as … Deleting it would remove that file"). Remove it from the library first, or delete with force=1 — which then deletes the file AND the movie/episode row.
• Retention silently does nothing for most timers. The cleanup query joins dvr_timers.dvr_profile_id to dvr_profiles, so only recordings whose timer explicitly names a profile can expire. A timer saved with the "Default Profile" option stores dvr_profile_id = NULL and is kept forever regardless of any profile's Retention Period. It also skips anything already promoted to VOD/Series (so library content is never expired out from under viewers). The sweep runs once per calendar day inside the DVR engine; there is a POST /api/dvr/retention/run endpoint but no button in the console.
• A timer can move to Movies or file into a Series, never both — the API returns "A recording can be moved to VOD or to a series, not both".
• Timers can only be edited while status is "scheduled". Once recording or completed, PUT returns 409 "Only scheduled timers can be edited" (console toast: "Only scheduled recordings can be edited").
• "After recording" is licence-gated at save time, not at the dropdown: choosing "Move to Movies (VOD)" calls require_feature('vod') and "File into a Series" calls require_feature('series'), so on a tier without them the save fails with a feature error.
• The whole DVR view is behind require_feature('dvr') — Pro and up. The 'ai_ad_removal' feature key exists in the Business/Enterprise tier lists but is never checked in code, so ad detection and review are available wherever DVR is.
• The auto-record engine only ever looks 7 days ahead. If your EPG source has less coverage than that, a rule that looks correct will simply create nothing until the guide fills in — "Run Auto-Record" answering "No new timers found" usually means missing EPG, not a broken rule.
• The Modules page "DVR / PVR Recording" toggle writes dvr_module_enabled, which nothing reads. It does not disable DVR.
• Recordings open in about a second and jump straight to any point (2.9.316); subscribers need no app update for that. The server measures each recording's real length and codecs when it finishes; older recordings are measured in the background the first time a player lists them.
• The web player (/tv) needs a recording prepared as HLS first. The first viewer sees a "preparing" card with progress while the server builds it. Finished builds are kept in the dvr folder under the VOD HLS Transcode Cache Path (Settings → General), 60 GB in total by default (setting dvr_hls_cache_max_gb), and the least recently watched go first. To build each recording as soon as it finishes, set dvr_hls_prebuild to 1 (off by default; it covers recordings of the last dvr_hls_prebuild_days = 7 days). These settings have no console field: set them through the settings API (PUT /api/settings).
• The BGPVR Player app (1.7.8 and later) shows the free space of the recording disk beside the recording count (2.9.315). To hide the free space, set dvr_client_show_free to 0 through the settings API.
• Watch progress and "watched" marks for recordings are kept on the server per profile and shared by all of the household's devices (2.9.315; BGPVR Player app 1.7.8 and later, web player 4.2). A recording is marked watched once playback is closer to the end than its post-padding plus one minute (at least 2, at most 15 minutes). The marks go with a deleted profile or account; Backup → Database maintenance removes those of deleted recordings after a day and any mark nobody touched for a year. New recordings also carry the guide's description and category into the subscribers' recordings list.
• Ad Review "New editor (beta)" (2.9.345): a switch in the editor, under the recording's name in the classic editor and at the top right of the new one. Switched on, the editor fills the window: the player and an edge preview (the frames either side of the selected cut edge, with buttons to move the edge by a frame or a second and "Back to detected") beside the cut list, and the timeline across the whole width with an overview strip of the whole recording (drag its frame to move the zoomed view). Drag the two dividers, or move them with the arrow keys when focused (double-click resets); "Bigger player" and "Bigger edge frames" set 70/30. The choice and both divider positions are kept per console login on the server, so each operator switches for themselves. The classic editor stays the default. Drafts, applying the cut (now, tonight or at a set time), rejecting and the AI feedback work the same in both, and switching keeps the draft (unsaved edits are saved first). On a screen under 640 px wide the new editor only lists the cuts. The edge frames are exact since 2.9.346 (below).
• Ad Review thumbnails (2.9.345): the timeline's pictures come from picture sheets the server makes once per recording, after ad detection finishes or the first time the editor opens it, so zooming and scrolling never reload or blank them. It makes one at a time at the lowest priority and waits while the box is above the AI queue's load limit or while 3 or more viewers are watching; until then the timeline shows the older thumbnails. The sheets are kept under ai_output/ad_review_sprites and are deleted when the recording is deleted in the console or by the nightly clean-up (its keep period, or a rule's "Keep at most"); a cut recording gets new ones.
• Viewers' Start early / Stop late (2.9.345, for BGPVR Player 1.8.6 and later): the app can ask for up to 30 minutes before and after a programme. The recorder then uses the larger of the viewer's minutes and the DVR profile's "Start early" / "Stop late", so the profile is the minimum for viewers' recordings. Exactly 2 minutes early or 5 late (the old default) count as no choice: the profile's padding alone. Recordings scheduled in the console, by auto-record rules, from a MAG box or from an older app get the profile's padding, as before. Saving a viewer's recording in the console's editor sets it back to the profile's padding.
• Ad Review exact frames and cuts (2.9.346): the new editor's edge preview shows the exact frames either side of a cut edge (last kept | first cut, last cut | first kept), and its frame buttons move the edge by whole frames at the recording's own frame rate. Once you have started the player, the frames come from a hidden copy of it, checked frame by frame; otherwise the server makes them. An edge at the very start or end shows "Start of recording" / "End of recording". Apply Cut now cuts on that frame: about a second of picture at each edge is re-encoded and the rest is copied as it is; the kept audio track is re-encoded once, in its own format, so it stays in step; the .original backup is kept as before. Each cut file is checked (every kept frame there, evenly spaced, the audio as long as the picture) before it replaces the recording. When the exact cut cannot be made (for example an H.264 channel without IDR frames and a kept part longer than 60 s, or a failed check), the recording gets the old keyframe cut (about ±0.5 s) and the ad-removal job's result says why in cut_fallback_code (empty when the exact cut ran). Apply is refused for a recording that changed after the editor was opened (cut or replaced): close the editor, open it again and check the cuts.
• Ad Review cuts keep every sound and subtitle track (2.9.349): cutting the adverts out of a recording (the frame-exact cut, and the older keyframe cut it falls back to) now keeps every audio track with its language (on HBO, for example, Bulgarian MP2 and English AC-3 5.1), the DVB subtitles and the teletext. Before 2.9.349 a cut recording kept the picture and one sound track only. The recorder itself has kept every track since 2.9.228 (5 August 2026): recordings made before that, and recordings cut before 2.9.349, cannot get their tracks back. A recording is not cut, and stays as it is with the reason on its job, when no sound is seen in its first seconds or when an extra sound track stops long before the end. A recording that lists a sound track which never carries sound now also plays as a TV stream in BGPVR Player 1.8.6 (it stopped with an error).
• Ad Review thumbnails status (2.9.346): until the picture sheets are ready, the editor (classic and new) says so in the timeline's toolbar: "Preparing thumbnails…", "Thumbnails wait: N live viewers" or "Thumbnails wait: server busy". It says nothing once they are in, or if the build failed (the older thumbnails stay). A recording in progress no longer holds the build back: it waits only while the load is above the AI queue's limit or 3 or more viewers watch live.
• Interlaced recordings in the web player (2.9.346): when the server prepares an interlaced recording (MPEG-2 576i, H.264 1080i) for the web player (/tv) or the console's player, a graphics card decodes it, deinterlaces it frame for frame (25 frames stay 25, so Ad Review's frame numbers do not change) and encodes it with NVENC. The server takes the card with the least NVENC load, then the least memory in use, and skips a card above 80 % NVENC load, one with under 512 MB free, or a GeForce at 3 sessions. It never deinterlaces on the processor: with no card free, a file the card cannot decode, or after a build on the card failed, the recording is prepared as before (combed), the log says why once, and that copy stays until the recording changes. Recordings prepared before 2.9.346 are prepared once more the next time they are opened (the "preparing" card shows again for a short while), or in the background when dvr_hls_prebuild is on. Films and episodes get it on their next preparation; their older copies go after 7 days unwatched.
• Light version of recordings (2.9.346, for BGPVR Player 1.8.6 and later): the server can send a viewer an HD recording in a light 720p version (H.264, about 4.5 Mbit/s) made on a graphics card; app 1.8.6 picks it on small boxes or slow connections, and nothing changes for older apps or the web player. It is made the first time a viewer asks for it, one recording at a time on the server (the others wait their turn), several times faster than real time, and playback starts once the first part is ready. It is made only on a graphics card: with no card free the viewer plays the original. The light copies are kept in dvr_light under the VOD HLS Transcode Cache Path, count towards dvr_hls_cache_max_gb, go after 7 days unwatched or with the recording, and are made again after an ad cut. The app offers it only when the server's access answer says recording_light.
• Recordings as a TV stream (2.9.347, for BGPVR Player 1.8.6 and later): the server sends a recording to app 1.8.6 the way it sends a live channel, from any point in it: a short head start (15 seconds of the recording at once), then a little faster than it plays (1.1x), so it plays smoothly on small boxes and over long distances. A jump in the recording starts the stream again from the new point. Every sound and subtitle track of the recording comes with it (every language, DVB subtitles and teletext), so the viewer picks them as on the TV; with the light version the picture is the 720p one made on a graphics card and each sound track AAC stereo. Each stream counts as a viewer for the AI queue and the Ad Review thumbnails, never against an account's connection limit; an account streams up to 4 recordings at once, and each of the viewer's devices plays one stream (a jump replaces it). Older apps and the web player are unchanged. The app uses it when the server's access answer says recording_stream.
• AI queue health (2.9.348): ad detection finishes again on long recordings. Its repeated-ad check (the audio fingerprint, compared with the channel's last 45 days) used to spend up to two hours writing to its database behind the AI container's disk limit, so 2.5-3 hour recordings ran out of time at exactly 2 hours; it now writes in one ordered pass and takes minutes. It also has its own limit of 15 minutes: when the disk is too busy it stops, nothing half-written is kept, and ad detection carries on with the other signals (the job's result shows the fingerprint step as timeout). The AI container now lets a job run up to 3 hours 10 minutes and the queue waits at most 3 hours, so the queue always gives up first and says why; an ad detection or ad cut the queue has stopped waiting for (its own limit, or a restart that started the job again) stops at its next progress report instead of running beside the next one, and a cut then leaves the recording as it is. An ad detection that stands down for a live viewer goes back into the queue instead of counting as failed. Recording pictures (thumbnails) skip a frame that takes too long and use the others; the job fails only when no frame comes at all.
• Kodi with the Tvheadend HTSP Client (2.9.351): Kodi lists a subscriber's recordings under TV → Recordings and plays them: their own, and the server's when their account or package shares them, on the channels of their package. Record in Kodi's guide, or on the channel being watched, schedules the recording with the app's checks (DVR in the package, the channel in the package, the adult PIN lock, the duplicate rule); Kodi's start and end margins count as the viewer's Start early / Stop late (0 = the profile's, at most 30 minutes). Kodi's Delete and Stop act only on the subscriber's own recordings: Stop ends a running recording and keeps it, and never deletes a finished one. Changes made anywhere (the app, the console, auto-record rules, the recorder) reach Kodi within 30 seconds. Not offered from Kodi: editing a timer or a recording, a disabled timer, playing a recording before it has finished. An anonymous LAN session (htsp_allow_anonymous) lists and plays the server's recordings and changes nothing. Each Kodi recording request is logged as an HTSP DVR line with ids only. Nothing changes in a Kodi setup: the same HTSP port (9982), the same login.
• Light version starts at once after an update (2.9.353): before a graphics card makes the light version for the first time, its deinterlacing and resizing programs have to be prepared for that card, which takes several seconds of processor work, and every update starts the server afresh. The server now prepares them on every graphics card as soon as it starts, so the first viewer who picks the light version after an update no longer waits for it (on 21 October the first light stream after an update did not start within 20 seconds, and the app played the original instead). The log shows Light warm-up: card N ready in Xs for each card; a card that fails is named there with the reason, and the light version on it is then prepared the first time a viewer asks, as before.
• Quality button in BGPVR Player 1.8.6 (2.9.353): the app's recording player has a Quality button (Full / Light) when the server can make the light version of the recording (the access answer's recording_light). Full plays the original, Light the 720p version made on a graphics card. A light start that fails is tried once more, then the original plays; when the viewer chose Light with the button (or after Auto's switch), the app says "Light is not available now, playing Full". With the app's Recording quality on Auto (recommended), a small TV box (under 2 GB of memory, or one where a recording stalled before) starts recordings in Light; if it had to fall back to the original and that stalls repeatedly, it switches to Light with the note "Switched to Light for smoother playback". Other devices on Auto play the original, and their viewers use the Quality button.
• A viewer's delete removes the recording's file (2.9.354): when a viewer deletes their own recording (in the app, with Kodi's Delete or on the MAG box), the server now deletes its file too, with the ad cut's .original / .overcut copies, the outputs its AI jobs made (subtitles, thumbnail, normalised sound, ad and chapter reports), its light and web-player copies, its Ad Review thumbnails and its row in the audio-fingerprint store; before, only the row went and the file stayed on the disk or NAS. In the app and Kodi it is refused while the recording is still being made; on the MAG box, Delete during a recording stops it and keeps what was recorded, and a second Delete removes it. It is refused while a job is working on the recording (an ad cut, an AI job): the viewer is told to try again when that has finished, and a job still waiting for the recording is cancelled with it. A series rule's removed episode stays as a placeholder, so the rule does not record it again. The file stays (only the row goes) when it is in the Films / Series library, another recording uses it, or it lies outside every DVR folder; a report another recording also uses stays too. The server's shared recordings and other viewers' are never touched, and a Stop in Kodi or on the box never deletes a recording. Each delete is logged with the account and recording ids only.
• Ad Review on a tablet (2.9.359): the editor (classic and new) has a Full screen button (in the dialog header, or at the top right of the new editor): the whole editor fills the screen, with the browser's bars gone, and the button or Esc brings them back; closing the editor leaves full screen. On an iPad (iPadOS 16.4 or later) Safari adds its own X in a corner and a swipe down also leaves full screen; an iPhone has no full screen for pages, so the button is not shown there. With a finger: tap or drag the ruler or the thumbnails to move the play line, drag along an empty part of the cut lane to mark an ad, drag near a cut's edge (it no longer has to be the thin handle) to move it, hold a cut for its menu (Start here, End here, do not cut), pinch the timeline to zoom; on the picture, swipe for 1 second back or forward, double-tap its left or right half for 5 seconds, tap to play or pause. Start here and End here are also toolbar buttons now; on a touch screen every editor button is at least 44 px. The keyboard shortcuts are unchanged, and the gestures are listed under Shortcuts (?). Marks are kept on the device until the server has them: the editor always shows "Saving…", "Draft saved", "Offline — kept on this device" (sent by itself when the connection is back) or "Couldn't save — tap to retry", and Apply waits until they are saved. Marks that never reached the server are offered the next time the recording is opened (this device's or the server's). While a detection or cut runs, the editor shows one progress line ("Detecting ads… 42%") instead of reloading itself every few seconds; it opens fresh once when the job ends.
• Ad Review edit copy for tablets (2.9.360, the server part): to mark adverts on an iPad or another tablet without streaming the recording from the server, the console can ask for a small copy of the recording that the tablet downloads once, keeps and plays itself: 960x540, H.264 at about 1 Mbit/s with AAC stereo sound (the first sound track), a key picture every half second so it jumps exactly to any point, about 1.2 GB for 2.5 hours. It keeps the recording's own timing, so a mark set on the copy is the same second in the recording; only the marks go to the server, which cuts the original as before. It is made on a graphics card only, when asked, one at a time on the server and after a light version a viewer is waiting for, in about 9 minutes for 2.5 hours of HD on the Quadro P1000; with no card free, or a file the card cannot read, the page plays the recording as before. A build that stops making progress for 5 minutes is stopped, and a copy shorter than the recording is never kept. The tablet keeps the copy in the browser's own storage, carries on a broken download where it stopped and says when the browser has no room; Safari may delete a site's stored data when the iPad runs short of space, or after 7 days of Safari use without a tap on the console, unless the console runs from the Home Screen. The copies are kept in dvr_editcopy under the VOD HLS Transcode Cache Path, count towards dvr_hls_cache_max_gb, go after 7 days unused or with the recording, and are made again after an ad cut. The Ad Review page offers the download in the release that adds its tablet controls.
• Ad Review on a tablet, round 2 (2.9.361): the player's controls (previous / next cut edge, −5 s, −1 s, −1 frame, play / pause, +1 frame, +1 s, +5 s, Preview cut) and the time / length now show as soon as the editor opens, also in full screen; before, they appeared only after Load player. Play loads the player and starts it (the server prepares the recording only then, as before). On a touch screen the classic editor puts the timeline right under the picture and the analysis panels after it, so the picture stays in view while you scrub; the new editor already had that order, and a mouse keeps the classic side column. While a finger drags on the timeline, a large time bubble rides above the finger with the time under it (the finger covers the ruler's own label), and the picture follows; dragging a cut's edge also moves the play line to that edge. Two fingers work as in a map: moving them sideways together scrolls a zoomed timeline and never zooms, spreading or closing them zooms around their centre. The keyboard shortcuts now work wherever the focus is in the editor (they used to need a click on the timeline first, so they seemed not to work after opening the editor, Load player, a click on the picture or in the cut list, or Full screen); a text field, a dialog or menu, and Space / Enter / arrows on a focused button or divider still keep their own keys.
• Ad Review tools (2.9.362), with a mouse, a finger or the keyboard, in both editors and in full screen: pick several cuts (Ctrl- or ⌘-click adds one, Shift-click a range; on a touch screen tap Select, then tap the cuts; a check shows on each, with an "N selected" chip and Clear; Esc clears). Merge (M) joins the picked cuts, and anything between them, into one cut from the first start to the last end (with one cut selected: with the next one, as before); the merged cut keeps the first cut's kind and detected start, the last cut's detected end, the highest confidence, and is cut if any of them was. Delete and Keep (do not cut; X) act on every picked cut. Split (S) cuts the cut under the play line in two. The toolbar's Start / End (E) chooses an edge of the selected cut, and −1 s / −1 f / +1 f / +1 s ({ < > }) move it by a second or by one frame of the recording, with the picture on that edge; in the new editor this is the same edge as the edge panel's. Previous / next cut (P / N) puts the play line on a cut's start. Merge gaps (G) asks in the page for a number of seconds (2 by default) and joins neighbouring cuts closer than that, which cleans up the small fragments detection leaves; a cut is never joined with a do-not-cut block. Every action is one Undo step and is saved like any edit (kept on the device when offline). Dragging the play line, a cut's edge, a whole cut or a new cut into the last 48 px (finger) or 32 px (mouse) of a zoomed timeline scrolls it on by itself, faster the deeper, and stops at the start or end of the recording, out of that zone, or when you let go. On a touch screen Select also shows All, and Ctrl+A (⌘+A) on the timeline picks every cut. All the keyboard shortcuts now also work on a Bulgarian (Cyrillic) keyboard layout: a key that types a Cyrillic letter or other non-Latin character is read by its place on the keyboard (the key that is J on an English keyboard works as J), while a Latin layout keeps its own letters.
• Speed Editor in Ad Review (2.9.392): the device works only in Chrome or Edge on a computer, because the browser must offer WebHID (Firefox and Safari show "Speed Editor: Chrome or Edge"; the PC keys work there). A tablet or phone keeps today's editor, with a grey "Speed Editor: on a computer" chip on the tablet. One program at a time can hold the device, so close DaVinci Resolve and any other tab that uses it first. Markers (colour and note) and split points are kept on the server for the recording as it is now; after Apply Cut they belong to the old file and are not shown on the cut one. Key maps are checked on the server (unknown keys and actions are dropped, 16 KB at most), and only an admin can save the operator default (a staff account gets 403). The battery level shows only over Bluetooth, and Bluetooth through Chrome is not proven yet.
• Ad Review merges teach the detector correctly (2.9.364): when you merge cuts (Merge, Merge gaps) and apply, the detections the merged cut absorbed now count as confirmed parts of one advert, not as detections you rejected, and the merged cut is compared with the outer edges of the detections it covers, so the channel's learned edge correction only changes when you really moved the first start or the last end. A detection you left out (do not cut) still counts as rejected; a merged cut you later split or shrank only confirms what it still covers; a cut you drew that took in detections is no longer counted as a missed advert. Older drafts and edits made before 2.9.364 are learned as before. Merges applied before 2.9.364 are not corrected after the fact: the channel's learning keeps only its last 40 edge corrections per kind, so their effect fades as you review.
• Ad Review: the copy on this device (2.9.369): both editors and full screen have "Download to this device". It first shows the room the copy needs and the room the browser has free, then the server's progress (queued with its place, or building with a percentage and the time left), the download (MB of MB; a broken download carries on where it stopped, "resuming…") and "Ready on this device ✓". From then on the player, the frame steps and the new editor's edge preview play the copy on the tablet with no trip to the server, also with no connection; a mark lands on the same frame as on the server, is saved as before and waits on the tablet while it is offline. A badge by the player says "Local copy" or "Streaming". A recording that already has a whole copy on the tablet uses it at once when it is opened again; opening the editor never starts a copy by itself. When the copy cannot be used (the browser cannot store it, not enough room, the server cannot make one, the connection kept failing, the session ended, the browser removed it) the page streams the recording as before and says why in one line. "Copies on this device" lists each copy with its size and a Delete, and says whether the browser keeps them for sure; on an iPad, add the console to the Home Screen and open it from there so Safari does not remove them.
• Pictures for the apps (2.9.391) are made only for recordings that ffmpeg can read and that last between 1 minute and 12 hours; a recording whose pictures fail is tried again after 6 hours. After an ad cut the recording's seek pictures are not shown until they are made again from the cut file (its still stays meanwhile). Catch-up pictures need the channel's timeshift buffer to hold the whole programme, so a programme that started before the buffer did gets none. Below 5 GB free in the data folder no pictures are made.