[phunkyfish]

I’m not sure. This would mean there is no way to play anything within 5 hours of live, right?

Seeking close to live would not work and the latest PR targeted at terminating streams like xc would need to be rewritten to facilitate this (which IMHO is the wrong thing to do, as it would add a huge amount of complexity).

I would raise the issue with your provider or switch to one with working catchup streams.

Out of curiosity, does the live stream match the live programme from the EPG so it’s only the catchup that’s incorrect?

[Seany70363]

I can watch within 5 hours of live but have to pretend it's 5 hours earlier - for example if it's currently 21:00 and I want to watch a programme that ran from 20:00 to 21:00 then I would have to scroll back to 15:00 to watch it. If I try and play anything after 16:00 it fails - because 16:00 is actually 21:00 (live)

Yes it's only the catchup that is incorrect - live matches EPG.

I actually think I got it working just now but haven't had chance to fully test with other channels yet... I put tvg-shift="5" in the header of my M3U (noticed this on the github page) which shifted my EPG by 5 hours but resulted in the correct programme being played when selected. So then I tried to compensate for this in the IPTV Simple settings by setting "EPG time shift" to -5. Now it would seem that both my EPG and catchup are correct!

[phunkyfish]

Amazing. I had no idea that would work. I think that deserves being called out specifically in the README.

Let me get it straight first.

1. Set tvg-shift in the header line of the M3U. These will shift both the EPG data and the catchup stream position by the value. Live will remain as live.
2. Set EPG timeshift to the negative of that value. This will only correct the EPG data leaving the catchup stream in its correct offset.

Make sense? @Seany70363

[phunkyfish]

What you have actually found is a bug, the epg timeshift value used for catchup only incorporates the value from the M3U and ignores the value in settings.

The EPG itself uses the settings value + the M3U channel shift.

This allows you to offset the stream by way of the difference. Let me see if there is a better way of doing this so the bug is fixed and you have a solution.

[Seany70363]

Amazing. I had no idea that would work. I think that deserves being called out specifically in the README.

Let me get it straight first.

1. Set tvg-shift in the header line of the M3U. These will shift both the EPG data and the catchup stream position by the value. Live will remain as live.
2. Set EPG timeshift to the negative of that value. This will only correct the EPG data leaving the catchup stream in its correct offset.

Make sense? @Seany70363

Correct. Probably not the best solution but it works! No doubt one day I'll switch to another provider and then wonder why my EPG is all off!

Please keep me posted on the progress of this

[phunkyfish]

Correct. Probably not the best solution but it works! No doubt one day I'll switch to another provider and then wonder why my EPG is all off!

Please keep me posted on the progress of this

Next release which will be out today will have a catchup-correction field which will work similar to tvg shift but only apply to the catchup stream. You can either set it for the whole M3U file and/or for each M3U individually.

I think what has happened with your stream is that it has geo locked itself to the wrong time.

[Karim95]

Hi Punky,

Thanks for your amazing work, i’m facing a challenge to get the catchup.
My provider is compatible, I can access to the timeshift using IPTV Smarter for example.
The m3u doesn’t include any catchup tag, I got the structure of the url using MXPlayer stream details.

Exemple of Live stream in the m3u
http://server.com:port/Username/Password/1234X

Catchup details from mxplayer:
http://server.com:port/timeshift/Username/Password/85/2020-05-01:23-10/271.ts

I understood that from the addon settings i’m able to set the syntax with Y-M-D:h-m

How can I specify the /timeshit/ url folder and the /85/ where i didn’t get the logic, it doesn’t match with the channel number and it’s different for each replay even from the same channel.

Please help me.

Thanks

[phunkyfish]

@Karim95

So in your example the 271 is static for the channel and the 85 changes?

We would need a way to find out or generate the number that changes. It could also just be a number that is chosen at random. Have you tried just hardcoding it and seeing if it works?

[Karim95]

@Karim95

So in your example the 271 is static for the channel and the 85 changes?

We would need a way to find out or generate the number that changes. It could also just be a number that is chosen at random. Have you tried just hardcoding it and seeing if it works?

[Karim95]

@Karim95

So in your example the 271 is static for the channel and the 85 changes?

We would need a way to find out or generate the number that changes. It could also just be a number that is chosen at random. Have you tried just hardcoding it and seeing if it works?

Hi Phunkyfush,

Thx for your reply, yes 271 is the static channel number, 85 is coming from nowhere. I saw in your readme that there is a catchup-id selector, could be that.
I’m using the Coreelec Archive addon, some url settings have no effect some start the channel but in live mode without timeshift.

[Karim95]

@Karim95

So in your example the 271 is static for the channel and the 85 changes?

We would need a way to find out or generate the number that changes. It could also just be a number that is chosen at random. Have you tried just hardcoding it and seeing if it works?

Hi Phunkyfush,

Thx for your reply, yes 271 is the static channel number, 85 is coming from nowhere. I saw in your readme that there is a catchup-id selector, could be that.
I’m using the Coreelec Archive addon, some url settings have no effect some start the channel but in live mode without timeshift.

Update:
The random number seems to be the duration

[phunkyfish]

Ok, then this is easy we already support that. So you just need help defining the catchup URL so. Will take a look later today.

EDIT - Try this for the M3U: 

Code:


#EXTINF:0 catchup="default" catchup-source="http://server.com:port/timeshift/Username/Password/{duration}/{Y}-{m}-{d}:{H}-{M}/271.ts" catchup-days="3",Channel Name
http://server.com:port/Username/Password/1234X


So I think the closest you can get is to within one minute of a time that you want. I have made a guess that you have 3 days of catchup available.

[Karim95]

Ok, then this is easy we already support that. So you just need help defining the catchup URL so. Will take a look later today.

EDIT - Try this for the M3U: 

Code:


#EXTINF:0 catchup="default" catchup-source="http://server.com:port/timeshift/Username/Password/{duration}/{Y}-{m}-{d}:{H}-{M}/271.ts" catchup-days="3",Channel Name
http://server.com:port/Username/Password/1234X


So I think the closest you can get is to within one minute of a time that you want. I have made a guess that you have 3 days of catchup available.

[Karim95]

Hi,

Thanks a lot, just a last point, your suggestion is to amend the m3u, the challenges are that it’s a hosted one to get the latest update, the second is even if I need to change that to use a static local file, i will need to amend all channel lines in the m3u (i have few thousands), so any option to keep the file updated without wiping everything each time the file is updated?

Thanks

Regards

[phunkyfish]

Actually your format looks to be the XC format.

Just set the All channels support catchup using mode in the addon settings.