Can you apply the most recent patchs from johnsonx42's thread, then repost the logs next time it happens? These patches add separate logs for each capture source, which makes it easier to track problems.
Looking at those logs, it looks like the recording has successfully run frome 8:59-9:33. It definitely hasn't stopped it between those two points. I'm assuming the device has just stop delivering data. Could some other software have used the HDHR during this time? or maybe have lost the signal?
I'm not really sure what to suggest as a next step for finding the cause of this. If you happened to come across this while it's happening, you could try running the HDHomeRun Config app to check the signal strength and network rate etc.
I haven't read all of the thread so apologies if I am missng the point.
I have dodgy reception. I used GBPVR until recently and recorded in dvr-ms format. There would be glitches during playback caused by glitches in the original transmission. Some glitches would show during playback as a moment of pixellation and others would show as 10 seconds or more of frozen video. But playback would return to normal after the point in the recording file where the transmission glitch occurred.
NPVR used to cope badly with these glitches but is much better now. I still get mad jumps during playback (but very rarely). I might get a sudden jump forward of 30 minutes. I can use the remote to skip back 29 and a half minutes and playback continues as normal.
sub Wrote:Looking at those logs, it looks like the recording has successfully run frome 8:59-9:33. It definitely hasn't stopped it between those two points. I'm assuming the device has just stop delivering data. Could some other software have used the HDHR during this time? or maybe have lost the signal?
I'm not really sure what to suggest as a next step for finding the cause of this. If you happened to come across this while it's happening, you could try running the HDHomeRun Config app to check the signal strength and network rate etc.
No other programs should be trying to use the HDHR. Don't think the signal could be lost considering this doesn't happen when I use GBPVR. I will look at the config utility the next time this happens and see if anything looks wrong. The only difference I can think of is I have a new Hauppauge 2650 setup for NPVR that isn't on the GBPVR setup. Is there any possibility that is conflicting with the original HDHR? I know the 2650 is pretty much a HDHR prime without the network ability and uses the same HDHR software.
Graham Wrote:I haven't read all of the thread so apologies if I am missng the point.
I have dodgy reception. I used GBPVR until recently and recorded in dvr-ms format. There would be glitches during playback caused by glitches in the original transmission. Some glitches would show during playback as a moment of pixellation and others would show as 10 seconds or more of frozen video. But playback would return to normal after the point in the recording file where the transmission glitch occurred.
NPVR used to cope badly with these glitches but is much better now. I still get mad jumps during playback (but very rarely). I might get a sudden jump forward of 30 minutes. I can use the remote to skip back 29 and a half minutes and playback continues as normal.
Graham.
The skip forward is not really a skip. A file that should be the size of about 2.5 GB is only around 200-400 MB. It essentially recorded only the pre and post padding. The first 2 minutes is in the file and the last 2 minutes is in the file. So it really didn't skip past the middle, the middle just isn't there.
persim Wrote:The only difference I can think of is I have a new Hauppauge 2650 setup for NPVR that isn't on the GBPVR setup. Is there any possibility that is conflicting with the original HDHR? I know the 2650 is pretty much a HDHR prime without the network ability and uses the same HDHR software.
I dont think any conflict of this type is happening in the app - there is no sign of it, and they even happen in different processes. It could potentially be some driver issue though, if they're sharing functionality between these two HDHR devices. I really dont know.
Odd you only seem to be having this problem on one channel.
My recollection from the Fox sample was that during the Simpsons, the recording only at PMT/PAT blocks at the earliest part of the file (during the pre-padding) and afterwords only the raw audio and video streams were available, which is why skipping was impossible. Subsequent broadcast were zero bytes because there wasn't anything but the elemental streams. DVR-MS muxing, might have been able to deal with these,
mvallevand Wrote:My recollection from the Fox sample was that during the Simpsons, the recording only at PMT/PAT blocks at the earliest part of the file (during the pre-padding) and afterwords only the raw audio and video streams were available, which is why skipping was impossible. Subsequent broadcast were zero bytes because there wasn't anything but the elemental streams. DVR-MS muxing, might have been able to deal with these,
Martin
I have just figured all along that this has to be a NPVR problem because it does not happen with GBPVR, I even used the TS Mux with GBPVR, never DVR-MS.
persim Wrote:I have just figured all along that this has to be a NPVR problem because it does not happen with GBPVR, I even used the TS Mux with GBPVR, never DVR-MS.
Does not know or did not when you used it? The properties can change. If GBPVR is still recording good .ts streams on that channel I suspect it is an HDHR problem.