A passed OpenATV timer conflict check confirms the planned schedule passed that check. When an enabled recording timer produces no usable file, read the actual timer status and inspect the receiver’s runtime state, the destination and the permitted source at the scheduled time.
Start with the saved entry and the reported outcome
Suppose a viewer scheduled a permitted evening programme from 21:00 to 21:30. OpenATV accepted the timer and the receiver was left in its usual overnight state. In the morning the recording is absent from the familiar movie list. Record the timer’s actual service, date, enabled state and type. Write down the destination shown on that specific timer, even if a different folder is now the default.
Open the affected timer’s available log or status display and note its exact state and message. A Zap entry can explain an expected channel switch without a saved file. A changed date or disabled entry calls for a scheduling correction. An enabled Record timer with the expected time leads to the runtime checks below.
Work from evidence near the scheduled time
| What you can establish | Next check |
|---|---|
| The receiver never reached its expected running state | Check its actual clock, power and standby state. Ordinary standby can record. Deep-standby wakeup depends on the receiver and its powered, supported setup. |
| The timer started but its destination was unavailable | Check whether that exact drive or NAS was mounted and writable then, and whether it had enough free space. A visible directory alone is insufficient. |
| A file exists but its size or duration is unexpectedly small | Preserve the file and check the reported failure time, destination availability and source behaviour over the same interval. |
| The movie list is empty but the exact timer folder contains a playable file | Check the library’s starting folder or filters. Keep the actual timer destination as evidence that a recording exists. |
| Storage was usable but the service could not open at runtime | Check the authorised source, relevant receiver resources and any provider connection limit for that time. |
Change one variable for a short permitted comparison
If the NAS is reachable now, that is a new observation. Check for a status or mount event from around 21:00 before describing it as available then. If there is insufficient runtime evidence and the owner wants to compare, choose a short permitted recording when the receiver is already running. Keep the same service and use a known writable local destination if storage is the suspected layer. Check the resulting file, duration and playback.
A successful short local recording narrows the next question to what changed, such as destination or overnight state. It cannot establish that every later NAS recording will work. If needed, compare the same short task with the intended mounted destination while the receiver stays running. Check wakeup separately only if the actual receiver and owner’s setup support that comparison.
Give support the runtime evidence
Keep the original timer details, the observed state or exact log message, the selected destination and what you found in that folder. Include whether the receiver was running, in ordinary standby, shut down normally or disconnected when that state is known. Redact credentials and private network paths. A record such as “enabled 21:00 recording, timer log reports destination unavailable, no file at the selected folder” gives a clearer next step than the earlier conflict-check result alone.
Sources and review
- Recording and zap timers — OpenATV