MP1.16 Remote Client Unable to Play: B43534E1 error watching Recorded TV (9 Viewers)

[mm1352000]

Hmmm, the hard page faults look like they might warrant some attention. My understanding of the meaning of hard page faults is that they indicate your physical memory (RAM) is full and some memory access had to "swap" via the page file on disk (HDD or SSD). Having some hard page faults is normal when you have lots of stuff open and not so much RAM. However filling 12 GB of RAM... and 0.5 second resolutions times... that's enough to make me do a double take.

Please check if the Windows page file is on your SSD or one of the HDDs.
Please check what's eating up all your RAM. I suspect Chrome may have something to do with it.
You may need to consider limiting the amount of stuff you leave open. Alternatively - and this may not help at all... - you may need to consider increasing the TV service's priority.

[edit: Meant to say, see if you can drill down a bit more into the page fault detail. The text file you attached is basically only a summary. Find out if TVService.exe is being hit by them. If it is, in my opinion there's a good chance that's the cause of your streaming troubles.]

 

[RonD]

I read the memory story this way, 12 GB total, 6 GB in use, 6 GB available. Memory tabs for current state in picture. If I only had 4 GB DRAM, paging would be important. After switching to W10 I find systems really want 6 to 8 GB, with 4GB I often saw paging.

from "How to use Windows 10's Resource Monitor to track memory usage" How to use Windows 10's Resource Monitor to track memory usage - TechRepublic Standby = The Standby list is shown in blue. If contains pages that have been removed from process working sets, but that are still linked to their working sets. The Standby list is basically a cache, but memory pages in the list are prioritized in a range of 0-7 (with 7 being the highest).

 

[mm1352000]

I see the hard page fault count there is 0 for both Chrome (which LatencyMon said had the highest hard page fault) and the TV service.
Did you restart the PC, or is that count only for the time that you were viewing?
It'd be interesting to keep the resource monitor open and try to stream a few recordings from clients. If you hit the problem, you could check whether the TV service hard page fault count increased.

Also, still interested to know whether your page file is on SSD or HDD.

 

[RonD]

page file is SSD, I don't typically see a lot of hard-fault paging on resource monitor. A little hard to do remote Client activity in Living Room and see TV Server Resource monitor in bedroom. I'll look into using ProcessMonitor SW to watch tvserver tomorrow

 

[RonD]

the 2 to 3 times I played with LatencyMon today, it starts off with low numbers but while running for 5 to 10 minutes it "pulse catch" worst case spikes, the longer it ran, the higher the numbers got. Two more picts. Almost want a histogram of LatencyMon results. Which of 3 LatencyMon reports show the true picture?

LatMon1minute_tvserverbusy.PNG tvserver recording 3 ATSC chanels, 60 Mbps HDHR ethernet traffic

LatencyMon_1min_3comskips.PNG a few minutes later, done recording news, 3 comksips running

 

[Owlsroost]

As an experiment, attached is a version of TsReader.ax (for the client) with the RTSP timeouts for the disk-related requests only - InternalPlay() and UpdateDuration() - increased to 2 seconds (from 0.5s). Just replace TsReader.ax in C:\Program Files (x86)\Team MediaPortal\MediaPortal with the new version.

The RTSP code for the pre-MP 1.16 versions is quite different, so I haven't managed to work out what the timeout used to be - mm, do you have any idea?

 

[Owlsroost]

TV Server is core i5, 3.1 GHz, 4 core, 12 GB DRAM, Windows 10 Home
C-drive is EVO 850 SSD 240 GB, used for windows, MP programs, MP data, SQL database
K-drive is WD HDD 3000 GB about 600 GB free space dedicated for recordings,
L-drive is WD HDD 2000 GB timeshift and other misc stuff

Is the K drive a WD 'Green' HDD by any chance?

Certainly in the past, these used to spin-down when idle all by themselves (not just when the OS told them to, it was controlled by the drive firmware) - I used to have one in my old HTPC. I haven't used a recent version of them, so I don't know if the current versions still do that.

Because Windows (and the drives themselves) do extensive data caching, if it's got the part of the file that is requested still in the cache, you can have a situation (I've seen it happen occasionally) where a video starts playing (from the cache), then pauses because the next part has to be read from a disk which is stopped (the pause = spin-up delay). This could account for the situation where recording playback starts OK (from the cache), then dies dues to the spin-up delay when it seeks to the 'resume' point (needs new data from disk).

 

[RonD]

L: = Green bought it a few years ago, K: = Blue "WD everyday" 5400 rpm. But between Win10 and WD its never clear what settings really control what. Do WD internal setting override Win10 commands?

Also even though I set Win10 Defender to exclude K:\MePo1\recordings, procmon showed MsMpEng (Defender) peeked at a few files this morning. see pict. Also noticed I have indexing enabled on K:

Will modify Defender Exclude setting to ignore complete K;-Drive, turn off indexing, and maybe look around for WD utils to tweak WD settings. Looked at K:-drive SMART info, no obvious signs of CRC errors, sector reallocation, or other drive problems.

Also noticed that procmon has a duration column, will include that to see if drive shows long "duration" times. So far have not found any Win10 documentation that defines "duration column".

 

[RonD]

As an experiment, attached is a version of TsReader.ax (for the client) with the RTSP timeouts for the disk-related requests only - InternalPlay() and UpdateDuration() - increased to 2 seconds (from 0.5s). Just replace TsReader.ax in C:\Program Files (x86)\Team MediaPortal\MediaPortal with the new version.

will try this later today or tomorrow

 

[mm1352000]

The RTSP code for the pre-MP 1.16 versions is quite different, so I haven't managed to work out what the timeout used to be - mm, do you have any idea?

Yeah, the timeout was infinite.

Example sending RTSP DESCRIBE command:
MediaPortal-1/RTSPClient.cpp at c0923d0d5b24ed66548e7ca288cc4799805d7820 · MediaPortal/MediaPortal-1 · GitHub

result = rtspClient->describeURL(url);

We don't override the default timeout value:
MediaPortal-1/RTSPClient.hh at c0923d0d5b24ed66548e7ca288cc4799805d7820 · MediaPortal/MediaPortal-1 · GitHub

char* describeURL(char const* url, Authenticator* authenticator = NULL, Boolean allowKasennaProtocol = False, int timeout = -1);

As a result, the socket handling is blocking (rather than non-blocking/async):
MediaPortal-1/RTSPClient.cpp at c0923d0d5b24ed66548e7ca288cc4799805d7820 · MediaPortal/MediaPortal-1 · GitHub

I chose the 500 milli-second value. I wanted to be generous, but at the same time, knowing that channel changing etc. in the MP code is currently still synchronous, I knew that the value I chose would directly affect how long people would have to wait for a channel change to complete/fail in error scenarios. I figured most people wouldn't tolerate more than a second or two... especially considering that a channel change could conceivably have already taken five seconds or more. Since 99.9% of the time we're expecting to be communicating with a server which is on the local network (often the same box - single-seat), I settled on the current value...