Multiple TVE Streams

Channels DVR Server
#41

Its showing that the stream is getting corrupted by the time it reaches the DVR. If your disk and ram are fine, then it might be a network issue. I would check the ethernet cables. Was the linux DVR plugged into the same switch?

I'm pretty sure this is not a software issue. If the DVR was broken on Windows 10 we would be hearing a lot more reports. I've only seen this skipped=N issue maybe 3-4 times since we launched TVE, and it has always been due to faulty hardware somewhere in the stack.

#42

These are all stats about the MPEG transport stream:

  • skipped=1904 – Bytes that were skipped by the MPEG-TS parser (malformed or corrupted TS packets)
  • unhandled_packets=0 – Number of packets that could not be recovered when a discontinuity is detected and are passed through un-fixed. If this is above 0, there were issues hat could not seamlessly be recovered from
  • discontinuity_detected=4 – Number of times that MPEG-TS streams were spliced together and Channels was able to properly recover from it and rewrite the stream in a consistent way
  • transport_errors=0 – Errors in the stream itself
  • invalid_pts=0 – Presentation timestamps that don't fit, such as inserted commercials using a different clock base
  • invalid_dts=0 – Decode timestamps that don't fit, just as above; sometimes packets are encoded in a different order than they're meant to display, hence two different types of timestamps
  • saw_pcr=true – Whether the stream had a program clock rate embedded, the basis used for the timestamps (PTS/DTS)
  • saw_pmt=true – Whether the stream had an embedded program map table, indicating a stream's various audio/video tracks
  • highest_pts=3440.926144 – Largest timestamp seen in the recording

Of course, these definitions are all my own inferences from prior experiences and logical conclusions; corrections are welcomed.

Edit: Definitions were updated with corrections from @tmm1 and @eric.

#43

Skipped is the number of bytes that could not be parsed. Mpeg-TS packets are generally 188 bytes and start with the byte 0x47. If the stream is corrupted, the 0x47 gets overwritten with something else and the packets cannot be parsed correctly.

The TVE streams come over the network, are saved directly to the disk, and then parsed to feed into the rest of the DVR recording engine. Somewhere in the pipeline the packets are being corrupted. In the past I've seen this due to bad RAM (i.e. corruption between network and disk), or bad DISK (i.e. corruption between when the data is written and when it is read). I think there was also one isolated case where the network itself was corrupting data before it made it to the DVR machine.

#44

Bytes, or packets?

So skipped refers to corrupted bytes/packets, not dropped. Good to know.

#45

IIRC skipped is reported in bytes. These bytes are skipped by the mpegts parser as it looks for the next 'G' that represents a valid packet.

#46

This is actually just indicating the number of times that MPEG-TS streams were spliced together and Channels was able to properly recover from it and rewrite the stream in a consistent way. Depending on which TVE stream is being used and how it is served, this could happen many times and be perfectly okay.

This is the number of packets that could not be recovered when a discontinuity is detected and are passed through un-fixed. If this is above 0, there were issues we could not seamlessly recover from.

#47

I purchased a new modem and it seems better. I will check again in the morning

#48

Thanks for the corrections. I modified the list, in case others go looking for the information. It's always nice to have things written down somewhere.

#49

The new modem appears to be holding. I will let you know if this changes. Thanks.

#50

What did you get for indications you needed a new modem? Were you getting uncorrectable errors?

#51

I received errors in the modems log about the config file and I was not getting my full speed.

New error What does it mean?

2020/04/22 12:26:11.923397 [HLS] Couldn't generate stream playlist for ch5902-dANY-ip192.168.1.20: Locast: Stream Not Available
2020/04/22 12:26:11.923397 [HLS] Stopping transcoder session ch5902-dANY-ip192.168.1.20

#52

When I try to sign into locast.org in my web browser, it shows "rate limit". What is this and how long does it take to reset.

#53

Can you submit diagnostics? Was it repeatedly hitting locast?

#54

I was pushing the locast for testing purposes. I ended up canceling my subscription and resigned up with a different name.

#55

I just submitted logs, fyi, there is a bug in your help page on the latest beta. It does not pick up on my dns settings or that google is accessible.

1 Like
#56

I just recorded some videos. On the mts line skipped is down to 0 for all new recordings. Thanks.

1 Like
#57

I'm encountering the same issue with Locast -- for some reason even though I have my TVE logins prioritized higher than Locast, my local channel recordings still use a Locast stream instead of TVE. I did not specify TVE channels for Season Passes. I logged out of Locast and now have a "Rate Limit" error. I'm running 2020.07.30.2221.

1 Like
#58

The same occurs when I try to register for locast.org. What am I supposed to do?