Tvheadend

Do you use transcoding?

No. Nothing fancy -- just straight recording passthru.

Funnily enough, I've just had this too this last week using current 4.2 git on DVB-T and a TBS6205 under Linux. Usually a 25 or 50Kb(ish) file when it occurs and no errors logged either.

Only started using Tvheadend recently and had chosen matroska as default recording stream profile to save space. However was testing with pass(through) to see if it gets ff/rewind useable beyond x4 with Kodi on same system. Switching back to matroska and all is fine again. Was going to investigate further when had free time.

Yes, I've had the same problem but thought it was just my setup, maybe because I have EPG running state accidentally enabled.

I noticed last night that it wasn't logging any errors but one recording wasn't getting any data. Another tuning at the same time on a different usb tuner was ok.

When I looked in finished recordings and sorted by size, I had about ten recordings over the past week that were all <1MB, most <100k. So it obviously thought they had been recorded ok, despite a two hour film only being 500kb.

I'm not sure if it's good or bad that I'm not alone with this problem!

I'm fairly new to the Tvheadend setup too. I was beginning to think I had configured something wrong just because I didn't know any better, but after multiple reinstalls of Tvheadend and the OS, I'm still lost. I swear I've tried just about every combination of settings that seem to be related to tuners and recordings. Nothing actually makes any difference. I would think everyone would be reporting it if it was widespread.

libhdhomerun for master (4.3) has been upgraded. Could you guys test that?

So, just switch to the unstable branch and run with it?

I have the problem without hdhomerun.

I think I've spotted a problem in the logfile, perhaps others could confirm if they have similar things logged on their failed recordings:

dvr:  #  type              lang  resolution  aspect ratio  sample rate  channels
dvr:  5  PCR

dvr:  #  type              lang  resolution  aspect ratio  sample rate  channels
dvr:  1  MPEG2VIDEO              ?           ?
dvr:  2  MPEG2AUDIO        eng                             96000        ?
dvr:  3  MPEG2AUDIO        eng                             96000        ?
dvr:  4  DVBSUB            eng

So I guess it's not detected the streams? I know there is/was a bug with mkv where sometimes it didn't detect audio, which is why I use pass.

Note that in the above case I was recording the preceding show on (I believe) the same tuner and that was detected ok. So, perhaps it is related to back-to-back recordings?

The recording is going at about 100kb/s

state RECORDING rec_state RUNNING error 'OK'

$ femon -a 7
FE: Afatech AF9033 (DVB-T) (DVBT)
status SCVYL | signal ffff | snr 07fe | ber 00000000 | unc 000045ca | FE_HAS_LOCK
status SCVYL | signal ffff | snr ffff | ber 00000000 | unc 000045ca | FE_HAS_LOCK
status SCVYL | signal ffff | snr ffff | ber 00000000 | unc 000045ca | FE_HAS_LOCK
status SCVYL | signal ffff | snr 07fe | ber 00000000 | unc 000045ca | FE_HAS_LOCK
status SCVYL | signal ffff | snr 07fe | ber 00000000 | unc 000045ca | FE_HAS_LOCK

dvbsnoop shows data is flowing.

Definitely not related to back to back programming for me. I could start up 4 recordings sequentially, and all 4 would fail or all four would work, or two out of four would fail, etc. Never found a pattern. I also didn't see any problems with the streams being detected. All of my tests looked similar to your 2nd (successful) log.

I guess I need to do a network monitor to see if the tuners are sending over the data and Tvheadend is just ignoring it. I did not look into that yet.

For my example above, I figured out is caused by my channel being time shared, so at 6pm it stops broadcasting on aerial but it is still broadcasting on satellite.

I'd recently changed my input priorities to favour the aerial so the satellite is available for non-aerial channels. But that means it now gets the part-time channel and doesn't retune to satellite since it's got a channel lock but is presumably just getting a poster saying "see you tomorrow".

I know that's not OP's problem, but thought I'd post so it can be removed from discussion.

I don't think this is the cause of my other failed recordings, but I'll watch out for it.

So, sure enough... I got home and immediately started manual records on 4 channels. Each time, the network traffic jumped by about 2 MiB/s on the Tvheadend server. The file sizes remain at less than 60KB on the UI, and no errors in the debug log. Looks like Tvheadend is just ignoring the stream. Stopping the recordings also stopped the streaming traffic.

I'm currently running the latest stable release. I'm going to try the 4.3 unstable branch. I wonder if backing down to the release version would make a difference?

Latest unstable (4.3-556) doesn't seem to be any better. I don't think the newer hdhomerun drivers made any difference.

Assuming I did it right (the version changed), rolling back to release-4.2 did nothing either.

Can you try setting default recording stream profile to matroska and retesting? Would confirm if we do have same issue and would point to the problem being pass(through) at fault.

Holy cow - That was it! After dozens of tests, I can no longer get it to fail. Do most people not use pass through. Crazy. I was at work when your initial suggestion came through, and forgot to try it. Thank you so much.

Minor update... The fix does not survive a reboot. Symptoms came back until I swapped to matroska and back to pass(through).

Brian: I'm not sure what you did. I meant just leaving it as matroska (until issue is fixed) but it sounds like you switched to matroska and then back to pass so issue (expectedly) reoccurred?

Em: I see the expected types MPEG2VIDEO+MPEG2AUDIO+MPEG2AUDIO+DVBSUB or H264+AAC+AAC+DVBSUB as usual for UK Freeview with failed recordings with pass.

I was trying to stick with .ts, but on a reboot, the recordings start to fail again. Simply flipping off pass to matroska and back to pass fixes it until the next boot. I'll just leave it at matroska for now. No harm done.

Same symptoms with me (Build: 4.3-500~gb958667 (2017-09-24):
Realizing the damaged (~50k) recordings since one week, (but I've been on holidays before).
Some recordings fail, some where fine.

Bernd Gravenfeld wrote:

Some recordings fail, some where fine.

I can confirm this bug, too.