Tvheadend

I posted this problem to a forum on Silicon Dust which make the HDHomeRun tuner. They claim:

"The HDHomeRun has a filter that is controlled by the PVR application to allow only certain portions of the stream through. It is entirely up to the application to control this at the time of streaming."

I found no setting in TVheadend to choose an audio channel to record. I did a test recording on the same channel that caused the problem and I found that this recording had both audio streams present. Is there such a setting in TVheadend?

Also, during the test recording, I had debug logging turned on. As the recording was stopping, I saw a message:

Apr 13 23:00:35 PSI: Service "HDHomeRun ATSC/219,000 kHz" PMT (version 31) updated, Language changed

What does the "Language changed" mean? The descriptive audio is send on the Spanish language audio stream. For some reason, the channel is viewed as a Spanish channel even though it is the local CBS station. When I play back a test recording in VLC, it thinks the audio and video streams are in Spanish.

Are you recording to mkv? If you are, there are a few issues relating to audio streams related to mkv, so give TS a try.

To be honest... it doesn't sound like any of the issues I've come across, but nothing to lose giving it a shot I'd say.

If it doesn't work, what does mediainfo say about the files? Do they have two audio tracks?

I'd go with Ben on this one... my (utterly uneducated and random) guess would be that there's a change in language flag on one or more of the audio streams, resulting in one of them getting dropped, corrupted, left down the back of the sofa, or similar. Ben: I suppose this could be similar to a stream switching from 2 to 6 channels?

You should see a syslog entry as the recording starts that identifies what tvheadend thought the audio tracks were, something like:

Apr 16 18:29:00 Server tvheadend[10562]: dvr: /recording_path/somefile.mkv from adapter: "Wibble", network: "ASTRA", mux: "ASTRA: 10,818,000 kHz Vertical (No satconf)", provider: "BSkyB", service: "Service_name" 
Apr 16 18:29:00 Server tvheadend[10562]: dvr:  #  type              lang  resolution  aspect ratio  sample rate  channels
Apr 16 18:29:00 Server tvheadend[10562]: dvr:  1  MPEG2VIDEO              720x576     16:9
Apr 16 18:29:00 Server tvheadend[10562]: dvr:  2  MPEG2AUDIO        eng                             48000        2
Apr 16 18:29:00 Server tvheadend[10562]: dvr:  3  MPEG2AUDIO        nar                             48000        2
Apr 16 18:29:00 Server tvheadend[10562]: dvr:  4  TELETEXT          nar                                                    <disabled, no valid input>
Apr 16 18:29:00 Server tvheadend[10562]: dvr:  5  DVBSUB            eng         
Apr 16 18:29:00 Server tvheadend[10562]: dvr:  6  TEXTSUB           eng      

(nar = audio described for me ... "NARrative", I believe).

See how the stream is initially declared/identified.

See if .TS helps; see if streaming directly to VLC helps identify anything (it should be the same as .TS, i.e. no re-muxing just a raw handoff of the received data); check to see if VLC changes its mind about the stream as you go through a recorded file, i.e. does the language change at the end of the continuity announcement/beginning of the main programme, for example (you can have the media info window open as you play).

The bad streams appear to have only one audio track, the spanish one where descriptive audio is stored. Yes, I am using mkv format. I will switch to .TS.

Yesterday, I did a test recording and it worked fine and contained two audio tracks. Prior to scheduling the recording, I purposely left the HDHR on a different channel. After that recording completed, I scheduled another short recording on the same channel. That recording only had one audio track, the spanish one. This evening, I tried it again. Switching HDHR to a different channel using a Windows Box, I did a short recording and this time, I got only the english stream. Next, I changed it to .TS and started another recording. That recording is still on-going, but it appears to contain both audio streams. Therefore, I do not know what the trigger is for the different audio streams.

I looked for entries in /var/log/syslog.log. However, my log file contains nothing about the HDHR tuner. I searched through the logs in /root/.hts/tvheadend. I found some info in dbvtransports. However, these files appear to only be updated occasionally. They do not appear to be updated on every recording.

Below is what the file contained. The first entry was from yesterday when it recorded the spanish track. The second entry was from today when it recorded the both language tracks. I don't know why the amount of information is different between these, as the recording setups were identical.

Can anyone point me to what logs I should be looking at? I turned on debug in the web interface and what it during the recordings. However, it did not print anything about the audio stream.

{
"service_id": 623,
"pmt": 64,
"stype": 0,
"scrambled": 0,
"channel": 0,
"dvb_eit_enable": 0,
"pcr": 65,
"disabled": 1,
"stream": {
"pid": 65,
"type": "MPEG2VIDEO",
"position": 0,
"width": 720,
"height": 480
},
"stream": {
"pid": 68,
"type": "AC3",
"position": 1,
"language": "spa"
}
}

{
"service_id": 1531,
"pmt": 48,
"stype": 0,
"scrambled": 0,
"channel": 0,
"channelname": "1531 KEYEDT (CBS)",
"mapped": 1,
"dvb_eit_enable": 1,
"pcr": 49,
"disabled": 0,
"stream": {
"pid": 38,
"type": "AC3",
"position": 0,
"language": "spa"
},
"stream": {
"pid": 49,
"type": "MPEG2VIDEO",
"position": 1,
"language": "spa",
"width": 1280,
"height": 720
},
"stream": {
"pid": 52,
"type": "AC3",
"position": 2,
"language": "eng"
}
}

Thanks.

----- Steve

It is sounding more similar to the other things that .ts has solved now…. so hopefully

On Thursday, 18 April 2013 at 04:58, [email protected] wrote:

Tvheadend - General: RE: Descriptive Audio Only in Recording (https://tvheadend.org/boards/5/topics/8244?r=8316#message-8316)
Steve Miller
The bad streams appear to have only one audio track, the spanish one where descriptive audio is stored. Yes, I am using mkv format. I will switch to .TS.
Yesterday, I did a test recording and it worked fine and contained two audio tracks. Prior to scheduling the recording, I purposely left the HDHR on a different channel. After that recording completed, I scheduled another short recording on the same channel. That recording only had one audio track, the spanish one. This evening, I tried it again. Switching HDHR to a different channel using a Windows Box, I did a short recording and this time, I got only the english stream. Next, I changed it to .TS and started another recording. That recording is still on-going, but it appears to contain both audio streams. Therefore, I do not know what the trigger is for the different audio streams.
I looked for entries in /var/log/syslog.log. However, my log file contains nothing about the HDHR tuner. I searched through the logs in /root/.hts/tvheadend. I found some info in dbvtransports. However, these files appear to only be updated occasionally. They do not appear to be updated on every recording.
Below is what the file contained. The first entry was from yesterday when it recorded the spanish track. The second entry was from today when it recorded the both language tracks. I don't know why the amount of information is different between these, as the recording setups were identical.
Can anyone point me to what logs I should be looking at? I turned on debug in the web interface and what it during the recordings. However, it did not print anything about the audio stream. {
"service_id": 623,
"pmt": 64,
"stype": 0,
"scrambled": 0,
"channel": 0,
"dvb_eit_enable": 0,
"pcr": 65,
"disabled": 1,
"stream": {
"pid": 65,
"type": "MPEG2VIDEO",
"position": 0,
"width": 720,
"height": 480
},
"stream": {
"pid": 68,
"type": "AC3",
"position": 1,
"language": "spa"
}
} {
"service_id": 1531,
"pmt": 48,
"stype": 0,
"scrambled": 0,
"channel": 0,
"channelname": "1531 KEYEDT (CBS)",
"mapped": 1,
"dvb_eit_enable": 1,
"pcr": 49,
"disabled": 0,
"stream": {
"pid": 38,
"type": "AC3",
"position": 0,
"language": "spa"
},
"stream": {
"pid": 49,
"type": "MPEG2VIDEO",
"position": 1,
"language": "spa",
"width": 1280,
"height": 720
},
"stream": {
"pid": 52,
"type": "AC3",
"position": 2,
"language": "eng"
}
}
Thanks.
----- Steve
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: https://tvheadend.org/my/account

Those "logs" you list are the underlying services as detected when you first scanned the muxes. On my system, the "stream" sections go on to list Teletext and Conditional Access status as well as video and audio streams. What I don't know is whether these are set in stone (i.e. what you find on first scan is all you can ever have) or whether they're descriptive versus directive (i.e. do they simply tell you what was there, or do they subsequently tell tvheadend what it should be looking for?). I can't imagine they're directive simply because the streams wash in and out dependent on programme type (e.g. stereo versus surround, not all programmes are audio described, and so on).

Depending on the answers to those imponderables, you may have to re-scan your services to see if anything better is detected next time.

Regarding the syslog, that's lost on my as to why you don't have those entries - maybe it's saved somewhere else on your distro, but I'm sure there should be something on a 'buntu derivative. There is a debug flag you can set for when tvheadend starts, maybe that will give more information (the danger is "a lot more"). Look for /etc/default/tvheadend, and set DEBUG=1.

With the streaming file set to .TS, I ran five short recordings during the day today. In reviewing the recordings this evening, I found that all five contained both audio streams. I set up another six for tomorrow morning. If these are OK, then I will switch back to .mkv and repeat the test. I do not know how frequent this intermittent problem is. Many channels do not run a different language on their second stream. Instead, they just seem to repeat the English broadcast in mono. Therefore, lots of my recordings for my wife may have had the problem but was unnoticed. It would only be noticeable when the program had the descriptive audio added.

I am embarrassed to say, that I cannot quite remember how to start my HDHR driver and TVheadend. I started these apps running six months ago from a console window. I thought I would run it until I had a glitch or crash and then use my notes to setup a startup script. Well, in six months, TVheadend never crashed, all winter long we never had a power outage, and I have since lost my notes. I guess over the weekend, I will experiment with getting this documented in a script on my NAS.

As an update, I have to report that my testing with .TS streams was flawed. I thought I switched to .TS, but never hit the "Save Configuration" button. Therefore, for several days I made lots of short recordings that all worked, but were still at the .mkv setting.

I switched to .TS AND hit save. I also connected via SSH and verified that the file extension is now .TS. The recordings thus far, have been fine. However, the results are inconclusive as lots of mistaken .mkv recordings were OK as well.

So anyone following this thread, I do not really have a answer. My problem appears to occur most when the tuner has been inactive for several days. I don't have a good way to force the issue to occur, so until I can consistently reproduce the issue, I am at the mercy of this intermittent gremlin.

Finally, I have no evidence where the issue lies. It may be the HDHR tuner itself, it may be the driver I am using for the tuner, or it may be TVheadend. I am not implying that it is TVheadend just because I am posting to this forum.

I also have an HDHR3 and have been using TVHeadend for about a year. A couple of recordings over the past couple of months had the descriptive audio, which was entertaining itself for one of the shows. Some recordings over the past couple of weeks had no audio. The version of TVHeadend when this happened was 3.5.126. I'm going to switch to "pass through" (*.TS) and see if that helps.