Client Connection Problems (1 Viewer)

[rsbrux]

Thanks for the additional suggestions! . I have meanwhile:

1. Disabled Defender by editing the registry
2. Updated my WLAN router to the latest available SW (Gargoyle 1.8.1)

Attached you will find logs of my most recent attempt, as well as a couple of TaskManager screenshots taken while streaming. The most demanded resource appears to be memory, not CPU. The CPU usage never exceeded 50% total, and the memory usage never exceeded 60% (although I have seen memory max out on previous attempts). Again the network loading appears surprisingly low.

Could you please add a screenshot of the LAV video codec settings?
I'd like to know what hardware acceleration (DXVA) setting you're using.

I'm not quite sure what you mean by this, but hope the attached screenshots are adequate

Hmmm. So, in general this is a slightly better result compared to the HD channel, right?

Yes, and after disabling Defender and updating the router SW, the results improved more, but are still unwatchable.
MP no longer hangs completely, nor does it pop up a connection error or ask me to redefine the server.
When started in the standard bug reporting mode (as shown in the attached logs), it still does not exit completely when I close the GUI, and has to be killed via TaskManager. However, when I start it with the Frames skin (my preference, and presumably much lower overhead) it does exit properly. I was surprised that WatchDog's default bug reporting mode started the Titan skin instead of DefaultWide, as I thought that Titan was no longer the default skin.

Some other things that I think would be worth trying...

• try UNC paths rather than RTSP for streaming (wiki)

What do you mean here? My client options in 1.13 only give me the option to "force RTSP usage" (which is not checked). Doesn't that mean that UNC is already being used?.

• try to copy SD and HD TV recordings to the compute stick's HDD and check if the compute stick can play them smoothly (if it can't, we might suspect the network is not the primary problem)

A recorded TS file which I copied from the TV Server onto an SDHC card plays fine on the ComputeStick, using the OOB W10 "Movies & TV" application.

• try channels/recordings with MPEG 2 video (if you have them) instead of h.264 video (if this makes a difference, we might suspect the load from decoding the video is overloading the CPU or GPU (...or maybe thermal throttling is occurring)

Isn't that what I already have? The recording from RTL (my test channel in the last several tries), which I copied for the test above, is described under Windows 7 as "MPEG-2 TS Video".

• install this patch

Do you mean this?

...and anything relating to network security on both client and server (eg. firewalls, network security monitors etc.) is worth checking.

I have already used the script from this wiki page to ensure that the needed firewall ports are open, and have even given up on keeping my WLAN connection Private (Windows 10 likes to switch it back to Public), so I . I am using the OOB W10 installation provided on the ComputeStick, and haven't set up any special security features on my routers. What other "network security monitors" might i have to consider?

 

[rsbrux]

Oh, and one more suggestion for the list: try disabling teletext subtitles.
http://wiki.team-mediaportal.com/1_...iguration/22_TV/1_TV_Client#Subtitle_Settings

It's a long shot, but I think still worth double-checking.

Attached are logfiles and TM screenshot with the new core.dll and teletext subtitles disabled.
I observed a maximum of 44% CPU and 64% memory load. There was no significant improvement in playback quality, but the MP client terminated properly when I closed the GUI.
Thanks again for your support!

P.S: forgot server logs ;-}

 

[mm1352000]

The CPU usage never exceeded 50% total...

It seems that you don't understand: this is a problem (!). If you see total CPU usage of approximately 25% on the compute stick, you need to realise that the CPU is likely to be overloaded.

Generally speaking most software these days is [still] primarily single threaded. Certainly MP is mainly single threaded. That means it will mostly only use one CPU core. Your CPU has four cores. When single threaded software runs on your CPU, one core will be loaded and the other three cores will be idle (do nothing). When one CPU core is running at maximum load and the other cores are idle, Windows Task Manager will report the CPU usage as 25%. This is deceptive because it suggests that there is 75% "head-room". However, single threaded software cannot use the other three cores. Therefore you should consider this situation as if the CPU usage is actually 100%.

In other words, I recommend you learn to think about the CPU usage per core. Windows Task Manager -> performance tab -> resource monitor -> CPU tab can show you this. If the CPU usage for any core is 90% or higher then it should be cause for concern.

Could you please add a screenshot of the LAV video codec settings?
I'd like to know what hardware acceleration (DXVA) setting you're using.

I'm not quite sure what you mean by this, but hope the attached screenshots are adequate

Yes, they are perfect - thanks.
LAV-Video1.png shows the settings that you normally need to care about.
...and again you have a problem there. "Hardware decoder to use" is set to "none". This means that if MP uses the LAV video codec, the compute stick's CPU will be used to decode/decompress the video. Using the CPU is not optimal because the GPU has dedicated hardware for doing the job with much lower power and minimal CPU usage. With a low power system like the compute stick you should want - even need - to use that dedicated GPU hardware whenever possible.

So, please:

1. Change the LAV video codec "hardware decoder to use" setting to DXVA2 or QuickSync.
2. Ensure MP is configured to use the LAV video codec in all cases (video, TV, DVD, Blu-Ray...).
3. Try to view TV in MP again and check task manager -> performance -> resource monitor for CPU, network etc.

Hmmm. So, in general this is a slightly better result compared to the HD channel, right?

Yes, and after disabling Defender and updating the router SW, the results improved more, but are still unwatchable.
MP no longer hangs completely, nor does it pop up a connection error or ask me to redefine the server.

Decoding h.264 video - even SD - can be quite taxing for a CPU. Disabling Defender may have reduced the CPU load enough to show the improvements that you see. However you should be able to do better by following the recommendations above.

When started in the standard bug reporting mode (as shown in the attached logs), it still does not exit completely when I close the GUI, and has to be killed via TaskManager.

The last entries in the log file are:

[2016-02-06 10:26:06,466] [Log ] [MPMain ] [INFO ] - RemoteControl - Connected
[2016-02-06 10:26:06,467] [Log ] [MPMain ] [INFO ] - TVHome: OnRemotingConnected, recovered from a disconnection
[2016-02-06 10:26:06,501] [Log ] [MPMain ] [INFO ] - TvNotify: stop
[2016-02-06 10:26:06,503] [Log ] [MPMain ] [DEBUG] - TVHome: HeartBeat Transmitter stopped.

So, I suspect this may be due to the TV plugin's connection to the server. We'll see if the recommendations above also help with this.

However, when I start it with the Frames skin (my preference, and presumably much lower overhead) it does exit properly.

Maybe the lower overhead helps... or maybe it's just coincidence. I don't know. Never used Frames.

I was surprised that WatchDog's default bug reporting mode started the Titan skin instead of DefaultWide, as I thought that Titan was no longer the default skin.

Nope, the default skin is still Titan AFAIK.

What do you mean here? My client options in 1.13 only give me the option to "force RTSP usage" (which is not checked). Doesn't that mean that UNC is already being used?

Are you looking at the settings on the compute stick, or on the PC where TV Server is installed?
You should be looking on the compute stick. Since TV Server is not installed on the compute stick, you should be able to choose either RTSP (default) or UNC.
.

A recorded TS file which I copied from the TV Server onto an SDHC card plays fine on the ComputeStick, using the OOB W10 "Movies & TV" application.

Please try to play the file with MediaPortal.

• try channels/recordings with MPEG 2 video (if you have them) instead of h.264 video (if this makes a difference, we might suspect the load from decoding the video is overloading the CPU or GPU (...or maybe thermal throttling is occurring)

Isn't that what I already have? The recording from RTL (my test channel in the last several tries), which I copied for the test above, is described under Windows 7 as "MPEG-2 TS Video".

No, it isn't what you already have. All the channels I've seen you view in the log files - including RTL - have been h.264/AVC video:
[2016-02-06 10:23:24,355] [Log ] [MPMain ] [INFO ] - TVHome.ViewChannelAndCheck(): View channel=RTL
...
[2016-02-06 10:23:25,764] [Log ] [MPMain ] [INFO ] - TsReaderPlayer: OnVideoFormatChanged - streamtype=H264 resolution=720x576 aspect ratio=16:9 bitrate=0 isInterlaced=True

"MPEG 2 TS" is MPEG 2 transport stream. It's a container format like MP4, MKV, WMV, AVI. The internal video and audio format can be h.264/AVC, h.265/HEVC, MPEG 2... etc.

Do you mean this?

Yes.

What other "network security monitors" might i have to consider?

Most security ("anti virus" etc.) software these days (Norton, McAfee, etc.) includes some kind of network-related security or monitor. Therefore you should consider any security software you have installed. I can't see which software you've installed, so I can't be more specific than that. Maybe you have nothing more than Windows Defender and Windows Firewall - fine. It's just a suggestion.

 

[rsbrux]

The CPU usage never exceeded 50% total...

It seems that you don't understand: this is a problem (!). If you see total CPU usage of approximately 25% on the compute stick, you need to realise that the CPU is likely to be overloaded.
In other words, I recommend you learn to think about the CPU usage per core. Windows Task Manager -> performance tab -> resource monitor -> CPU tab can show you this. If the CPU usage for any core is 90% or higher then it should be cause for concern.

Quite true; I didn't consider that. Thanks for explaining this so patiently!
I found the Resource Monitor display somewhat confusing, as it repeatedly indicated 100% load under "CPU - Total", (even when I successfully played a previously recorded video), although none of the individual cores showed a high load.

1. Change the LAV video codec "hardware decoder to use" setting to DXVA2 or QuickSync.
2. Ensure MP is configured to use the LAV video codec in all cases (video, TV, DVD, Blu-Ray...).
3. Try to view TV in MP again and check task manager -> performance -> resource monitor for CPU, network etc.

Since there are two choices for DXVA2, I opted for Intel QuickSync. All of the attached data reflect this setting, as well as using LAV throughout.

So, I suspect this may be due to the TV plugin's connection to the server. We'll see if the recommendations above also help with this.

I have attached logs for 3 attempts:

1. Using UNC: there were relatively long delays in TV navigation (e.g. displaying the TV Guide). The MP client said it couldn't play the timeshift file (see error.png), but exited gracefully when I closed the GUI.
   
2. Playing the previously copied TV recording out of the local client's Video folder. Playback was fine, and the MP client again exited gracefully when I closed the GUI.
3. Retry with RTSP (and Intel QuickSync), given the failure of 1 above. There was only a brief fragment of audio, but no video. The MP client failed to exit completely when I closed the GUI, and had to be terminated via Task Manager.

Are you looking at the settings on the compute stick, or on the PC where TV Server is installed?
You should be looking on the compute stick. Since TV Server is not installed on the compute stick, you should be able to choose either RTSP (default) or UNC.

Quite right; I was looking at the wrong client settings. On the Compute Stick, the corresponding option is to force UNC (RTSP is not mentioned).
[/quote]

Please try to play the file with MediaPortal.

This worked fine. Please see 2nd set of attached logs.

No, it isn't what you already have. All the channels I've seen you view in the log files - including RTL - have been h.264/AVC video:

I couldn't find any information from my cable provider, which identifies any channels as carrying MPEG-2 encodiing as opposed to H.264, nor could I find any clues in the exported tuning details from the MP TV Server. Is there some way to identify potential candidates, short of zapping through all 50+ FTA channels and then checking the log?

Most security ("anti virus" etc.) software these days (Norton, McAfee, etc.) includes some kind of network-related security or monitor. Therefore you should consider any security software you have installed. I can't see which software you've installed, so I can't be more specific than that. Maybe you have nothing more than Windows Defender and Windows Firewall - fine. It's just a suggestion.

Thanks, I didn't install anything else. I wanted to stay as close as possible to bog-standard OOTB W10, to keep things as simple as possible.
Thanks again for all of your help!

 

[mm1352000]

I found the Resource Monitor display somewhat confusing, as it repeatedly indicated 100% load under "CPU - Total", (even when I successfully played a previously recorded video), although none of the individual cores showed a high load.

Hmm, I don't see this in any of your 3 screenshots. Only "rm2" shows some/all of the cores reaching 100% load for a little while.
Are you sure you're not confused by the graph scale markings ("0%" and "100%" beside each graph)?
What did the "service CPU usage" show?

Since there are two choices for DXVA2, I opted for Intel QuickSync. All of the attached data reflect this setting, as well as using LAV throughout.

Oh, yes - sorry I forgot about that. Prefer DXVA2 native. AFAIK the copy-back one is not necessary for you.

I have attached logs for 3 attempts...

In future if you're going to attach more than 1 set of log files, please rename the zip files for clarity. It helps me figure out which set of log files goes with each description. Also, there are/were actually 4 sets of log files attached. From the file names and sizes I guessed that the *11_17.zip ones were duplicates.

For the UNC case...
I think the delay was nothing to do with UNC and everything to do with the DB connection:
[collapse]
[2016-02-07 10:09:12,341] [Error ] [TvClient-TvHome: HeartBeat transmitter thread] [ERROR] - TVHome: Error in Reload
[2016-02-07 10:09:12,403] [Log ] [TvClient-TvHome: HeartBeat transmitter thread] [ERROR] - Exception: Error: StatementErrorUnclassified
Gentle.Common.GentleException: select idChannel, isRadio, isTv, timesWatched, totalTimeWatched, grabEpg, lastGrabTime, sortOrder, visibleInGuide, externalId, displayName, epgHasGaps, channelNumber from Channel where isTv = @isTv order by sortOrder asc; ---> System.Data.SqlClient.SqlException: Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding. ---> System.ComponentModel.Win32Exception: The wait operation timed out[/collapse]

I think the failure to play the time-shift file is due to errors in the share configuration (eg. lack of permissions).
[2016-02-07 10:09:40,562] [Log ] [MPMain ] [INFO ] - tvhome:startplay:\\scaleoe\D\ProgramData\Team MediaPortal\MediaPortal TV Server\timeshiftbuffer\live3-0.ts.tsbuffer - using rtsp mode:False
...
[2016-02-07 10:10:21,569] [Log ] [MPMain ] [INFO ] - tvhome:startplay: waiting for TS file \\scaleoe\D\ProgramData\Team MediaPortal\MediaPortal TV Server\timeshiftbuffer\live3-0.ts.tsbuffer

For the copied TS file case...
I think this was meant to be shown in the *11_17.zip log files. Unfortunately those log files seem to have been collected with Watchdog option 3 and log level set to "error", and therefore they show almost nothing. Nevertheless I believe the result.
Can the same file be played by MediaPortal -> "My Videos" if you put it in a share on the server?

For the RTSP case...
Please try LAV with the DXVA 2 native option (...but to be honest, the result with the copied TS file suggests the problem is more likely to be with the network connection than the codec settings now. Maybe there was a codec problem before, but now it seems like that problem should be solved.)

Is there some way to identify potential candidates, short of zapping through all 50+ FTA channels and then checking the log?

Unfortunately no. However I think the copied TS test shows that we don't need to worry about this. If the compute stick can play a recording from a channel, it should be able to show live TV for that channel.

So in summary, it looks more and

 

[rsbrux]

Hmm, I don't see this in any of your 3 screenshots. Only "rm2" shows some/all of the cores reaching 100% load for a little while.
Are you sure you're not confused by the graph scale markings ("0%" and "100%" beside each graph)?
What did the "service CPU usage" show?

What confused me was the blue line, indicating CPU clock frequency. The service loading is negligible.

Oh, yes - sorry I forgot about that. Prefer DXVA2 native. AFAIK the copy-back one is not necessary for you.

done

For the UNC case...
I think the delay was nothing to do with UNC and everything to do with the DB connection:

Presuming that the DB connection is needed to display the guide, it works well most of the time.

I think the failure to play the time-shift file is due to errors in the share configuration (eg. lack of permissions).

Quite likely: I am reluctant to set up a domain or even a Homegroup, and remote authentication has gotten trickier since Vista

For the copied TS file case...
I think this was meant to be shown in the *11_17.zip log files. Unfortunately those log files seem to have been collected with Watchdog option 3 and log level set to "error", and therefore they show almost nothing. Nevertheless I believe the result.
Can the same file be played by MediaPortal -> "My Videos" if you put it in a share on the server?

This works, but the quality is nearly as bad as streaming live TV (stuttering, intermittent long pauses).

For the RTSP case...
Please try LAV with the DXVA 2 native option (...but to be honest, the result with the copied TS file suggests the problem is more likely to be with the network connection than the codec settings now. Maybe there was a codec problem before, but now it seems like that problem should be solved.)

done but still unwatchable (stuttering, intermittent long pauses).

So in summary, it looks more and

Presumably there was a bit more coming ;-) IAC, it smells like a network problem to me. Since the network monitor on the client shows light loading, I have tried moving the WLAN router closer to the client. This resulted in the client showing an additional bar in the signal strength display, but the performance is no better. Attached are some logs and screenshots from an attempt yesterday.
I have now measured the signal at the ComputeStick location with the Android app "WiFi Analyzer", which gives it -65dbm.
I will try a different channel, but the ComputeStick only sees 2.4 GHz, so it's a bit crowded.

 

[mm1352000]

IAC, it smells like a network problem to me.

Yes, I agree.

The resource manager screenshot shows the network load at 1681 kb/s. That seems very low even for an SD stream. If that is the capacity of the wireless link then it won't be possible to use it for TV streaming.

If you simply try to copy a large file from the server share to the compute stick (or vice versa), what network speed/bandwidth/throughput do you get?

 

[rsbrux]

In my last post I forgot to mention that I also updated the router firmware to Gargoyle 1.8.1. Meanwhile I have also changed the channel to one which is less crowded. The connection properties show 72 Mbps for the WLAN connection I am using (see "WiFi Status.png"), but when I tried to copy a 10GB TV recording from a share on my TV server to the Compute Stick, it looked like it was being limited to 8Mbps (see "10GB copy*.png" and "copy speed*.png"). Streaming TV from MP got a little bit less. At first I thought it was because the connection was identified as "metered", but turning that off didn't help. The limitation appears to be the ComputeStick running Windows 10 Home rather than the router. I repeated the experiment with a laptop running Windows 8.1 Pro placed near the Compute Stick. The connection properties show only slightly better BW (see "x230t wifi properties.jpg"), but the copy performance was significantly better.(see "x230t copy speed.jpg", "RM.jpg" and "Tm.jpg"). Since it's clear that MP is not to blame, I am scouring the net for ideas about the cause. Any tips would be welcome.

 

[mm1352000]

Hmmmm, I think you definitely found the problem there. 72 Mbps is almost as slow as 802.11g (54 Mbps)... and if I'm not wrong that is only the "sync" speed (which is part of the reason you get 8 Mbps instead of 72 Mbps on the file copy).

Perhaps it would be worth trying LatencyMon to confirm you don't have DPC latency problems with drivers on the compute stick. Aside from that I'm not sure what else to suggest. 8 Mbps usable bandwidth should be enough for SD TV in most cases, but probably still not quite good enough for HD.

 

[rsbrux]

I have found some posts complaining about the poor performance of the Compute Stick's built-in WLAN, but I don't understand how it can be so much worse than a laptop.
I tried out LatencyMon, but don't really understand the results. Attached are LatencyMon reports for:

1. Windows and normal services (Defender reenabled)
2. MP launched through Watchdog (logs also attached)
3. MP launched directly (without Watchdog)

I have also included a screenshot of LatencyMon from the last case. I have checked the BIOS and WIndows Power Options and both are set for maximum performance (although Windows 10 Home Edition doesn't give control of anything other than sleep timers).

Any other ideas what I can do (besides giving up on the built-in LAN and getting a USB WiFi dongle) would be most welcome!