Lost Live TV

[SilverTiger]

Yeah I’d like to take a look. I’d like to see approximately what is happening.

https://1drv.ms/v/s!AmFK7SDJM9Omj1eHhyHa...V?e=O9kVLp

The above link is to quick video showing what happens.

[sub]

I'd also like to see a set of logs.

Here is a set of logs.  Did test at about 16:11 local time on 23 Dec.

I suspect your problem is something different. The pixilation fix in this new build was related to a permissions issue that could happen with HDHR, IPTV and Extras devices. It did not affect HDPVR style devices.

I may need to get you to collect some lower level logs to give us more insight into what's happening.

Create a c:\temp directory, and set HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\NPVR\ LogDemuxFileOps=1 (DWORD) in the registry, then start watching the device for a few seconds until you get this pixilation, then zip and attach the logs, along with the extra c:\temp\file.txt

After the test, delete that registry setting (since it'll hurt performance)

[mvallevand]

I still think the 10 seconds that it took for startup is a potential issue. That is why I why I asked what delay SilverTiger might be adding in his tuning script.

Martin

[SilverTiger]

I still think the 10 seconds that it took for startup is a potential issue.  That is why I why I asked what delay SilverTiger might be adding in his tuning script.

Martin

Martin

The only delay I have intentionally set is <WaitLongerDelay>7500</WaitLongerDelay>.  My understanding from Sub is that this only affects recording so I would not expect it to be an issue for live TV.  However, my splitters (required due to HDCP) are not real quick coming to life sometimes.  That may be what you are seeing.  The above delay is for the splitters.

Walt

[SilverTiger]

I'd also like to see a set of logs.

Here is a set of logs.  Did test at about 16:11 local time on 23 Dec.

I suspect your problem is something different. The pixilation fix in this new build was related to a permissions issue that could happen with HDHR, IPTV and Extras devices. It did not affect HDPVR style devices.

I may need to get you to collect some lower level logs to give us more insight into what's happening.

Create a c:\temp directory, and set HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\NPVR\ LogDemuxFileOps=1 (DWORD) in the registry, then start watching the device for a few seconds until you get this pixilation, then zip and attach the logs, along with the extra c:\temp\file.txt

After the test, delete that registry setting (since it'll hurt performance)

[sub]

Ok - I can see what is happening. It's the same type of thing as I fixed for the other tuner types. I wouldn't have thought it would have occurred for this type, but it looks like it'll need somewhat similar changes:

20:32:34.167 OpenFile(F:\NPVRV5 Buffer\live-WPVIDT-11581.ts)
20:32:34.167 Not live stream. OpenMutex failed (00000005) (Global\NPVR-mutex-ea92244153fd07c02d31b7e475700875)

[SilverTiger]

Just as info, I noticed that I could not zip all the log files (this may not matter) unless I stopped a process called NRecord (I think). I DID stop the service and the tray app, but the NRecord was still out there. Not a big deal, but thought I would mention.

[sub]

Usually a user would just use the button in the app to download the logs - it’ll flush the logs to disk, and zip them, and send them to the users browser to save a copy.

[mulletback]

Sub, the 5.0.1.191224 build fixed the live tv pixilation problem on my test box. I'm continuing to monitor this thread because my production box (see sig) also has a Colossus.

[sub]

Yep sounds like it’s still an issue on HDPVR/Colossus style devices. I’m gonna check this out tomorrow.