Streams stopping intermittently

[mvallevand]

It recorded to the end without an error though so Live TV issues might be related to the rolling file.

2023-12-20 10:02:00.479 [DEBUG][24] Reached end of in-progress recording. Dropping connection.


What I did notice is you had and EPG update during the recording which is is bad practice and might have caused the corruption.

2023-12-20 10:00:59.179 [DEBUG][34] Doing EPG update from broadcast DVB/ATSC EPG

Zip and send the .timing file that was created with recordings.

How often do you do EPG updates I see a few. Can you link the EPG updates to other problems with Live TV?

2023-12-20 07:55:42.063 [DEBUG][9] {"stat": "ok", "status": "EPG Update complete. [2935 inserted, 0 updated, 0 skipped]", "updating": false}
2023-12-20 13:06:46.331 [DEBUG][24] {"stat": "ok", "status": "EPG Update complete. [2923 inserted, 0 updated, 0 skipped]", "updating": false}

[Langelus]

I have a schedule for EPG update at 10 AM but I've just changed it to run at night instead, I'll try it out some and see if that would solve it

[mvallevand]

That file by timestamps seems fine, so the corruption is probably just the number of packets lost that are either source or network related, you would need to investigate that but the percentage is relatively low, but could at times be noticeable.

Sub does need to look at the error on the rolling file though, which appears to be the real cause of Live TV stopping

Martin

[Langelus]

Running the EPG update unfortunately makes no difference, not wanting to come of a pushy but has Sub had time to take a look at the potential issue with the rolling file?

Thanks!

[mvallevand]

Could you send new zipped logs to confirm you are still getting this error. It might be related to a SAT>IP read timeout too that sub has just looked into. Do you have the minisatip logs?

Martin

[Langelus]

Just confirmed here, attaching the logs where you can see the rolling file error at 2024-01-16 08:29:53.919 in the NextPVR logs and the TEARDOWN message at 16/01 08:29:55.646 in the Minisatip log

[mvallevand]

If you attached the minisatip log it would have had to be zipped and under 2MB A TEARDOWN would be normal on exit though and those times seem to match nicely,

2024-01-16 08:29:55.646 [DEBUG][23] Shutting down RTSP input stream
2024-01-16 08:29:55.649 [DEBUG][3] No more streams. Stopping SATIP device

The quality of the feed is definitely suspect, a few dropped packets in 10 seconds would be normal these are not, if in those

Code:

2024-01-16 08:08:28.102 [DEBUG][23]     Have received 819313964 bytes from rtsp source (361 dropped packets)
2024-01-16 08:08:38.121 [DEBUG][23]     Have received 838680220 bytes from rtsp source (1253 dropped packets)

2024-01-16 08:15:08.512 [DEBUG][23]     Have received 1638537876 bytes from rtsp source (1363 dropped packets)
2024-01-16 08:15:18.525 [DEBUG][23]     Have received 1658547280 bytes from rtsp source (1725 dropped packets)

2024-01-16 08:21:48.850 [DEBUG][23]     Have received 2458326728 bytes from rtsp source (1775 dropped packets)
2024-01-16 08:21:58.863 [DEBUG][23]     Have received 2477555368 bytes from rtsp source (2726 dropped packets)

2024-01-16 08:24:59.048 [DEBUG][23]     Have received 2846456676 bytes from rtsp source (3020 dropped packets)
2024-01-16 08:25:09.048 [DEBUG][23]     Have received 2866611216 bytes from rtsp source (3262 dropped packets)

2024-01-16 08:26:39.116 [DEBUG][23]     Have received 3051258988 bytes from rtsp source (3262 dropped packets)
2024-01-16 08:26:49.120 [DEBUG][23]     Have received 3071305428 bytes from rtsp source (3543 dropped packets)

2024-01-16 08:28:29.205 [DEBUG][23]     Have received 3276155868 bytes from rtsp source (3714 dropped packets)
2024-01-16 08:28:39.228 [DEBUG][23]     Have received 3296013556 bytes from rtsp source (4234 dropped packets)

Between these times would be more interesting, if no data was received it could, because of your poor signal, it might be a timeout.

2024-01-16 08:29:49.288 [DEBUG][23] Have received 3439609272 bytes from rtsp source (4283 dropped packets)
2024-01-16 08:29:53.919 [ERROR][3] Unexpected error streaming channel: System.NullReferenceException: Object reference not set to an instance

Martin

[Langelus]

Didn't notice that the minisatip log didn't upload correctly, here it is.

Can't seem to find anything indicative of issues in that log though (?)

[mvallevand]

Not much there and the dropped indicator didn't show anything in this https://pastebin.com/Zuce6wpD paste so perhaps the network is dropping packets. Perhaps in that paste there is a link to when the bandwidth (BW) drops to the missed packets but hard to say

Sub would really need to luck at the rolling file error to see if perhaps it could be a short timeout that he was looking

Martin

[Langelus]

Been playing around with it to try and pinpoint where those networkdrops would come from since it's all local to the same server, I did notice a pattern that there is a slight drop every now and again of a couple of packets and a huge spike of ~500 packets dropped when rolling over to the new file. Since minisatip is running as a Docker while NextPVR is installed directly on the OS I did try to change from host-based networking to an overlay network (bridged) and since that I don't see these big drops and has so far not been able to reproduce the error of the rolling file.

Gonna keep testing a couple of days to see if it happens again otherwise it might just be that the Docker host networktype does something wierd and with a short timeout is enough to cause issues.