Weird issue with some recordings

[enforcersu]

So I can't quite isolate what is causing this issue with (some) recordings.

About 2-3 recordings / day seem to have this issue when I load in other players (Kodi, Plex, emby), that I cannot fast forward. It is almost like the player is playing the recording live, and that any fast forwarding requires a load of buffering (1+ min). All other recordings is immediate.

If I play the recording in nPVR itself, it plays just fine.

I am not quite sure what could cause this, whether or not it is an issue with:
1) my HDHR tuner?
2) How nPVR is recording this? (It seems to be happening mostly on FS1 or ESPN recordings).
3) other?

What would be most useful to diagnose this? Would logs of the time from recording help?

[mvallevand]

Plex and Emby are transcoding so you shouldn't be expected to fast forward easily. 1080i sports are typical hard to transcode efficiently. Kodi logs might be useful

Martin

[enforcersu]

Sorry to be so long between replies on this, got sidetracked over the holidays.

This is happening more frequently for me now. I've noticed that if I open the recordings affected in VLC, it doesn't compute the end time of the recording. For example, if I open a recording that is 60 mins long, then VLC recognizes that the end time is at 60 mins. If I open one of these recordings that doesn't play well outside of nPVR, then no end time for the recording is computed.

Here's a snippet from NRecord logs for one of the recordings that's not working well
2017-01-05 14:29:00.080 [DEBUG][9] Recording explicitly recording to directory: '[sports shows]'
2017-01-05 14:29:00.080 [DEBUG][9] allocating recording target filename: D:\Sports Shows\Pardon the Interruption\Pardon the Interruption_20170105_14301500.ts
2017-01-05 14:29:00.080 [DEBUG][9] About to start recording (62107 on 37): D:\Sports Shows\Pardon the Interruption\Pardon the Interruption_20170105_14301500.ts...
2017-01-05 14:29:00.080 [DEBUG][9] Free space 2618483843072 (D:\)
2017-01-05 14:29:00.080 [DEBUG][9] HDHomeRunRecorder.StartStream()
2017-01-05 14:29:00.080 [DEBUG][9] Multi-Record. Not retuning HDHomeRun. Already on the correct channel.
2017-01-05 14:29:00.081 [DEBUG][9] StartStream() returned handle=91
2017-01-05 14:29:00.081 [DEBUG][9] Allocated Handle: 91
2017-01-05 14:29:00.081 [DEBUG][9] Temp at 1/5/2017 2:29:10 PM
2017-01-05 14:29:00.081 [DEBUG][9] Started recording (62107:91:\Sports Shows\Pardon the Interruption\Pardon the Interruption_20170105_14301500.ts)
2017-01-05 14:29:00.091 [DEBUG][9] No C:\Users\Public\NPVR\Scripts\ParallelProcessing.bat
2017-01-05 14:29:00.092 [DEBUG][20] catalog says:
<Catalog><Version>1</Version><Poster>C:\Users\Public\NPVR\media\shows\Pardon the Interruption.jpg</Poster><Landscape>C:\Users\Public\NPVR\media\shows\Pardon the Interruption.landscape.jpg</Landscape><Logo>C:\Users\Public\NPVR\media\shows\Pardon the Interruption.logo.jpg</Logo><FanArt>C:\Users\Public\NPVR\media\shows\Pardon the Interruption.fanart.jpg</FanArt><Banner>C:\Users\Public\NPVR\media\shows\Pardon the Interruption.banner.jpg</Banner></Catalog>
2017-01-05 14:29:00.096 [DEBUG][9] - deleting extra recording: D:\Sports Shows\Pardon the Interruption\Pardon the Interruption_20170104_14301500.ts (1/4/2017 10:29:00 PM)
2017-01-05 14:29:00.166 [DEBUG][9] -removing: D:\Sports Shows\Pardon the Interruption\Pardon the Interruption_20170104_14301500.xml
2017-01-05 14:29:00.166 [DEBUG][9] PlaybackPositionHelper.DeletePlaybackPosition(D:\Sports Shows\Pardon the Interruption\Pardon the Interruption_20170104_14301500.ts)

Not sure what logs might be helpful...

[spaceghost2000]

I am also frequently experiencing this problem with recordings. Like you, I see no end time if I try to play w/VLC. I'm on v3.9.2 with HDHR-3 Prime firmware 20161117. I get 2 or 3 recordings a week that won't process via MCEBuddy due to this issue. I can use Handbrake to process the file manually but not thru any scripting like MCEBuddy. Seems to happen when there are back to back recordings on the same tuner and the PVR is not terminating recordings correctly.
Both NCIS and The Wall exhibit this issue every week. They record, file size is right for an hour show, but both show 00:00:00 as end time in VLC and fail any processing w/MCEBuddy. I am not sure if this is a NextPVR issue or HDHomerun issue, but I don't remember seeing this issue before I upgraded to 3.9.2 (or as frequently). I had my post padding set to 3 min, pre set to 1. I just changed post to 1 to see if it will help next week's recordings.

[ATTACHMENT NOT FOUND]

[scJohn]

Double check that the 'BDA Compatibility Mode' for your HDHomeRun, located at HDHomeRunSetUp | Configuration | General, is set to 'Default' or 'MedialPortal'. This is especially import when pre/post padding are set to anything other than 0. All though even when pre/post padding is set to 0, you should still use 'Default' or 'MediaPortal'.

[spaceghost2000]

it is (default), thank you for the suggestion!

[spaceghost2000]

something odd, I had another recording last night missing the Duration. Mediainfo shows:
General
ID : 0 (0x0)
Complete name : W:\PVRDISC\Arrow\Arrow.S05E11.Second Chances.ts
Format : MPEG-TS
File size : 5.23 GiB

where a properly recorded show lists Duration:
General
ID : 0 (0x0)
Complete name : W:\PVRDISC\The Young and the Restless\The Young and the Restless.S44E107.ts
Format : MPEG-TS
File size : 4.73 GiB
Duration : 1 h 1 min
Overall bit rate mode : Variable
Overall bit rate : 10.9 Mb/s

If I run the arrow thru tsmuxer it somehow fixes the metadata and vlc\mediainfo shows proper duration:
General
ID : 1 (0x1)
Complete name : E:\temp\arrow.ts
Format : MPEG-TS
File size : 5.16 GiB
Duration : 1 h 0 min
Overall bit rate mode : Variable
Overall bit rate : 12.1 Mb/s
Maximum Overall bit rate : 35.5 Mb/s

So is this an issue with saving the metadata in the recording?

[spaceghost2000]

ffmpeg also shows missing duration:
bad file--
Input #0, mpegts, from 'W:\PVRDISC\Arrow\Arrow.S05E11.Second.Chances.bakup-bad.ts':
Duration: N/A, start: 28243.094433, bitrate: N/A
Program 1
Stream #0:0[0x66a]: Video: mpeg2video (Main) ([2][0][0][0] / 0x0002), yuv420p(tv, bt709), 1920x1080 [SAR 1:1 DAR 16:9], Closed Captions, max. 20000 kb/s, 29.97 fps, 29.97 tbr, 90k tbn, 59.94 tbc
Stream #0:1[0x66b](eng): Audio: ac3 (AC-3 / 0x332D4341), 48000 Hz, 5.1(side), fltp, 384 kb/s
Stream #0:2[0x66c](spa): Audio: ac3 (AC-3 / 0x332D4341), 48000 Hz, mono, fltp, 192 kb/s


good file---
Input #0, mpegts, from 'W:\PVRDISC\Arrow\Arrow.S05E11.Second Chances.ts':
Duration: 01:00:58.04, start: 600.013000, bitrate: 12120 kb/s
Program 1
Stream #0:0[0x1011]: Video: mpeg2video (Main) ([2][0][0][0] / 0x0002), yuv420p(tv, bt709), 1920x1080 [SAR 1:1 DAR 16:9], Closed Captions, max. 20000 kb/s, 29.97 fps, 29.97 tbr, 90k tbn, 59.94 tbc
Stream #0:1[0x1100](eng): Audio: ac3 (AC-3 / 0x332D4341), 48000 Hz, 5.1(side), fltp, 384 kb/s
Stream #0:2[0x1101](spa): Audio: ac3 (AC-3 / 0x332D4341), 48000 Hz, mono, fltp, 192 kb/s

[scJohn]

If you had a SC Connect or Extend I would suggest a fine tuning of your antenna. But you have a Prime which means you are on a cable system and on cable you should be getting a 'perfect' stream. But you are not. IMHO this leaves you with 3 possibilities: 1) weak cable signal into your house, 2)the TV station is having signal problems or 3) your PRIME is about to fail.

Are your problem recording(s) from just one channel? If not, that would seem to rule out #2. For #3, how old is your Prime? Normally, the transformer will start to fail (before the device), giving you interment errors.

[spaceghost2000]

We had a lot of issues getting the cable card working so the contracted techs did a lot of measuring and said signal was a tad low and put in a ticket to have the real cable techs come out, which they did and had to fix something upstream from me. That was about 9 months months ago, which is how old my prime is. I haven't noticed a particular set of channels having problems but when I usually have back to back recording they're usually on the local channels. I don't get decent enough antenna reception due to the huge hill and houses in the direction of most of the broadcasting stations. I would need about a 100ft antenna to get high enough to get decent signal.

So I'm wondering what the tv channel feed would have to do with the duration not being tagged on a local .TS file (your item #2)? I could record 37 minutes of a 30 or 60 minute program and the file duration should list 37 minutes. Guess I assumed NextPVR was capturing the stream to a file and in control when it starts/ends and the duration tagged in the media. The "bad" files play ok, no audio/video glitches or dropouts but skipping or FFW takes forever since there's no duration. Once I run it thru tsmuxer (not changing anything) it calculates the duration and tags the file and play/FFW works just fine.

BTW, thank you for your help!