Bug #4481

"File missing" error for all recordings of only one channel

Added by Joel Maxuel 13 days ago. Updated 12 days ago.

Status:InvalidStart date:2017-07-12
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:-
Target version:-
Found in version:4.2.2-59~g66b7e9e Affected Versions:

Description

I have recently switched antennas from rabbit ears in the living room to a Digiwave ANT2088 antenna in the attic. The change has resulted in a more reliable picture subjectively and objectively (Better Signal and SNR), but I have run into a problem (or more recurring) in the process.

One of my three channels, can be exclusively found in the Removed Recordings section (no other channel in that section for two months; since the antenna switch all programs of that channel are going there), with the status "file missing". As I write this, my HDRomeRun is streaming to my HTS server, but nothing is being recorded in spite of a scheduled recording (and I have no clients viewing the show). My only other change besides the antenna is that I did a Mux rescan, and remapped services (in the process my channel of interest created a new service and marked the old one obsolete).

There was nothing of interest in dmesg but I do have a syslog of use:

Jul 11 17:58:30 cybaryme tvheadend[1936]: dvr: "CTV News Atlantic" on "5.1 CJCHDT" recorder starting
Jul 11 17:58:30 cybaryme tvheadend[1936]: mpegts: 677.028MHz in ATSC-T Network - tuning on HDHomeRun ATSC-T Tuner #0 (192.168.1.113)
Jul 11 17:58:30 cybaryme tvheadend[1936]: tvhdhomerun: tuning to auto:677028615
Jul 11 17:58:30 cybaryme tvheadend[1936]: subscription: 000B: "DVR: CTV News Atlantic" subscribing on channel "5.1 CJCHDT", weight: 300, adapter: "HDHomeRun ATSC-T Tuner #0 (192.168.1.113)", network: "ATSC-T Network", mux: "677.028MHz", service: "CJCH", profile="webtv-h264-aac-matroska" 
Jul 11 17:58:30 cybaryme tvheadend[1936]: TS: ATSC-T Network/677.028MHz/CJCH Transport error indicator (total 1)
Jul 11 17:58:30 cybaryme tvheadend[1936]: TS: ATSC-T Network/677.028MHz/CJCH: AC3 @ #52: Invalid start code 10:21:f2
Jul 11 17:58:30 cybaryme tvheadend[1936]: TS: ATSC-T Network/677.028MHz/CJCH: MPEG2VIDEO @ #49: Invalid start code 40:85:04
Jul 11 17:58:30 cybaryme tvheadend[1936]: TS: ATSC-T Network/677.028MHz/CJCH: AC3 @ #51: Invalid start code 96:e0a:25
Jul 11 17:58:30 cybaryme tvheadend[1936]: transcode: 0009: 1:MPEG2VIDEO 1940x68 ==> H264 1940x68 (libx264)
Jul 11 17:58:30 cybaryme tvheadend[1936]: transcode: 0009: 2:AC3 ==> AAC (aac)
Jul 11 17:58:31 cybaryme tvheadend[1936]: TS: ATSC-T Network/677.028MHz/CJCH: MPEG2VIDEO @ #49 Continuity counter error (total 1)
Jul 11 17:58:31 cybaryme tvheadend[1936]: TS: ATSC-T Network/677.028MHz/CJCH: AC3 @ #51 Continuity counter error (total 1)
Jul 11 17:58:31 cybaryme tvheadend[1936]: TS: ATSC-T Network/677.028MHz/CJCH: AC3 @ #52 Continuity counter error (total 1)
Jul 11 17:58:48 cybaryme tvheadend[1936]: TS: ATSC-T Network/677.028MHz/CJCH Transport error indicator (total 2552)
Jul 11 17:58:48 cybaryme tvheadend[1936]: TS: ATSC-T Network/677.028MHz/CJCH: AC3 @ #51: Invalid start code a3:86:6d
Jul 11 17:58:48 cybaryme tvheadend[1936]: TS: ATSC-T Network/677.028MHz/CJCH: MPEG2VIDEO @ #49 Continuity counter error (total 1163)
Jul 11 17:58:48 cybaryme tvheadend[1936]: TS: ATSC-T Network/677.028MHz/CJCH: MPEG2VIDEO @ #49: Invalid start code 63:03:03
Jul 11 17:58:48 cybaryme tvheadend[1936]: TS: ATSC-T Network/677.028MHz/CJCH: AC3 @ #51 Continuity counter error (total 26)
Jul 11 17:58:48 cybaryme tvheadend[1936]: TS: ATSC-T Network/677.028MHz/CJCH: AC3 @ #52 Continuity counter error (total 51)
Jul 11 17:58:50 cybaryme tvheadend[1936]: TS: ATSC-T Network/677.028MHz/CJCH: AC3 @ #52: Invalid start code b6:23:32
Jul 11 17:59:24 cybaryme tvheadend[1936]: TS: ATSC-T Network/677.028MHz/CJCH: MPEG2VIDEO @ #49 Continuity counter error (total 2935)
Jul 11 17:59:24 cybaryme tvheadend[1936]: TS: ATSC-T Network/677.028MHz/CJCH Transport error indicator (total 4768)
Jul 11 17:59:24 cybaryme tvheadend[1936]: TS: ATSC-T Network/677.028MHz/CJCH: MPEG2VIDEO @ #49: Invalid start code c4:79:2c
Jul 11 18:00:01 cybaryme tvheadend[1936]: TS: ATSC-T Network/677.028MHz/CJCH: MPEG2VIDEO @ #49 Continuity counter error (total 2944)
Jul 11 18:00:01 cybaryme tvheadend[1936]: TS: ATSC-T Network/677.028MHz/CJCH Transport error indicator (total 4798)
Jul 11 18:00:01 cybaryme tvheadend[1936]: TS: ATSC-T Network/677.028MHz/CJCH: MPEG2VIDEO @ #49: Invalid start code 4e:ee:6c
Jul 11 18:00:01 cybaryme tvheadend[1936]: TS: ATSC-T Network/677.028MHz/CJCH: AC3 @ #51 Continuity counter error (total 71)
Jul 11 18:00:01 cybaryme tvheadend[1936]: TS: ATSC-T Network/677.028MHz/CJCH: AC3 @ #52 Continuity counter error (total 106)
Jul 11 18:00:04 cybaryme tvheadend[1936]: TS: ATSC-T Network/677.028MHz/CJCH: AC3 @ #52: Invalid start code af:82:5c
Jul 11 18:00:05 cybaryme tvheadend[1936]: TS: ATSC-T Network/677.028MHz/CJCH: AC3 @ #51: Invalid start code 49:f9:2b

I should mention that this particular program has been a pain for me in the past as I had tried a different recording profile (wanted only a five day retention policy) and time frame limitation (only record the 18:00 news - another of the same name and channel is on at 23:00) - had I set either, it would not record back then either. But for minimal changes to the recording settings, it has been working fine until recently. But now, even other shows of the same channel are being dropped.

Would there be something critical I am missing?

Also, I just took a few extra minutes to note a couple more observations. Even though playback of that channel is fine through an actual TV, my client (Kodi) stalls when trying to access that same channel. Syslog looks much like above.

Many thanks.

History

#1 Updated by g siviero 12 days ago

Is the resolution correct? 1940x68 ?

Jul 11 17:58:30 cybaryme tvheadend[1936]: transcode: 0009: 1:MPEG2VIDEO 1940x68 ==> H264 1940x68 (libx264)

#2 Updated by Mark Clarkstone 12 days ago

g siviero wrote:

Is the resolution correct? 1940x68 ?

[...]

Yes, this does seem a bit odd, but having that many CC errors isn't helping.

Joel, can you view the channel fine without issues over http [or htsp]?

#3 Updated by Mono Polimorph 12 days ago

Hi,

Using sources with a lot of errors (=insufficient signal) is normal to have problems.
My recomendation is this: if you have a very low signal in some muxes, then mark it as not useable (ban them).
It's extreamly complex to make a robust processing of a TS with a lot of errors. So, the most simple solution is forget these channels.

#4 Updated by Joel Maxuel 12 days ago

Mark Clarkstone wrote:

g siviero wrote:

Is the resolution correct? 1940x68 ?

[...]

Yes, this does seem a bit odd, but having that many CC errors isn't helping.

Joel, can you view the channel fine without issues over http [or htsp]?

I thought about that a couple hours after sending the bug report. My HDHomeRun has a uPNP mode. I tapped into that, and same channel, there was a lot of noise, making it unwatchable. Quantitatively, through the HDHR app, that put signal strength around 70 and SNR quality around 67. In comparison, the other channels are getting 83 Sig/72 SNR and 93 Sig/68 SNR.

I tried a couple different splitters to the HDHR, my best scenario was 74 Sig/58 SNR, and as the device "settles down" from me touching the connections, it may get a little better.

I think my options at this point is to either move the antenna from the attic to the roof (or at least reposition - which will mean reworking my "mount" solution), or as already said, to forget about that particular channel.

Feel free to close as it is not an issue specific to TvHeadEnd. Thank you.

#5 Updated by Joel Maxuel 12 days ago

Update... I took the opportunity to reposition the antenna. I originally had the antenna hanging from a rafter, now I have a pole mounted, and closer to a vent, with the face of the antenna pointing right at it. I am getting 80's and 90's for signal now, with a respectable SNR (not in the yellow), for all three channels. More importantly, TvHeadEnd is playing all channels now - I imagine there won't be any recording issues at this point.

Mystery solved! Thanks again.

#6 Updated by Mark Clarkstone 12 days ago

  • Status changed from New to Invalid

Closing :)

Also available in: Atom PDF