Open hagaygo opened 1 year ago
Can you give a real example of the URL and the date/time that it represents?
I cant supply a working url, it requires a login session in order to work.
If {utc} value for now is about 1686110830, the url needs the value of (1686110830 - 1577836800 = 108274030) to be passed.
What is the significance of 1577836800
?
As i mentioned, it is 1st of January 2020, this is how the iptv provider time stamp works.
I hope for an option that we can write our own numbers in the m3u , not to hard this value of course.
I would need to look into this to see what is possible. The hard part of this sharing the functionality between iptvsimple and ffmpegdirect. They share the same logic for calculating time stamps.
I believe you misunderstood me.
Lets take an example from this addon readme
#EXTINF:0 tvg-id="channel-f" tvg-name="Channel-F" catchup="default" catchup-days="1" catchup-source="http://yoururl/channeld/video-{utc}-{duration}.m3u8",Channel F
http://yoururl/channeld/video.m3u8
The catchup-source url is
http://yoururl/channeld/video-{utc}-{duration}.m3u8
which using my previous example (lets say duration is 1200) is gonna get translated to
http://yoururl/channeld/video-1686110830 -1200.m3u8
Which wont work for my iptv provider (or any other iptv provider which use non standard timestamps)
The url needs to be in my iptv case like this
http://yoururl/channeld/video-108274030-1200.m3u8
So the addon needs to allow some kind of arithmetic on the parameter values so instead of {utc} we could write something like {utc - 1577836800 } or ({utc} - 1577836800)
I hope this clears up this subject.
Thanks in advance.
I didn’t misunderstand at all. The catchup protocol (so to speak) is still shared across two addons. So both need to be modified to fully support the logic
O.K , I was under the impression that the catchup-source url evaluation is done on the fly by the iptv pvr addon, my mistake i guess.
Thanks for your answers so far , let me know if i can help in any way.
The long answer is that it depends. If all you provider does is give you video file for the program that plays like any other VOD then just iptvsimple would work.
But if skipping, fast forward, rewind etc are all realised through the URL then we need both as iptvsimple only hands off to the inputstream (ffmpegdirect), and the inputstream handles everything from there.
So we always keep those mechanisms in sync as we never know what the users providers capabilities are.
The long answer is that it depends. If all you provider does is give you video file for the program that plays like any other VOD then just iptvsimple would work.
I am quite sure this is my case.
If you will write a video addon for this provider do I need to spend the time implementing this feature? As you can now generate whatever URL you like based on the URL plug-in arguments.
Hi
I think this feature is going to be more and more required in time since IPTV providers are becoming more common and strange/non standard timestamp implementations on their side is also going to be more common.
While i can workaround my use case with a custom software , not every user has that option.
Its your time, in my opinion it would be beneficial to the community.
Thanks again for your time and keep up the good work.
How about I leave this issue open and if some other users make the same request I’ll consider implementing it then.
Hi , Trying to use the addon on an IPTV provider which supports catchup with non standard time stamps.
Their time stamp is based on start of year 2020 , so {utc} parameter is too "big", it needs to be something like {utc}-1577836800 in order for catchup to work correctly.
As far i can see the addon currently does not support this case , if there is a way to make it work , any pointers would be appreciated.