Bug report: NextPVR "Not Responding" when menus in Settings are selected.

[techtony]

WinTV works now: I moved the tuner card from a x16 to a x1 PCIe slot and also updated the motherboard UEFI. I'm not sure which change caused WinTV to recognize the tuner, but it works fine now.

I downloaded and installed K-lite, and it found a problem and fixed it, but NPVR still hangs on the Decoders dialog (and the DVD dialog).

[sub]

If you go to the Settings->Advanced Settings screen in WinTV, and tick the 'enable 3rd party decoders', does it successfully load the decoder drop downs? If so, zip and attach the c:\users\public\wintv\logs\wintv.log and I'll compare.

[techtony]

There is no error or exception. It's simply taking windows a very very long time to return on the call to get the list of decoders. If I had to work around this unusual circumstance in NextPVR, I could put the call on a background thread, and time it out after a few seconds or something - but you're still not going have anything in your list of decoders, so it wouldn't really help you.

You're not entirely alone though - I think we've seen this maybe 3 or 4 times in the 15 years of NextPVR (and the earlier GBPVR software), from 10's of thousands of users, so certainly not a common problem. I don't see it as a NextPVR problem, but rather a bug in one of the DirectShow decoders in your machine. I'm not aware of any other way I could get the list of decoders that would avoid this problem.

Starting a timer or using a thread were things I was going to "suggest", but I don't know enough about the actual problem. It seems generally on-track though. Personally, I'd fix all problems like that, not just "common" ones. "Defensive programming", you know. You seem sure that it's a bug in a decoder on my machine. NPVR has to be implemented as a fragile program not robust against decoder bugs? How many lines of code execute between clicking on "Decoders" and displaying the dialog? A list of decoders isn't available in the Windows Registry? Again, I don't know the area, but intuitively, it seems this *exceptional condition* ("exception") should not hang the program, and that a bit of redesign and reimplementation may be prudent.

[techtony]

If you go to the Settings->Advanced Settings screen in WinTV, and tick the 'enable 3rd party decoders', does it successfully load the decoder drop downs? If so, zip and attach the c:\users\public\wintv\logs\wintv.log and I'll compare.

No it doesn't! Guess what it does? It does the same thing NPVR does! Oh well, I guess it's a design problem at a larger scope than just NPVR.

[sub]

Starting a timer or using a thread were things I was going to "suggest", but I don't know enough about the actual problem. It seems generally on-track though. Personally, I'd fix all problems like that, not just "common" ones. "Defensive programming", you know. You seem sure that it's a bug in a decoder on my machine. NPVR has to be implemented as a fragile program not robust against decoder bugs? How many lines of code execute between clicking on "Decoders" and displaying the dialog? A list of decoders isn't available in the Windows Registry? Again, I don't know the area, but intuitively, it seems this *exceptional condition* ("exception") should not hang the program, and that a bit of redesign and reimplementation may be prudent.

It's a bit of a tough one to do anything about - I think it's a single Windows API call that just never returns. That shouldn't happen, and works as expected for the vast majority of users. I'm not aware of any alternative call I can make to get this information, so that I can avoid making this call.

It's so rare though, that I'm not sure it's worth investing a huge amount of time one - particularly given I have no way to reproduce it here so can't test fixes.

[sub]

If you're able to offer remote access to your machine, for an hour or so, I'm happy to take a closer look at the problem, and see if there is any potential fixes.

[techtony]

If you're able to offer remote access to your machine, for an hour or so, I'm happy to take a closer look at the problem, and see if there is any potential fixes.

I can't give you access to my machine, but I can send the detailed logs of WinTV that I have if that would help the analysis. Some of the logs show a repetitive pattern of calls upon quick look at them. The .zip is a bit less than 7 MB, so it exceeds the ~3 MB attachment limit of this forum.

[techtony]

It's a bit of a tough one to do anything about - I think it's a single Windows API call that just never returns. That shouldn't happen, and works as expected for the vast majority of users. I'm not aware of any alternative call I can make to get this information, so that I can avoid making this call.

It's so rare though, that I'm not sure it's worth investing a huge amount of time one - particularly given I have no way to reproduce it here so can't test fixes.

I found "Shark007" codec software on the web, and with that I may be able to disable the codecs and enable them one at a time and narrow down the problem, but I don't have too much time to spend on this either, especially since WinTV is working now and I don't need the 3rd party decoder (unsupported) feature.

[sub]

I can't give you access to my machine, but I can send the detailed logs of WinTV that I have if that would help the analysis. Some of the logs show a repetitive pattern of calls upon quick look at them. The .zip is a bit less than 7 MB, so it exceeds the ~3 MB attachment limit of this forum.

Nah, the logs won't show the cause. There was more detailed steps needed to investigate.

Nevermind.

[techtony]

Nah, the logs won't show the cause. There was more detailed steps needed to investigate.

Nevermind.

So the debug logs that fill micro-second detail of a product that behaves exactly like yours does, wouldn't provide any insight? What I am wondering, if there was something like reverse-engineering of a design pattern and that is why two products (at least two) behave exactly the same. So, I, would attack the problem from a more abstract view rather than from a detailed (implementation/code) perspective.

I was probably wrong to offer the logs, so I retract that offer. I wonder a little bit about the details of 3rd-party codecs and software that uses them, and things like how WinTV software has always been a PITA. It just seems like after decades, this should not be a problem.

That said, I'm going to bring up my PC from scratch soon and will put WinTV and NPVR at the top of the software install list (but that this kind of software requires such finesse, is a statement in itself), to eliminate as much potential interacting conflict as possible.