EPlusTV

[hdpvr-doug8796]

No you use a UI client and they use a lot of logging, you need to catch it closer.  Keeping clients running all day doesn't help.

Martin

So no idea what happened?

[mvallevand]

Your logging goes back to the 27th what more can I say.

[hdpvr-doug8796]

How can I go back further

[mvallevand]

Since we don't have TARDIS, check your PC daily backup, which you likely don't make or you wouldn't ask. Perhaps start backing up your logs folder more often.

In the end it doesn't seem like an NextPVR specific problem as you note the change made in the last patch worked around a server issue handling fast m38u8 calls. There is nothing left to change.

What could be the problem is that NextPVR natively doesn't support all the features of HTTP Live Streaming https://datatracker.ietf.org/doc/html/rfc8216 and there are no plans to implement them. Enabling verbose logging in NextPVR could show that but wouldn't lead to a solution.

You might find that an extra with ffmpeg or streamlink is more to your liking, but they may not be consistent handling out of spec streams. These services don't want you to record them and change, I see the your EPlusTV just lost Paramount+ so the scrapper needs reworking, and can be foiled with DRM. Some of these streams also generate mpeg-ts files with bad timelines which can be played live and saved but have timelines that make them unwatchabel.

Perhaps read up on ChannelDVR support for PlutoTV handling that one service can be a full time job.

Martin

[hdpvr-doug8796]

What I think may have happened is that some events start later than expected. Is it possible to have nextpvr keep reattempting to record something if it first fails - like event not beginning yet?

Things break periodicially. Paramount broke but has been fixed.

[mvallevand]

That is a reasonable explanation. However, live TV channels are supposed to be "live" and not event driven so in reality polling for an m3u8 that returns 404 not found doesn't make sense. NextPVR will attempt to find the same unique id in the guide data on failure so I guess you could craft an XMLTV file that tries every five minutes.

You can enter negative pre-padding in the guide if expect the start time to be lose.

In theory servers could control this with the 503 and a Retry-After header but it is not something I see being implemented in NextPVR anytime soon, it is pretty hard to test and pretty esoteric

Martin

[hdpvr-doug8796]

That is a reasonable explanation.  However, live TV channels are supposed to be "live" and not event driven so in reality polling for an m3u8 that returns 404 not found doesn't make sense.  NextPVR will attempt to find the same unique id in the guide data on failure so I guess you could craft an XMLTV file that tries every five minutes. 

You can enter negative pre-padding in the guide if expect the start time to be lose.

In theory servers could control this with the 503 and a Retry-After header but it is not something I see being implemented in NextPVR anytime soon, it is pretty hard to test and pretty esoteric

Martin

Any other tips?

[mvallevand]

Negative padding makes the most sense but you can create as many manual recordings as you need otherwise i think I'm done.

Martin