LiveTV Freezes Are Back on Clients

[sub]

(yay internet working again!)

Can you post the server nrecord.log?

[mvallevand]

I started again sorry, I'll catch it the next time. It looked the same to me as the others I posted, streaming stopped, a few minutes of lease renewals with no streaming, then a lease expired, stop and graph stop.

Martin

[mvallevand]

Here is another freeze after a read of 0 bytes

Code:

System.ArgumentOutOfRangeException: Value to add was out of range.
Parameter name: value
   at System.DateTime.Add(Double value, Int32 scale)
   at NextPVR.Players.BasePlayer.UpdateTimeline()
   at NextPVR.Players.BasePlayer.RefeshOSD()
   at NextPVR.Players.LiveTvPlayer.RefeshOSD()
   at NextPVR.ControllerForm.timer1_Tick(Object sender, EventArgs e)
   at System.Windows.Forms.Timer.OnTick(EventArgs e)
   at System.Windows.Forms.Timer.TimerNativeWindow.WndProc(Message& m)
   at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

Martin

[rbmcgee]

Hi,

I'm following this issue and therefore this thread and could I just ask a couple questions for clarification.

Martin, I assume you are using 2.5.9 (with all patches) for the server. Are you using 2.5.9 for the client as well? Also, is the client on the lan (I assume) or across the internet?

sub, if this issue occurs across the lan, I also assume it would occur across the internet?

[mvallevand]

I am using 2.5.9 patched clients and servers and I would never use NextPVR's proprietary client protocol over over the internet,

Martin

[sub]

sub, if this issue occurs across the lan, I also assume it would occur across the internet?

This is full bitrate transport stream, only intended for use on a LAN, a typical internet connection would never keep up. If you were wanting to use it over the internet, you'd need on the fly transcoding etc, which isn't there.

[sub]

Here is another freeze after a read of 0 bytes

You could see if this helps. It increases the size of the socket send buffer. The problem in your logs looks like it occurs when a send() from the server gets blocked.

[mvallevand]

That's why I have been asking if you are handling the read = 0 correctly as a non-error, with the small wait retry. I never see a reread in reader.log on 0.

Martin

[sub]

The way the protocol works it shouldn't require a retry - that should happen on the server, but given the attached adds a client side retry.

[mvallevand]

The way the protocol works it shouldn't require a retry - that should happen on the server, but given the attached adds a client side retry.

Here is a log hang using the newer nshared but not the reader. The 0 read is not from the protocol, winsock returns it unless you are using blocking reads when the network is momentarily busy.

Martin