Tvheadend

Adam Sutton wrote:

I don't quite follow what the problem is.

Your saying you can't add more than 2 muxes manually? Can't say I've encountered that problem.

And I don't understand the scanning point?

Adam

I used to add all multiplex manually without problems. With this version, I added one, a second, and when trying to add the third, there was no way to use any of any theselection button (8K/7K, ..) past the initial Mhz selection in any of subsequent fields.

I realized, it was stuck trying to probe the multiplex to get the channels but this was awfully slows 5min of more per multiplex. If you have dvb-t adapter and kown the muwes, try adding them manually and see waht happens.

Note: at the end it did work... But 15 mins later for the last muxes (only have five)

I can't repeat this, I've added several muxes manually for DVB-S system (that's all I have to hand) and it was fine.

Though I was testing some stuff on a users DVB-T system last week and we manually added 5-10 muxes without issue. So I'm still not entirely clear what the problem is?

Mux scan (for initial scan) should be no more than 20s per mux. Previously (i.e pre 3.2) there was a bug that meant it could get stuck on the last mux I think, that has been fixed.

A debug log might help to clear things up, understand what is going on etc..

Adam

Adam Sutton wrote:

I can't repeat this, I've added several muxes manually for DVB-S system (that's all I have to hand) and it was fine.

Though I was testing some stuff on a users DVB-T system last week and we manually added 5-10 muxes without issue. So I'm still not entirely clear what the problem is?

Mux scan (for initial scan) should be no more than 20s per mux. Previously (i.e pre 3.2) there was a bug that meant it could get stuck on the last mux I think, that has been fixed.

A debug log might help to clear things up, understand what is going on etc..

Adam

I've tested all of my DVB-T/T2 sticks (Hauppauge NOVA-T & NOVA-TD dual tuner, PCTV T2 Stick and an unbranded stick) adding muxes is instant.

Eric what device are you using? Have you also tried another adapter and software? This is really unusual.

Mark Clarkstone wrote:

Eric what device are you using? Have you also tried another adapter and software? This is really unusual.

I used a local pseudo tuner via dvbhdhomerun as I did not want to corrupt my old 2.12 modified setup on real dvb-t tuners right now because of partially integrated TS streaming features. But w_scan works fine on the pseudo tuners it and produce a correct vlc input file when using -L option. Using this xspf playlist vlc do see the streams correctly. Its logically equivalent to a dual tuner setup.

Maybe it is just a nasty bug/interaction with in dvbhdhomerun but what I find bizarre is the way the GUI did react with inaccessible dropdown selection. After a while 15min addition of the last muxer was indeed fast. Copying the various muxes to the other adapter worked fine also. After fixing a bogus proxy setup, using vlc to play the stream via http did work also.

Back a test. Its more than just the initial scan. I have channels that I cannot play and channels that works correctly. The same channels work correctly in vlc without restarting:

<title>0013. ARTE</title>
<location>dvb-t://frequency=498000000,inversion=2,bandwidth=8,code-rate-hp=9,coderatelp=9,modulation=0,transmission=0,guard=0,hierarchy=-1
</location>
<extension application="http://www.videolan.org/vlc/playlist/0">
<vlc:id>14</vlc:id>
<vlc:option>program=1543</vlc:option>
</extension>

and the name of the tvheadend http link is: http://localhost:9981/stream/service/_dev_dvb_adapter0_HDHomeRun_DVB_T498000000_0607 so at least the multiplex frequency is fine. Info in the service tag for the adapter is correct but vlc simply blocs. All channels on this transponder seems affected.

config for tvheadend:

more _dev_dvb_adapter0_HDHomeRun_DVB_T498000000 {
"quality": 100,
"enabled": 1,
"status": "OK",
"transportstreamid": 6,
"network": "F",
"frequency": 498000000,
"initialscan": 0,
"bandwidth": "8MHz",
"constellation": "AUTO",
"transmission_mode": "AUTO",
"guard_interval": "AUTO",
"hierarchy": "NONE",
"fec_hi": "AUTO",
"fec_lo": "AUTO"
}

more 21 {
"name": "ARTE",
"tags": [
8,
2,
1
],
"dvr_extra_time_pre": 0,
"dvr_extra_time_post": 0,
"channel_number": 7
}

Works on my 2.12 with same drivers. Did a full rescan via tvheadend and tested the new vlc playlist without restarting : works. I have no clue what happens. Will try debugging using -d...

A debug log would certainly help. There have definitely been various issues related to hdhomerun, but most of these have so far turned out to be the DVB drivers.

However if it works with VLC and not TVH then a debug log might help indicate where the fault lies.

Adam

Adam Sutton wrote:

A debug log would certainly help. There have definitely been various issues related to hdhomerun, but most of these have so far turned out to be the DVB drivers.

However if it works with VLC and not TVH then a debug log might help indicate where the fault lies.

Adam

Things get even more complicated: when running in debug mode after being logged as hts (su-> su hts) and running tvheadend -d it works for ARTE channel. I get this in the console window:

oct. 01 22:39:40 [INFO]:subscription: "HTTP" direct subscription to adapter: "HDHomeRun DVB-T", network: "F", mux: "F: 498,000 kHz", provider: "SMR6", service: "ARTE", quality: 100
oct. 01 22:39:41 [DEBUG]:webui: Start streaming /stream/service/_dev_dvb_adapter0_HDHomeRun_DVB_T498000000_0607
oct. 01 22:39:46 [DEBUG]:dvb: "/dev/dvb/adapter1" tuning to "F: 698,000 kHz" (Autoscan)

It starts directly from the command line I do not have to click on anything.

I killed the program and restarted tvheadend manually via /etc/init.d/tvheadend start and I get the same error as before: vlc stuck with no error and only the first line in the main window console:

oct. 01 22:41:35 subscription: "HTTP" direct subscription to adapter: "HDHomeRun DVB-T", network: "F", mux: "F: 498,000 kHz", provider: "SMR6", service: "ARTE", quality: 100. Restarted several time: sometimes it works, sometimes it is stuck. No need to restart userspace hdhomerun proxy or pseudo driver.

No more output. Noticed the following line in dmesg: tvheadend⁷⁸⁷¹: segfault at 50 ip 0000000000411619 sp 00007f8aa4fa70c0 error 4 in tvheadend[400000+82000] which is in pkt_merge_header just before the call to pktbuf_alloc 0x0000000000411619 <+105>: mov 0x10(%rdx),%rsi

Really need a debug log and ideally a full gdb trace for the crash.

Regards
Adam

Eric,

Any further updates on this. I think the MKV crash you noted may relate to a memory leak that has recently been fied (but cannot be sure as there's not much to go on).

As for slowness of adding muxes, I and other users are not seeing this.

And as for problems with playback from HDHomerun based devices, we are getting sporadic reports of this, but as far as I can tell its a problem with the HDHR DVB API wrappers. However that doesn't mean there isn't something that TVH can do to overcome the issues.

Adam

Well I tried new versions but did not readd the muxes so I do not know. You can close the bug report. I have seen other problem on the PI when adding an invalid mux and then a valid one after but you can close it.