Watch now issue

[bader77uk]

Agreed with mvallevand.

@sub i would suggest to implement a limit numbers of retries with delay in between if receives "403" for not to missed the rest of recording where there is much possibility to catch up again with stream. i am sure it will be useful and effective ( manually tested ).

Edit: @sub if you dont think its important or you disagree, i would donate for a custom version for personal use.

[sub]

Try the next build when it's available, then we'll decide if anything further needs to be done.

[bader77uk]

ok thank you

[sub]

Ok.  There is an issue of the earlier 403 (maybe on the HEAD) being sent to ffmpeg that should be avoided.

Code:

2020-06-25 22:37:43.388 [DEBUG][271] ConnectToURL:
...
2020-06-25 22:37:43.427 [DEBUG][271] WebException: System.Net.WebException: The remote server returned an error: (403) Forbidden.
  at System.Net.HttpWebRequest.GetResponse()
  at NShared.IPTVRecorder.ConnectToURL(String url, Int32 depth)
2020-06-25 22:37:43.427 [DEBUG][271] CheckTSUrl done
...
2020-06-25 22:37:43.427 [DEBUG][271] IPTV StartStream@3.3
2020-06-25 22:37:43.427 [DEBUG][271] IPTV StartStream@3.4
2020-06-25 22:37:43.427 [DEBUG][271] IPTV StartStream@3.5
2020-06-25 22:37:43.427 [DEBUG][271] IPTV StartStream@3.5.1
2020-06-25 22:37:43.427 [DEBUG][271] Executing: ffmpeg -y -user_agent "VLC/2.2.6 LibVLC/2.2.6" -vaapi_device /dev/dri/renderD128 -i http://.... -codec:v:0 h264_vaapi -codec:a:0 aac -strict experimental -ac 2 -ab 128000 -f mpegts  -

I checked this out. This looks fairly normal.

When starting a recording, if for any reason NextPVR can't connect to the stream directly, it'll fall back to letting ffmpeg try. (In this case it was related to a 403, but other times might be something weird with redirects or cookies etc which NextPVR might not understand).

Normally bader77uk's streams are able to be used directly, without requiring ffmpeg. It was only falling back to ffmpeg when the service started rejecting his connections.

[mvallevand]

I understand the logic, it's just that on a 403 it might not safe to assume that ffmpeg will be able to open the stream which could lead to an IP lookout and I was trying to explain "why". Also I guess you could check cached info and on a 403/401 don't got to ffmepg when it is h264/aac

The better solution is a more stable provider so we don't have to go through this.

Martin

[sub]

Also I guess you could check cached info and on a 403/401 don't got to ffmepg

Actually, there has been some rare cases where NextPVR gets a 401 failure, and it falls back to ffmpeg, and it succeeds (due to IPTV provider rejecting NextPVR user-agent string) etc.

[bader77uk]

@sub

There is an error "(503) Service Unavailable." which also keep retires, this need a fix as well

check file "nrecord.log.1" starting @line 54950

[sub]

There is an error "(503) Service Unavailable." which also keep retires, this need a fix as well

There is no clear cut answer to what the best behavior is for some of these. Ultimately, retrying is usually a good thing, and with some services it'll just reconnect and continue on.

I've add a max of 40 retries for the next build, for any type of error. After that it'll give up.

[bader77uk]

There is an error "(503) Service Unavailable." which also keep retires, this need a fix as well

There is no clear cut answer to what the best behavior is for some of these. Ultimately, retrying is usually a good thing, and with some services it'll just reconnect and continue on.

I've add a max of 40 retries for the next build, for any type of error. After that it'll give up.

limit to 40 retries is a way better than the current behaviour. I agreed
when will be the next build available?

[sub]

limit to 40 retries is a way better than the current behaviour. I agreed
when will be the next build available?

I've been pretty with my day job recently. I'll try to get it out around the end of the week though.