I performed a test and created a DVR entry without a stop date/time. The entry creation command looked like this:
'{"disp_title":"a","disp_extratext":"b","channel":"ef85dcbdbd53ecc9f8628aeb5c549d6d","start":1715869800,"stop":"","comment":"c","start_extra":0,"stop_extra":0,"pri":6,"config_name":""}'
The ‘stop’ is empty as expected.
When I then extract the complete details for that newly created entry, the start/stop-related properties look like this (I added the date text for clarity):
"start_extra": 0,
"start_real": 1715869770, (Thursday, 16 May 2024 2:29:30 PM)
"stop": 1715869800, (Thursday, 16 May 2024 2:30:00 PM)
"stop_extra": 0,
"stop_real": 1715869800, (Thursday, 16 May 2024 2:30:00 PM)
"duration": 0,
The ‘start’, ‘stop’ and ‘stop_real’ are all identical. The ‘start_real’ is 30 seconds prior to the ‘start’. I have no pre/post-padding in my DVR profile, so the extra 30 seconds seems to have come from my ‘Extra warming up time’ DVR profile setting.
From previous work I have done looking into the WebUI, I think that the reason that an error was not displayed due to the empty ‘stop’ property was that the DVR entry was created using a generic dialogue box within the WebUI.
Each TVH object type has its own set of properties and these are provided to the WebUI when it loads. The WebUI then builds a dialogue box based on the properties of the object in question. When saved, the WebUI simply returns the property names and their values based on what the used has input without validation.
In order to warn about the missing stop date/time before the DVR entry is submitted to TVH, I think that a customised dialogue box may be required. This is because the generic dialogue box does not know how to test the validity of fields.
It may be possible to intercept the ‘Create’ button on the generic dialogue box and perform some validation from within the WebUI before sending the data to TVH. More research would be required to see if that is possible.
On the TVH side, I can see that if the ‘stop’ property is not present, the DVR event is rejected. As the ‘stop’ property is actually present, but empty, TVH does not reject this entry.
One possible solution would be to add a test and reject the DVR entry at this point if ‘stop’ is present but empty.
As a side experiment, I tried to create a PVR entry with no ‘start’ or ‘stop’. The WebUI sent the PVR entry to TVH and TVH created an object. However, the newly created PVR entry was not returned in the upcoming listing. It is present in the ‘Failed Recordings’ as ‘Time missed’.
From what I have found, it appears that both the WebUI and TVH expect sane data to be provided. Apart from the presence of a data property, there is no test that the data contained is actually well formed.
I’m not inclined to take this any further. TVH is expecting users to provide correct data and does not appear to try to protect them from themselves.
If a user wants to make a manual recording that can also be stop manually, perhaps they can make it 24 hours (or whatever) and stop it when they are ready.
