Windows client hanging when playing recording

[TGinAZ]

I'm running version 5.2.0.210912 on a Windows 10 PC, and I'm having problems watching some (not all) recordings.  The NextPVR client appears to hang in a loop and is totally unresponsive... the only way to continue is killing the app.

I tried opening the TS file with Windows Media Player, and while it doesn't hang, it plays for a couple of minutes and then jumps to near the end of the 30+ minute video.  Obviously suggesting something is wrong with the recording.

This recording, and the others that cause the problem, was created with NextPVR from a SiliconDust HDHomeRun tuner.

Can anyone help fix my problem (the NextPVR recording or playback problem, not all my other issues!)  ;-)

Would it help to have a copy of the logs and/or TS file?
https://drive.google.com/drive/folders/1AoRgv8U0mDn2mTv9Ir4593fQOBL588W5

Thanks in advance!

[mvallevand]

This seems to be a duplicate post and I even recall sub asking what the tuner source was but I can't find the original

Anyway the video in file I looked at was very corrupt, and it started off ok the expression "Garbage In Garbage Out" comes to mind and you need to get a better antenna to fix the signal. Sometimes sub channel OTA stations run with low power too. Recording quality has nothing to do with NextPVR it just captures the signal as it receives it.

Perhaps if you tried the LAV video decoder it might not hang? Sub might be able to improve NextPVR and not hang, but it won't make the recording watchable.

Looking at the logs the only other explanation would be something is disrupting the UDP broadcast but that seems unlikely. It is not a disk write error since the stream itself is fine.

Martin

[sub]

This seems to be a duplicate post and I even recall sub asking what the tuner source was but I can't find the original

I accidentally deleted his post, so asked him to repost - I even supplied the text from the original post.

[sub]

The bulk of the file is missing. The recording is 00:32:58 long,but only 85MB and big chunks of it a are missing. The first couple of minutes are ok, then it breaks up and resumes late in the recording. It is most likely a reception issue, but possibly something wrong with your network. NextPVR would have recorded everything it received from the device.

[TGinAZ]

While I can understand acquiring a lousy signal, and yes, that is definitely a possibility, I don't understand how the recording could be corrupt (not smart enough to understand the details). I would have expected the recording to show all sorts of screen blanking, etc. But in this case, the file is bad and crashes the program?

The NextPVR client HANGS! The only way to recover is to have Windows terminate the app... nothing works in the client. If you were to try to play that recording, does your client hang? Opening the TS file with VLC doesn't cause the program to crash.... but it obviously is a lousy file.

Thanks! I'm still trying to figure things out (and not have my wife mad at me as I cut the cord!).

[mvallevand]

I played it in a NextPVR app for Android and the file did not crash. Did you try it with 32 bit LAV as I suggested?

Martin

[sub]

While I can understand acquiring a lousy signal, and yes, that is definitely a possibility, I don't understand how the recording could be corrupt (not smart enough to understand the details).  I would have expected the recording to show all sorts of screen blanking, etc. 

It might not be clear to how things work behind the scenes. What you describe is more like how analog tv behaved. ie, we'd actually record black frames etc when there are gaps.

With digital, the broadcaster is encoding the audio and video, and we're just writing the data to disk as it arrives. We're not re-encoding the video, so there is no opportunity for us to insert black frames to fill in the gaps etc.

What happens when you're playing it, is that it reads the next frame of video and displays it at the timestamp it says to use. In your case, you're managing to display a few minutes of frames, then eventually the next frame it gets is for display 28 minutes later, so it's sitting there (with previous frame still showing) waiting for that time to show that next frame. In theory it should stay responsive during that period, but with frame frozen on the screen, waiting for the time to display the next frame, but I think that gap is just too damn big, and causes some buffer issues.

I'm intending to use your sample file as test to see if I can improve the situation, which is about all I can really do.

But in this case, the file is bad and crashes the program?

The NextPVR client HANGS!  The only way to recover is to have Windows terminate the app... nothing works in the client.  If you were to try to play that recording, does your client hang?  Opening the TS file with VLC doesn't cause the program to crash.... but it obviously is a lousy file.

True - ideally it shouldn't hang, and it certainly does try to cope with some of these types of scenarios. Exact behaviour can come down to choice of decoders etc though. Ultimately, if you only receive like 3 minutes of marginal signal over half an hour, you're never going to be happy with the results you're going to get from that channel. NextPVR can't work miracles. Your only real options are either deleting the weak channel, or getting a better antenna.

Also, remember this is a hobby project, written by one guy in his spare time. Yeah, it's not perfect. Pretty good, but not perfect.

[TGinAZ]

I played it in a NextPVR app for Android and the file did not crash.  Did you try it with 32 bit LAV as I suggested?

Martin

Thanks for the suggestion Martin, but I have no idea how to find that setting... please help!


(Here's another issue... I'm not getting emails notifying of new replies in spite of selecting that option when I post.)

[mvallevand]

I believe the link is in the NextPVR settings but it is here https://github.com/Nevcairiel/LAVFilters/releases You want the 32 bit version even with 64 bit Windows.

Martin

[TGinAZ]

I won't quote your reply.... after all, it's not that far back!

First, I want to say you show remarkable restraint and politeness in your replies!  Such a contrast from so many developers and on so many forums.  THANK YOU!  Also, your helpful explanations provide insight that I really appreciate.  Again, THANK YOU!

Digital broadcasts... if I understand correctly, while NextPVR might be communicating with my SiliconDust tuner, the data may be corrupt (potentially because of lousy reception). Since using something like HDHomeRun would display garbage on the screen, I just assumed the file on my disk would provide that same level of garbage without messing with your code. Does the timestamp come from the tuner, or is it applied by NextPVR as it writes data to the disk?  It just makes me assume the "envelope" should always be good, but the frame content might be bad.

And if the decoder isn't your code, I can understand that a garbage frame could be the source of a decoder "hang". I didn't see a link in settings for LAV, but I'll check out your link and look again.

Just as an aside... while my antenna is really cheap, it is picking up from repeaters on two mountains, and while most stations come in quite well, there are a few that are problematic.  A neighbor has a very expensive antenna and experiences similar issues with those problem stations.

I totally understand that marginal signals are not something NextPVR can do anything about!  As someone who did code in assembly languages for mini-computers in the 70s, I'm often amazed that programs work as well as they do.  Geeze, in those days we used paper tape and punched cards, and miniscule capacity disks were the size of washing machines.

And yes, I am aware the project is a hobby, and I applaud the efforts. "Pretty good, but not perfect"?  Nah, perhaps not perfect, but I would say EXCELLENT!