Help with slow tuning (2 Viewers)

[jonm]

OK generic was fastest in my testing so that's good.

 

[porky996t]

Hi,

Things seem to have settled down a bit here; I haven't changed anything at all. Initialisation of client to watch live TV now takes around 11 seconds, and thereafter channel change takes about 4 seconds, maybe up to 5 secs for a HD channel change.

I don't know if it is possible to get these times down anymore, but it would help the WAF.

Thanks!

 

[jonm]

I guess it's a case of working out if that 11 seconds delay is in the client or on the server. Without knowing where the delay is, I wonder if "preloading" the cards might help here? As for channel change times, mine are about the same, I'd love to get them quicker!

 

[octessence]

I would check the TV server log first and check the time it takes to tune. Mines about 0.8s now like I said. If you have cygwin, it's useful to do a tail -f on the TV server log just before switching.

Also using the LAV filters does seem to help on the client side as suggested by someone above.

 

[ianc]

I'm having a similar issue of very slow channel switching except that mine appears to be very temporarily fixed with a restart and a deleting of the tv.log.

See extracts

2012-11-18 16:52:19.616632 [(7)]: AdvancedCardAllocation.GetAvailableCardsForChannel took 66 msec
  
#### and a few hours later
  
2012-11-18 21:05:42.934992 [(23)]: AdvancedCardAllocation.GetAvailableCardsForChannel took 1264 msec

My tv.log ends up being 10MB+ very quickly due to WebEPG spewing into it and I was thing that this may be a contributer.

Is there a way to turndown the logging level in TVServer?

I couldn't see a setting in the config tool.

 

[mm1352000]

@porky996t
Your problem looks to me like it could be network related.
Have you got the IPv6 protocol enabled on any of the PCs involved?
What about firewalls?
Are you using static IP addresses, and is MP/TV Server configured with the IP addresses or hostnames?

 

[mm1352000]

@ianc
To me it looks like your problem is HDD or CPU speed/stress. Everything is just generally sluggish without good cause. Check for real-time scanners and HDD free space.

Generally speaking, aside from code efficiency and overall system capability these are the things that determine zap time:

1. Tuner driver.
2. CAM/decryption solution.
3. Server CPU load and HDD speed, load, free space and fragmentation.
4. Network configuration - firewall, IPv6, wireless/wired, DNS.
5. Codecs, GPU and HDD on the client side.
6. Zap delay setting.

You can monitor (1) by checking the tv.log. In particular, how long does it take to apply the tune request:

2012-11-18 21:06:38.190851 [(23)]: dvbubmit tunerequest calling put_TuneRequest
2012-11-18 21:06:38.445734 [(23)]: dvbubmit tunerequest done calling put_TuneRequest

...and how long does it take to start the graph:

2012-11-18 21:06:38.623468 [(23)]: RunGraph
2012-11-18 21:06:38.712336 [(23)]: dvb: LockedInOnSignal ok

For (2), check how long it takes before audio/video is seen:

2012-11-18 21:06:44.810968 [(23)]: card: WaitForTimeShiftFile - waiting _eventAudio & _eventVideo
2012-11-18 21:06:44.898859 [(23)]: card: WaitForTimeShiftFile - video and audio are seen after 0.086914 seconds

For (3), look at overall "sluggishness" of the server. If the tuning process doesn't have any unusual delays but everything seems generally slower then this is almost a certain sign of real-time scanning causing problems for the HDD and/or CPU.

For (4), attempt to correlate the MediaPortal.log and tv.log and look for reasonably significant delays that don't have any good justification. This takes a little familiarity with the code and/or tuning process.

(5) is quite subjective. You're basically looking at how long it takes between when the light on the TV button [in the MP UI] turns on and when you start seeing video and hearing audio.

(6) is a setting. If you find working with the remote slow but selecting a channel through the mini-guide fast then the zap delay is to blame.

Of course there are always exceptions.

mm

 

[ianc]

@ianc
To me it looks like your problem is HDD or CPU speed/stress. Everything is just generally sluggish without good cause. Check for real-time scanners and HDD free space.

Generally speaking, aside from code efficiency and overall system capability these are the things that determine zap time:

1. Tuner driver.
2. CAM/decryption solution.
3. Server CPU load and HDD speed, load, free space and fragmentation.
4. Network configuration - firewall, IPv6, wireless/wired, DNS.
5. Codecs, GPU and HDD on the client side.
6. Zap delay setting.

You can monitor (1) by checking the tv.log. In particular, how long does it take to apply the tune request:

2012-11-18 21:06:38.190851 [(23)]: dvbubmit tunerequest calling put_TuneRequest
2012-11-18 21:06:38.445734 [(23)]: dvbubmit tunerequest done calling put_TuneRequest

...and how long does it take to start the graph:

2012-11-18 21:06:38.623468 [(23)]: RunGraph
2012-11-18 21:06:38.712336 [(23)]: dvb: LockedInOnSignal ok

For (2), check how long it takes before audio/video is seen:

2012-11-18 21:06:44.810968 [(23)]: card: WaitForTimeShiftFile - waiting _eventAudio & _eventVideo
2012-11-18 21:06:44.898859 [(23)]: card: WaitForTimeShiftFile - video and audio are seen after 0.086914 seconds

For (3), look at overall "sluggishness" of the server. If the tuning process doesn't have any unusual delays but everything seems generally slower then this is almost a certain sign of real-time scanning causing problems for the HDD and/or CPU.

For (4), attempt to correlate the MediaPortal.log and tv.log and look for reasonably significant delays that don't have any good justification. This takes a little familiarity with the code and/or tuning process.

(5) is quite subjective. You're basically looking at how long it takes between when the light on the TV button [in the MP UI] turns on and when you start seeing video and hearing audio.

(6) is a setting. If you find working with the remote slow but selecting a channel through the mini-guide fast then the zap delay is to blame.

Of course there are always exceptions.

mm

mm - The problem is specifically on "AdvancedCardAllocation.GetAvailableCardsForChannel" where it goes from 66ms to 1500ms over the course of an afternoon.

 

[ianc]

Some additional testing:
1) Channel select after running for the day and it takes 10+ seconds (DVB-S) and you can see "AdvancedCardAllocation.GetAvailableCardsForChannel " taking 1500ms and the function being called several times per station select. (see 2012-11-19 19:58:08.211359 in large attaached log)
2) Stopped and restarted TVService (2012-11-19 20:00:21.728937). Repreated the test with similar slow results
3) Stopped service and removed the log file and restarted. "AdvancedCardAllocation.GetAvailableCardsForChannel " now taking <100ms on average. See smaller log file attached.

So it seems to be impacted by logfile size. Any thoughts/suggestions?
Is there a way to reduce the verbosity of the log file?

 

[mm1352000]

mm - The problem is specifically on "AdvancedCardAllocation.GetAvailableCardsForChannel" where it goes from 66ms to 1500ms over the course of an afternoon.

I don't fully agree. Look at the rest of the tuning process as well and you'll see *everything* becomes more sluggish. The difference is not solely due to the advancedcardallocation function. Example from your first set of logs:

2012-11-18 16:52:20.983820 [(7)]: WaitForPmt: PMT handling took 0.1972656 seconds.

2012-11-18 21:07:10.388117 [(23)]: WaitForPmt: PMT handling took 3.5947265 seconds.

1. How full is your C: drive?
2. How hard are your CPU and HDD working when the tuning is slow?

So it seems to be impacted by logfile size. Any thoughts/suggestions?
Is there a way to reduce the verbosity of the log file?

I'm not convinced that the logging is the core issue. If you're saying that only deleting the tv.log makes that sort of difference then it doesn't make sense to me unless deleting the other log files has a similar impact. I'd say it is a symptom of something else. Are you running an SSD for your system drive? Again, how full is your system and timeshifting drive?