Experimental TsReader development (2 Viewers)

[HomeY]

Tony, LiveTV has been bugging me for a while now, so i thought i would report in here, since it might be related to TsReader. I've got a dedicated TV Server and stream (gbit network, fixed IP adresses) LiveTV using RTSP (used UNC for a long time because of the thumbnailing issue, and i must say i've got a feeling that UNC is more stable for me, but can't say that for sure yet).

This morning i got desync in LiveTV again so i started to investigate it a bit more. I've tested with 2 different codecs for LiveTV (LAV & PDVD12) and tested this with both MPAR & DirectSound device. For some strange reason i'm getting a bunch of -A/V buffers in my TsReader log (@ 10:46, 10:50, 10:53, 10:56 for example) where my TsWriter log is clean in this time frame. I also notice that the number of compensated buffers is always (or very close to) 12?

With UNC i think i had less desync issues, but the FileReader::Read() no open file issue occurred occasionally (which freezes MP for at least a minute).

Any thoughts??

 

[Owlsroost]

The 'Continuity error...' are almost certainly due to packet loss in the network (somewhere).

The '-x.xxx A/V buffers' messages are probably because other packets are being delayed, so the data is too old to use (when it arrives).

Not sure I can help much more - I'm not really a network expert (I run single-seat myself). Have you tried a different NIC in the server/client, or a different switch/router ?

Tony

 

[HomeY]

Not sure I can help much more - I'm not really a network expert (I run single-seat myself). Have you tried a different NIC in the server/client, or a different switch/router ?

Tony

I've tested latency, which resulted without issues. I've been running this network since a long time, and never had this many issues as i have now. Off course this could be related to me switching from UNC to RTSP paths, but i understood that RTSP should be a more stable solution than UNC. i've tried putting a separate gbit card in my HTPC, but that didn't improve things. Even upgraded my servers hardware recently so that can't be the problem. Mayb i'll have to test with UNC some more and compare + retry older TsReader. It's just a nasty issue to track with so many variables in the chain And sometimes the problem seems bigger than other times.

The thing is, i only have issues with LiveTV. Series & movies (Blu-ray) all stream perfectly fine (also the 1080i BDs). Time to spend some more time on this! TNX for the feedback

 

[mhoogenbosch]

Not sure I can help much more - I'm not really a network expert (I run single-seat myself). Have you tried a different NIC in the server/client, or a different switch/router ?

Tony

I've tested latency, which resulted without issues. I've been running this network since a long time, and never had this many issues as i have now. Off course this could be related to me switching from UNC to RTSP paths, but i understood that RTSP should be a more stable solution than UNC. i've tried putting a separate gbit card in my HTPC, but that didn't improve things. Even upgraded my servers hardware recently so that can't be the problem. Mayb i'll have to test with UNC some more and compare + retry older TsReader. It's just a nasty issue to track with so many variables in the chain And sometimes the problem seems bigger than other times.

The thing is, i only have issues with LiveTV. Series & movies (Blu-ray) all stream perfectly fine (also the 1080i BDs). Time to spend some more time on this! TNX for the feedback

Sounds familiar, had a bunch of issues (although i'm running singleseat), discontinuious messages were because my GPU was getting intensly hot and therefor downclockt it to a speed wich couldn't handle LiveTV (which is appereanltly much harder than 1080p or regular 1080i). Worth a try i think, GPU-Z gives you the information you need.

 

[HomeY]

I'm almost certain that isn't my issue, but checked anyways. Running LiveTV while GPU_Z runs in background show GPULoad of 0% with very rare 'spikes' to max 27% load. It returns to 0% load within a second. As soon as i stop LiveTV you can see the GPU Core & Memory Clock drop down. Temps look OK:


Just downloaded TCPView and noticed a weird thing. When i run this on my server and tune into a channel on the HTPC, TCPView shows a TvService connection ESTABLISHED on port 49567 (and it changes this port everytime i retune a channel). But RTSP port on Server is set to 554. Or am i misunderstanding something here??

 

[Owlsroost]

Not sure I can help much more - I'm not really a network expert (I run single-seat myself). Have you tried a different NIC in the server/client, or a different switch/router ?

Tony

I've tested latency, which resulted without issues. I've been running this network since a long time, and never had this many issues as i have now. Off course this could be related to me switching from UNC to RTSP paths, but i understood that RTSP should be a more stable solution than UNC. i've tried putting a separate gbit card in my HTPC, but that didn't improve things. Even upgraded my servers hardware recently so that can't be the problem. Mayb i'll have to test with UNC some more and compare + retry older TsReader. It's just a nasty issue to track with so many variables in the chain And sometimes the problem seems bigger than other times.

The thing is, i only have issues with LiveTV. Series & movies (Blu-ray) all stream perfectly fine (also the 1080i BDs). Time to spend some more time on this! TNX for the feedback

Everything *except* live & recorded TV (using the MP TV plugin in RTSP mode) will use the equivalent of the 'UNC paths' method i.e. Windows SMBx protocol to read remote files. SMB is a 'reliable' protocol with handshaking and re-transmission etc., but RTSP isn't - the data is just pushed out by the server, if the packets get lost in the network they are gone forever - there is no re-transmission.

If these network problems have got worse recently, have you checked/swapped the cables etc. ? The problem with networking is that because the common protocols (HTTP, FTP, SMB etc) are designed to handle packet loss/corruption, the network performance can degrade without it affecting most traffic - except for things like RTSP which are sensitive to it.

Tony[DOUBLEPOST=1355062840][/DOUBLEPOST]

I'm almost certain that isn't my issue, but checked anyways. Running LiveTV while GPU_Z runs in background show GPULoad of 0% with very rare 'spikes' to max 27% load. It returns to 0% load within a second. As soon as i stop LiveTV you can see the GPU Core & Memory Clock drop down. Temps look OK:
View attachment 116334

Just downloaded TCPView and noticed a weird thing. When i run this on my server and tune into a channel on the HTPC, TCPView shows a TvService connection ESTABLISHED on port 49567 (and it changes this port everytime i retune a channel). But RTSP port on Server is set to 554. Or am i misunderstanding something here??

The actual data stream port number is allocated dynamically, so it will change for each new stream. Port 554 is (I think) the port used for stream setup and control.

Tony

 

[Paranoid Delusion]

Hi HomeY

Do recordings suffer the same problem, or are they fine.

 

[HomeY]

If these network problems have got worse recently, have you checked/swapped the cables etc. ? The problem with networking is that because the common protocols (HTTP, FTP, SMB etc) are designed to handle packet loss/corruption, the network performance can degrade without it affecting most traffic - except for things like RTSP which are sensitive to it.

Nope, haven't swapped the cables. Did continuous checking or latency and that seems completely fine. Biggest change (and according to your text about this, this could be the cause) would be the switch from UNC to RTSP for LiveTV.

Hi HomeY


Do recordings suffer the same problem, or are they fine.

I think i've seen hickups and desync on recordings playback also. a skip step seems to fix this, so that would mean it's a network issue.

 

[Paranoid Delusion]

Only a thought, are there any energy settings inside your router or network cards that could cause some periodic reset.

 

[HomeY]

Only a thought, are there any energy settings inside your router or network cards that could cause some periodic reset.

Not that i know of. All powersettings are set to High performance, TV Service is running 'above normal', all PC's have fixed IPs and fixed gbit full duplex settings on the adapters, and i just changed TV Server config for RTSP IP from 'auto' to 'IP' also (i thought i did that already....). AV is excluded from the Timeshift, Recording & MP folders.

I also noticed that i have a bunch of PES errors in my TsReader log. I surely hope it's not a hardware (CAM) issue. But based on the 'randomness' of this issue, i hope i can assume it's not.

Think i'll have to do some more comparising between RTSP & UNC first, but pretty hard to tackle this.