Recording jumbled

[VCR58]

I scheduled a recording of game 3 of the world series at 7:00pm. About 2hrs later started the recording with Kodi to watch the game delayed. However, after about 20 sec the video became jumbled and soon it was just a big mess and no audio. I fast forwarded the video to see if it got better but no luck. There were a few places that were clear for a few seconds then back to jumbled. So, I gave up and watched it live to the end without any problems. Never saw any issues watching it live. My tuners are HDHR configured for OTA and the HDHR signal strength indicator was 100%. When the recording completed I went back to view it again. About the time (1hr 52min) where I started watching the game live, the recording was not having issues anymore. 

There was a previous recording that finished the same time the game started on a different channel and it played fine.j

The logs are attached and a link to a video made with cut chunk.

Link to video
no longer available

Thanks

[BrettB]

You need to include a debug log from the Kodi client.

If I'm reading the logs you supplied correctly, it appears that you were trying to play the recording via the HTTP streaming in NextPVR. I think that method has some issues on the Kodi side with in-progress recordings where the file is growing. And I see multiple "client disconnected" messages, but without the Kodi debug log, we can't see what happened on the Kodi side to cause those.

If you want to be able to play in-progress recordings and/or use comskip/edl files for automatic skipping, I'd suggest setting up your Kodi client to use path substitution to play the files via file share (either SMB or NFS) rather than via the native NextPVR HTTP streaming.

[VCR58]

You need to include a debug log from the Kodi client.

If I'm reading the logs you supplied correctly, it appears that you were trying to play the recording via the HTTP streaming in NextPVR. I think that method has some issues on the Kodi side with in-progress recordings where the file is growing. And I see multiple "client disconnected" messages, but without the Kodi debug log, we can't see what happened on the Kodi side to cause those.

If you want to be able to play in-progress recordings and/or use comskip/edl files for automatic skipping, I'd suggest setting up your Kodi client to use path substitution to play the files via file share (either SMB or NFS) rather than via the native NextPVR HTTP streaming.

Actually, the problem is with the recording. Had no trouble with streaming live TV.

[BrettB]

When the recording completed I went back to view it again. About the time (1hr 52min) where I started watching the game live, the recording was not having issues anymore. 

There was a previous recording that finished the same time the game started on a different channel and it played fine.

Actually, the problem is with the recording. Had no trouble with streaming live TV.

From your first message above, I understood that you had issues playing the recording while it was still being generated. But after it was finished, you tried playing it again (in the same place), and you didn't have any issues--indicating that the recording was fine.

[VCR58]

When the recording completed I went back to view it again. About the time (1hr 52min) where I started watching the game live, the recording was not having issues anymore. 

There was a previous recording that finished the same time the game started on a different channel and it played fine.

Actually, the problem is with the recording. Had no trouble with streaming live TV.

From your first message above, I understood that you had issues playing the recording while it was still being generated. But after it was finished, you tried playing it again (in the same place), and you didn't have any issues--indicating that the recording was fine.

Sorry for the confusion.

The video clip shows the problem with the recording right from the start. The first 2 hrs of the recording are bad. The rest of the recording is good.

[BrettB]

Sorry for the confusion.

The video clip shows the problem with the recording right from the start. The first 2 hrs of the recording are bad. The rest of the recording is good.

OK. You mentioned that you had another recording that had just completed when this one began. Were you by chance running comskip on the completed recording simultaneously with the beginning of this recording.

In both v4 and v5, I have found issues with "bad recordings" from my HDHR devices when the disk couldn't keep up with the volume. SATA 3Gb vs. SATA 6Gb drives, 5400RPM vs. 7200RPM drives, multiple simultaneous recordings, and concurrent comskip operations have all caused this for me--especially on my test system when I ramped it up to 5-6 simultaneous recordings.

[mvallevand]

I'm lost on what the problem we are discussing but certainly sub has to do something about the logging at the microsecond level before which can't help performance

Code:

2019-10-25 23:30:31.048    [DEBUG][32]    Sent 56400 bytes
2019-10-25 23:30:31.048    [DEBUG][32]    Sent 56400 bytes
2019-10-25 23:30:31.048    [DEBUG][32]    Sent 56400 bytes
2019-10-25 23:30:31.049    [DEBUG][24]    Sent 56400 bytes
2019-10-25 23:30:31.054    [DEBUG][24]    Sent 56400 bytes
2019-10-25 23:30:31.059    [DEBUG][24]    Sent 56400 bytes

nrecord already logs too much but I am hoping that is going to change as the beta cycle nears but this is logging is excessive.

Martin

[VCR58]

OK. You mentioned that you had another recording that had just completed when this one began. Were you by chance running comskip on the completed recording simultaneously with the beginning of this recording.

In both v4 and v5, I have found issues with "bad recordings" from my HDHR devices when the disk couldn't keep up with the volume. SATA 3Gb vs. SATA 6Gb drives, 5400RPM vs. 7200RPM drives,  multiple simultaneous recordings, and concurrent comskip operations have all caused this for me--especially on my test system when I ramped it up to 5-6 simultaneous recordings.

No, I wasn't using comskip. Never tried setting it up. Maybe some day...

I may be having tuner issues. I noticed that in the NPVR.log the configuration for the tuner used for the game recording never finishes.

[VCR58]

I'm lost on what the problem we are discussing but certainly sub has to do something about the logging at the microsecond level before which can't help performance

Code:

2019-10-25 23:30:31.048    [DEBUG][32]    Sent 56400 bytes
2019-10-25 23:30:31.048    [DEBUG][32]    Sent 56400 bytes
2019-10-25 23:30:31.048    [DEBUG][32]    Sent 56400 bytes
2019-10-25 23:30:31.049    [DEBUG][24]    Sent 56400 bytes
2019-10-25 23:30:31.054    [DEBUG][24]    Sent 56400 bytes
2019-10-25 23:30:31.059    [DEBUG][24]    Sent 56400 bytes

nrecord already logs too much but I am hoping that is going to change as the beta cycle nears but this is logging is excessive.

Martin

The basic problem is the recording I scheduled is bad. The link to the video clip show what I see most of the time for the first 2 hrs.

[mvallevand]

I saw that in the file but the logging is also a bit crazy. Are you running the tuner in HDHR mode or ATSC mode, I remember sub had to revert HDHR mode back in 4.2.2 because of issues with recordings. Not sure if http is fixed in v5 but it will need good throughput.

Martin