Bug #6107
openRecording two subsequent shows using REST API is failing
0%
Description
TL;DR
Recording using webif works correctly
Recording using REST API does not work correctly in all situations
Hello devteam,
I want to report a bug when using the recorder, it's a little bit difficult to explain, I also made some tests with the API myself and got around it but do not know how to fix it in code.
I am using a TVH client software on my Amazon TV-Stick where I sometimes want to record two different episodes of a show which are broadcasted in direct sequence which is failing.
As said it's a little bit difficult to explain, therefore I will make an example: Lets assume I want to record two episodes of "Super-Cool-Show" which are broadcasted by e.g. "RTL Televsision" the same day in sequence. Please note that the description of the shows are the same but the episodes are really different:
RTL Television, Super-Cool-Show, 01.06.2021 15:30 - 16:30
RTL Television, Super-Cool-Show, 01.06.2021 16:30 - 17:30
Now, I am marking both episodes with my TVH client software in Amazon Fire TV, which will then, if I open up the TVH webif, show nicely under "planned recordings", like this:
Planned >> RTL Television, Super-Cool-Show, 01.06.2021 15:30 - 16:30
Planned >> RTL Television, Super-Cool-Show, 01.06.2021 16:30 - 17:30
So everything is cool right now, but if the time has come to start recording of the first episode of the show the following happens: The second entry which should be recorded an hour later will be recorded, too and if I now take a look into the TVH webif now I see the following entries in the "recording" section:
RECORDING >> RTL Television, Super-Cool-Show, 01.06.2021 15:30 - 16:30
RECORDING >> RTL Television, Super-Cool-Show, 01.06.2021 15:30 - 16:30 !!!!
The second entry which is now also recorded, "morphed" its time from "01.06.2021 16:30 - 17:30" to the first one and also started recording.
If you have no unique recording-filenames, TVHeadend will crash now. Even if you restart the service, since it always want to recreate the same files. You will then have to wait until both shows are over. I managed to make the filenames unique then it is working and you will end up in having recorded the same show (the first one) twice. By the way, if you are recording more subsequent shows you will end up in having the first show recorded multiple times.
If I do the same on the TVH webif (not using the TVH client software) it records fine both shows. Therefore, with this information I first asked the developer of the TV client software because it looked like something is wrong on "his" side).
He told me that he is just using the REST API to create the entries and he never experienced stuff like I reported. So I made some more tests on my side:
If I am using e.g. POSTMAN and the REST-API to create the same entries above using endpoint POST dvr/entry/create with e.g.:
{"start": 1623358800, "stop": 1623360600, "channelname": "Pearl.tv HD Shop", "title": { "ger": "Das Beste aus dem Katalog" }}
(and also the second call with different times, don't have the json anymore, it is basically the same with different start/stop)
It results in the failed behaviour. So this is failing.
If I use the endpoint dvr/entry/create_by_event which is using UUIDs to record the shows. It is working fine.
Also interresting, if I create the two "failing" record-entries, either with the TVH client software or the TVH REST API (well basically it is the same), and afterwards editing the entries with the TVH webif (changing something irrelevant) the entries are somehow corrected then. Then the shows are recorded fine. It looks like the webif correctes something while saving the entries.
The change of the other, subsequent entries, will be changed let's say 5 seconds after the first, regular show and entry, starts.
I am running debian 10 and using tvh docker-images made by the linuxserver.io guys. Therefore I am always relatively up-to-date. I am observing this behaviour since about one year, I am not sure how long this behaviour exists. Some years ago I used KODI and also TVH on a debian backend, here I am very sure, it worked fine. But maybe the guys at KODI are not using the REST API but the "tvhclient binary hstp" protocol? Not sure here though, but this was TVH 4.0 afair.
Files