@
phunkyfish Thank you for your fast response.
1. I have an idea about this. I saw that EPG time format in my epg.xml is the same as the one in the URLs I use -
"<programme start="20201207132000 +0200" stop="20201207134500 +0200" channel="X">"
even the DST info is there, so the plugin reads that info anyway, maybe you can add Catchup format specifiers like {epg} {epgend} that use start and end directly from epg. Maybe that way the DTS problem can be solved also - just calculated on the fly, or grabbed if there's any from the program info, but that's not a big deal its just one time in the year - find and replace with text editor , and maybe even soon no more if they cancel it.
other idea is maybe Ye,me,De,He,Me,Se - with "e" for an end, but I don't know if the calculations are going to be easy doable that way.
2. About the format specifiers in the realtime URL, in all the investigation I made I didn't find a realtime TV URL with both start and end time, but only start with "-" at the end, which is more like a 'request date stamp' than 'video start pointer', because even with time months behind it plays realtime stream. What worries me is that it must be there for a reason.
Why do you think its going to be a problem if URL doesn't support end time. Is it tied to your code someway, because I saw in the examples catchup-source without end time, for example:
"#EXTINF:0 catchup="default" catchup-source="http://path-to-stream/live/catchup-b.ts&cutv={Y}-{m}-{d}T{H}:{M}:{S}" catchup-days="3",Channel B
http://path-to-stream/live/channel-b.ts"
Its a user(provider) decision if there is going to be start only or start + end info in the URL, its just needed the plugin to make the conversion from format specifiers to real numbers, am I right ?
And last about the manually constructed URLs question, yes I've tested TV archive with manually edited start & end time in the right format and it works like a charm
