Freezing viewing recorded or Live tv on Clients (1 Viewer)

[mguebert]

@mm1352000

I made the changes to the file you suggested and disabled the windows firewall. I have not watched the file yet, but here is the logs. I also pulled a splitter out of the chain and the signal at the same channel went from -4.5 db to +1.5db

 

[mguebert]

Next I tried going to a single ethernet link and disabling jumbo frames.

 

[Owlsroost]

I am experiencing periodic freezing, sometimes as long as a minute or so. Most of the time it will start playing again on it's own, missing the chunk of time it was frozen.

It's those long freezes I was concerned about - one of them in the TsReader log is more than 30s long. Normally this means no data is available to play (or the client is effectively frozen i.e. the playback filter graph isn't getting the CPU time it needs).

I notice you are using 'UNC paths' for TV - does it behave differently if you use RTSP to connect to the clients ?

 

[mguebert]

I am using UNC paths on the server side because Argus requires it. However I initiated recording / timeshifting from the tvservice app directly and I still see the continuity errors. I then tried changing the recording paths to direct drive letter and initiated a timeshift. I am still seeing discontinuity, is this somewhat normal?

The only thing I can think of to try is to assign a fixed IP to the ceton and connect it directly to the pc with a crossover cable???????[DOUBLEPOST=1389035764][/DOUBLEPOST]I am desperate, WAF is going down the tubes FAST!!!!

 

[mguebert]

Update,

I tried to enable rtsp and playback a file that caused freezing, instead of freezing the recording would stop playing an return to the recording screen. I went in and disabled QOS scheduling and enabled file and print sharing. Still it would kick the recording playback back to the recording screen. Then I tried the replacement tsreader.ax you supplied and the file played back normally.

The problem I have with rtsp is that when watching live tv from the hdpvr all I get is a black screen unless I stop the live tv playback and restart it. It has to do with channel changes and the stream from the hdpvr. Is there a way to delay the start of the stream until the channel change has completed????

The TSreader file has seemed to help one of the clients anyway. I will try this file on the other clients.[DOUBLEPOST=1389042789][/DOUBLEPOST]Still seeing the continuity errors in the tswriter log even with a static ip assigned to the tuner and being connected directly to the pc on it's own Intel gb nic.

 

[mguebert]

Update,

The problem isn't solved, as in I still see the continuity errors in the stream. But the steps I took are below

The ceton is now on a fixed IP connected directly to a Intel Gb Nic on the server.
The 3gbs lag enabled NIC is now active again
Jumbo frames disabled on both the server and the clients
Microsoft QOS packet scheduler disabled on the clients and the server
Owlroosts tsreader.ax on the clients.
UNC paths enabled (needed for the HDPVR) RTSP will show a black screen due to the lag in channel changing. (is there a way to delay the start of the video stream to compensate so RTSP can be used???)

Last night I had two recordings going from the ceton, one live timeshift going from the ceton, and I was playing back a recording. Comskip was also running on one of the files.

I am seeing periodic glitches in the video stream but they are not causing freezes anymore at this point.

Any further testing or logs I can provide, I will gladly do.

 

[mm1352000]

mguebert, I'm sure the frustration levels are starting to peak. I'd really like to be able to help with a bunch of suggestions, but to be completely honest I'm a bit stumped at this point.

The way I see it, the first and most important thing to solve would be the glitches in the stream from the Ceton tuner. If you don't deal with that, any stream originating from that tuner (including recordings) played on any PC - client or server - will have glitches. This makes it significantly more difficult to debug streaming issues between the server and client(s).

The question then becomes: what more can be done to debug and find the cause of these glitches... to which my answer is currently "I don't know".

About all I can say with 100% confidence at this point is that if the IPTV source log contains discontinuity warnings/errors in it, it means the stream being received from the tuner is not glitch free. If you've simplified to the point of a normal W7 install with latest service packs and patches, latest stable Ceton software (drivers and firmware), crossover cable connecting the tuner to the server, disabled all fancy network protocols and features (link aggregation/teaming, VPN stuff, QoS stuff, IPv6, jumbo packets), disabled all firewalls, removed all cable splitters, closed all other user applications using the network and/or tuners... then things are really getting to the point where I'd be questioning the cable signal quality. I know you said it was fine with Sage and I don't doubt that... I just think that we're getting to the point where assumptions made previously need to be carefully re-evaluated.

For example: you said Sage was working on the same hardware. From your comment about experimentation with ESXi etc. I am implying that it wasn't the same OS... or at least not the same install.

I start to wonder...

Could network adaptor drivers be a factor?
Are you running the latest Intel chipset and NIC drivers?
Have you tried using latencymon or DPC Latency Checker to check that drivers are happy when attempting to receive from the tuner?
Have you tried installing Sage or any other HTPC software that can receive from the tuner to isolate the problem to TV Server?


In parallel I know that you're also having the problem with the HD-PVR. The issue using an HD-PVR and/or Colossus with a multi-seat setup (ie. server + client(s)) are known. At this point there is no solution except to use UNC.

mm

 

[mguebert]

MM1352000,

Thanks for all of your words of advice. I am still trying to solve the issues. Although with the current setup it is at least not freezing anymore.

To answer some of your questions, you are correct. I did blow out the OS when transitioning from sage, it had been running for quite awhile and I felt a fresh OS load was the way to go. I did at that point experiment with ESXI. When I started seeing all of the freezes I stopped that experiment and went with a native Win 7 x64 install after a detour with trying WHS2011.

To be honest I am running all of the built in drivers. I will try updating those. As far as signal goes I don't have any way of disputing that other than the ceton web page. Screenshot attached. It indicates decent signal if I understand it correctly.

Currently the Ceton card is connected directly to it's own Intel gb nic on fixed IP address. There are no drivers or software installed for the ceton card. TV service sees them no problem.

I am not familiar with the DPC check, although I have seen some stuff about it. Is there anything specific I should be looking for?

 

[mm1352000]

Just a quick reply...

Thanks for all of your words of advice. I am still trying to solve the issues. Although with the current setup it is at least not freezing anymore.

Thanks, and that sounds positive.

To answer some of your questions, you are correct. I did blow out the OS when transitioning from sage, it had been running for quite awhile and I felt a fresh OS load was the way to go. I did at that point experiment with ESXI. When I started seeing all of the freezes I stopped that experiment and went with a native Win 7 x64 install after a detour with trying WHS2011.

Understood.

To be honest I am running all of the built in drivers. I will try updating those.

Okay, great.

As far as signal goes I don't have any way of disputing that other than the ceton web page. Screenshot attached. It indicates decent signal if I understand it correctly.

I don't see any signal strength/quality ratings other than "carrier lock" which is true/false. I do recall your quoted dB ratings, which I'd agree seem reasonable. However, I suspect those readings won't show occasional glitches very well. They're better at showing the average level/quality.

Currently the Ceton card is connected directly to it's own Intel gb nic on fixed IP address. There are no drivers or software installed for the ceton card. TV service sees them no problem.

Yep, understood. I was suggesting to install the Ceton software (downloadable from their website) as it might get you firmware updates.

I am not familiar with the DPC check, although I have seen some stuff about it. Is there anything specific I should be looking for?

Hopefully it should be fairly self evident once you see the user interface. I've only used DPC latency checker, but I think latencymon is similar. Basically there is a continuous graph of the deferred procedure call latency value. Green (short) is okay; yellow (medium) is maybe dodgy; red (long/tall) is bad => could cause glitches. Any red or yellow bars at the same time as glitches is what you're looking for.

[edit: The other thing I meant to say is that the data level debug for the IPTV source is not proving useful. I'd definitely throttle that back to "verbose" (4).]

 

[mguebert]

Again MM1352000 thanks so much for your patience and help. I may have found the problem. On a fluke I decided to pull the cable company installed amp / splitter out of the chain. It has been there since the beginning so I didn't think anything of it. I pulled it out and started timeshifting from all 6 tuners simultaneously for 20 minutes and I saw 3 continuity errors, that coincided with my starting of the 4th stream. Since then I have seen very few if any continuity errors. Certainly no where near what I was seeing before. The strange thing is that the signal levels as shown in the ceton screen are very much the same as before. Maybe the amp / splitter was introducing noise (it is an active splitter / amp)?

On another note, I see this frequently on startup, where the tuners show as NA NA in the tv service screen. Stopping and restarting the service brings them to normal.