timeradd questions

[DetlefM]

Hi,

# EPG Entry for test timeradd
<Timer Type="1" ID="{DA25C491-02D1-4FF3-BEF3-B382BBEA5DA1}" Enabled="-1" Charset="255" Date="23.07.2025" Start="20:15:00" Dur="100" End="21:55:00" IntID="9515" Priority="50" Action="0" Timeshift="0" EPGEventID="48124" PDC="769295"> 
<Descr>Mytitle</Descr> 
<Options AdjustPAT="-1" MonitorPDC="1"/> 
<Format>2</Format> 
<Folder>Auto</Folder> 
<NameScheme>%name_%event_%station__%year-%date_%time_W2</NameScheme> 
<Title>Agatha Christie's Poirot</Title> 
<Subheading>Alibi</Subheading> 
<Source>API</Source> 
<Channel ID="2359890668641593480|ONE HD" EPGID="577023706619914376"/> 
<Executeable>-1</Executeable> 
<Recording>0</Recording> 
<ID>9515</ID> 
<GUID>{DA25C491-02D1-4FF3-BEF3-B382BBEA5DA1}</GUID> 
</Timer>

 

1. ID and GUID are identical.
Do I need them for something like deleting, editing, or are they only for internal use? Or in other words, is the UID unique even across server starts? The <ID> isn't when I am right.
2. Title:
The string passed in the 'title' parameter seems to be stored under the tag <Descr>Mytitle</Descr>. However, the original title is displayed in the web interface - at least if the time matches an EPG entry. Do I have to pay attention to anything when using this parameter as a custom ID?
3. From the Recording Service documentation
"epgevent= Set a valid EPG Event ID, to connect the Timer to an EPG entry (only used if the Twaak is set)." What is Twaak?
4. Daylight saving time
How does it behave during daylight saving time changes?  Can I assume that a movie/series that starts before the change has the correct end time in the EPG? (i.e., one hour more or one hour less). Or should I always use the duration instead of the end time?

Request/suggestion:
For timeradd and timeredit (not tested there): The newly created or modified timer would make sense as the response.text – or at least the timerID.
Currently, I have to retrieve all timers again to check and then make a manual selection.

Thanks in advance

[Griga]

vor 15 Stunden schrieb DetlefM:

1. ID and GUID are identical: Do I need them for something like deleting, editing, or are they only for internal use?

 

I don't know why the GUID has been introduced (happened before I took over). It is created when a new timer object gets created and stays the same, also across server starts, provided the timer is not recreated. Maybe it is used in some add-on, so I kept it for compatibility reasons. In DMS/DVBViewer it is used nowhere for identifying or retrieving a certain timer. However, it is written to the EPG Info file of recordings, thus linking recordings to timers, which doesn't make sense, because mostly timers are deleted after the recording is done.

 

Another thing is the Integer ID. It is uniquely created as soon as a timer is added to the internal list of timers and heavily used in the API and in the web interfaces for efficiently referring to / identifying certain timers. It is mandatory for editing timers. It is recommended for deleting timers. Only specify the timer by channel ID, date, start and stop time if the ID is unknown.

 

Unfortunately an awkward thing in the api/timerlist.html output is the GUID ID appearing as ID attribute of the Timer element, but also as GUID sub-element, and the Integer ID as IntID attribute of the Timer element, but also as ID sub-element. This is an unnecessary and confusing redundancy. I just noticed it and can't remember how and when and why this came in.

 

vor 15 Stunden schrieb DetlefM:

2. Title: The string passed in the 'title' parameter seems to be stored under the tag <Descr>Mytitle</Descr>.

 

The identifier Descr is one of inconsistencies originating from a chaotic past with a lot of rapid prototyping. I had to keep Descr as identifier for compatibility reasons, but actually it refers to the user-editable timer name. Title and Subheading have been added later for facilitating auto-timer handling. Please read more about it here (German). 

 

vor 15 Stunden schrieb DetlefM:

3. From the Recording Service documentation: "epgevent= Set a valid EPG Event ID, to connect the Timer to an EPG entry (only used if the Twaak is set)." What is Twaak?

 

EPGEventID is the EventID originating from the broadcasted EPG. It is supposed to identify an event uniquely and could be used to recognize an event (programme) in the EPG, even if (after an EPG update) other properties like title, subheading, start time etc. have changed, if the broadcasters would use it correctly. Unfortunately a lot of them don't, which means, they re-assign EventIDs on EPG updates.

 

Recognizing events (programmes) is important for updating timers automatically, e.g. to changed start times. Unfortunately the only data that has proved to be passably reliable for event identification is the PDC, or, if not available, the time interval covered by the timer and the event. So by default the Media Server only uses the EventID in certain cases for reassuring that an event matches a a timer, not for identifying it. However, this can be changed by the tweak "EPG Event ID usage on timer handling" (-> launch DMSTweaker,bat). It lets the DMS use the EventID in the same way as the PDC, if not present in the EPG, and may be worth a try if a DVB network provides stable EventIDs, like the British Freesat.

 

vor 15 Stunden schrieb DetlefM:

4. Daylight saving time: How does it behave during daylight saving time changes? 

 

Who knows? The basic problem in DVBViewer / DMS is that it converts EPG start times, which are broadcasted as UTC, to local times on arrival and stores them in this way. Timer start times are also processed and stored as local times. So there are quite some opportunities to do the wrong thing after a DST change. AFAIK there have been some adjustments in the past to mitigate the worst impact, particularly concerning the EPG. However, a fail-proof handling would require to internally use UTC times throughout and only convert them to local times in the UI. I once changed it in DVBViewer GE accordingly (and successfully), but it was a great deal of work, and in DVBViewer Pro / DMS it would be a Herculean task, probably causing many incompatibilities. So we have to live with imperfection in this respect

 

vor 15 Stunden schrieb DetlefM:

Request/suggestion: For timeradd and timeredit (not tested there): The newly created or modified timer would make sense as the response.text

 

I'll think about it...

 

[DetlefM]

Thanks for the quick, detailed reply. Is there already a request for a "json" flag so that the response is in json instead of xml? Of course, I can convert it, but json is much more widely supported in current languages than xml, especially for web applications. (And makes it easier for humans and AIs to understand.) But I also understand "never change a running system."

[Griga]

vor 1 Minute schrieb DetlefM:

Is there already a request for a "json" flag so that the response is in json instead of xml?

 

No request up to now.

 

[Griga]

Am 22.7.2025 um 20:12 schrieb DetlefM:

Request/suggestion:
For timeradd and timeredit (not tested there): The newly created or modified timer would make sense as the response.text

 

That's easy. However, it requires another parameter response=[whatever] for compatibility reasons. The response is the complete added / edited timer as xml in the api/timerlist.html format. The output is empty if a timer isn't added because

• the channel cannot be received with the available hardware (406 not acceptable response)
• the programme is already covered by a timer and allowdup=1 is not included in the query part. (see below)

Will be available in the next release. I could provide a test version in case of urgent need.

 

Edited July 24 by Griga
Correction

[DetlefM]

Quote

The output is empty if a timer isn't added because

• the channel cannot be received with the available hardware (406 not acceptable response)
• the programme is already covered by a timer and allowdup=1 is not included in the query part.

I'm advocating for a "fullresponse" parameter of 0 or 1 - defaults to 0 (False). Yes - if status != 200 there is no need for additonal content. The status is the content.
I don't need it right away, but of course I'm happy to test it if it helps.

And regarding "json": If it were possible with reasonable effort, I'd like to see it on the "nice to have" list. Especially with modern React and other frameworks, json is integrated directly into JavaScript as part of the language. Of course, you can use a third-party library, but that bloats the code. Also, not every XML parser produces identical json strings, which is also bad for the API documentation.
I'm sure that every new app using the MediaServer API would immediately use json (regardless of the language).
Here's a quick question to Copilot about which format AIs prefer (in German - sorry)
https://copilot.microsoft.com/shares/ZJND97veb5S3g2o2e2azG

[Griga]

vor 6 Stunden schrieb Griga:

The output is empty if a timer isn't added because

• the channel cannot be received with the available hardware (406 not acceptable response)
• the programme is already covered by a timer and allowdup=1 is not included in the query part.

 

I think it's better to return the duplicate timer, so it can be inspected.

 

vor 1 Stunde schrieb DetlefM:

I'm advocating for a "fullresponse" parameter of 0 or 1 - defaults to 0 (False).

 

Ok. Now a numerical value <> 0 of the response parameter means true, all other values false.

 

In the meantime I've added the same possibility for api/searchadd, api/searchedit and api/recedit.

 

vor 1 Stunde schrieb DetlefM:

And regarding "json": If it were possible with reasonable effort, I'd like to see it on the "nice to have" list.

 

Since there seems  to be no easy way to convert XML to JSON (see here), and I couldn't find a XML to JSON conversion library suitable for Delphi  7, each and every API XML output would have to be re-coded for JSON output. The effort would only be reasonable if there would be really demand for it, either by many add-ons or by a very important add-on. And even if this would be the case, my resources would probably be too limited for doing something like that.

 

[DetlefM]

Quote

In the meantime I've added the same possibility for api/searchadd, api/searchedit and api/recedit.

Good idea.

 

Quote

Since there seems  to be no easy way to convert XML to JSON (see here), and I couldn't find a XML to JSON conversion library suitable for Delphi  7,

I only worked with Delphi briefly decades ago, so I have no idea how much effort it takes. Python seems pretty manageable (see attachment). My brief search didn't yield a library either. It's better to let the topic rest. When I have time, I'll see if there's a free version of Delphi 7 that I can play with to get a feel for it.

xmltodict.py.txt

[DetlefM]

json
I've now written a small Python proxy server that adds json functionality to the MediaServer.
I think you should install it on the same computer as the MediaServer (but it also works on a Raspberry Pi in the corner).
Use after installation: Instead of <mediaserver:8089>/api/<apicall>?parameter, call <proxyhost:PORT>/api/<apicall>?json=1,parameter.
If an XML response is recognized, you get it as a json string. Otherwise, you get the normal response from the MediaServer (even if you omit json).
Description and download at https://github.com/detlefm/MediaServerAPI

Feedback welcome.

Edited July 24 by DetlefM

[Griga]

vor 14 Stunden schrieb DetlefM:

I've now written a small Python proxy server that adds json functionality to the MediaServer.

 

A clever idea. However, I will not deal with it. I've never done something with Python or JSON, and there are several other things waiting to be done, so I'll rather give them priority.

 

Anyway, thanks for your contribution. Feel free to publish it in a separate topic, so it can be pinned and stays at the top of the API forum.

 

Am 23.7.2025 um 18:08 schrieb DetlefM:

I don't need it right away, but of course I'm happy to test it if it helps.

 

I'll notify you via PM if a beta test version is available. Currently it is in an intermediate state that I want to complete first. Many files changed since 3.3.1.0, particularly in the web interface, so I have to provide the complete setup.

 

[Griga]

Check your PMs.