Tvheadend

this is the bug tracker, please use the forum for support. further more this is a quite old build, you should update..,

B C wrote:

this is the bug tracker, please use the forum for support. further more this is a quite old build, you should update..,

I know this is the bug tracker, but if adding a mux manually fails to find services, isn't this a bug?
I will try to update to a more recent version and retry the tests by posting here the results, if any, though. Actually I though that scanning muxes should be a "consolidated" feature (it was working well in the past).

virtual dj wrote:

B C wrote:

this is the bug tracker, please use the forum for support. further more this is a quite old build, you should update..,

I know this is the bug tracker, but if adding a mux manually fails to find services, isn't this a bug?

This isn't a bug, it's been like this since the rewrite. I think it has something to do with changes to linuxdvb code in newer kernels.

I will try to update to a more recent version and retry the tests by posting here the results, if any, though. Actually I though that scanning muxes should be a "consolidated" feature (it was working well in the past).

Working well for you, you mean For many (myself included) the all AUTO method rarely worked correctly.

The problem is some drivers work with AUTO and some hate it with a passion.

Why you're opening a ticket complaining about this I'm not sure, you only have to enter more details to get it to scan correctly.

TVH passes these values directly to the driver through Linux DVBAPI. If you set the values to AUTO, the driver/firmware will guess the correct settings. The AUTO settings does not work for all devices. TVH does not do any guessing at the moment.

And yes, the tuning mux might fail, if user enters wrong (or incomplete) parameters for the Linux DVB driver. But it's problem of the kernel, isn't ?

Mark Clarkstone wrote:

virtual dj wrote:

B C wrote:

this is the bug tracker, please use the forum for support. further more this is a quite old build, you should update..,

I know this is the bug tracker, but if adding a mux manually fails to find services, isn't this a bug?

This isn't a bug, it's been like this since the rewrite. I think it has something to do with changes to linuxdvb code in newer kernels.

Now that you said this, I remember that I may have scanned the channels using a TVHeadend version pre-rewrite. And of course the kernel wasn't so recent (2.6.33.2).

Working well for you, you mean For many (myself included) the all AUTO method rarely worked correctly.

I didn't know that, sorry.

Why you're opening a ticket complaining about this I'm not sure, you only have to enter more details to get it to scan correctly.

Because I didn't know it was a kernel-related issue, as I was using the same tuner in the past but of course (now that I know) with a different kernel (2.6.33.2 vs 3.12.6).

Jaroslav Kysela wrote:

TVH passes these values directly to the driver through Linux DVBAPI. If you set the values to AUTO, the driver/firmware will guess the correct settings. The AUTO settings does not work for all devices. TVH does not do any guessing at the moment.

OK, I see. As I've written on the previous answer, I didn't know it might be a kernel issue, because an older kernel with the same tuner didn't have the issue. Unfortunately I understand now that newer kernel does not mean "better" features, then. In fact they broke it.

And yes, the tuning mux might fail, if user enters wrong (or incomplete) parameters for the Linux DVB driver. But it's problem of the kernel, isn't ?

Sorry, I didn't mean to criticize TVHeadend or its developers in ANY way, actually my aim was to help debugging and solving the issue, if there was one. I just didn't know that the kernel was the culprit.
So basically there's nothing I can do... just live with that.

Last question: is the missing service names also related to the kernel?

virtual dj wrote:

Mark Clarkstone wrote:

virtual dj wrote:

B C wrote:

this is the bug tracker, please use the forum for support. further more this is a quite old build, you should update..,

I know this is the bug tracker, but if adding a mux manually fails to find services, isn't this a bug?

This isn't a bug, it's been like this since the rewrite. I think it has something to do with changes to linuxdvb code in newer kernels.

Now that you said this, I remember that I may have scanned the channels using a TVHeadend version pre-rewrite. And of course the kernel wasn't so recent (2.6.33.2).

Working well for you, you mean For many (myself included) the all AUTO method rarely worked correctly.

I didn't know that, sorry.

No need to apologise, re-reading it back my response was a little narky I never intended it that way, sorry :p

Why you're opening a ticket complaining about this I'm not sure, you only have to enter more details to get it to scan correctly.

Because I didn't know it was a kernel-related issue, as I was using the same tuner in the past but of course (now that I know) with a different kernel (2.6.33.2 vs 3.12.6).

Fair enough

Jaroslav Kysela wrote:

TVH passes these values directly to the driver through Linux DVBAPI. If you set the values to AUTO, the driver/firmware will guess the correct settings. The AUTO settings does not work for all devices. TVH does not do any guessing at the moment.

OK, I see. As I've written on the previous answer, I didn't know it might be a kernel issue, because an older kernel with the same tuner didn't have the issue. Unfortunately I understand now that newer kernel does not mean "better" features, then. In fact they broke it.

I wouldn't say they broke it but just made it less forgiving. :p But if you think about it, it means less mistakes can be made.

And yes, the tuning mux might fail, if user enters wrong (or incomplete) parameters for the Linux DVB driver. But it's problem of the kernel, isn't ?

Sorry, I didn't mean to criticize TVHeadend or its developers in ANY way,

You're apologising again with no need to :p

actually my aim was to help debugging and solving the issue, if there was one. I just didn't know that the kernel was the culprit.
So basically there's nothing I can do... just live with that.

Unfortunately yes, but it really isn't a big deal unless you have to change frequencies constantly. With Network discovery enabled you really only need to enter one frequency fully anyway and Tvheadend should find the rest.

Last question: is the missing service names also related to the kernel?

I think that's more to do with the driver than the kernel.

Missing service names: It might be that the gathered information are incomplete. The names are in the different DVB table. Also, I remeber a bug in older code which create "phantom" services without names. Please, upgrade to latest.

@ virtual dj: as shown in your screenshots you come from Italy. The 1600 MHz mux isn't a tvheadend issue, it's a wrong data transmission from another mux (telecity for me) which send this for mux discovery service.
In your network settings simply disable that option and delete the 1600 MHz mux (mux discovery is pointless in a dvb-t setup - all 60 frequencies can easily be set).

May i ask why don't you use presets in network setup? They work flawlessly for me.

The 1600Mhz is really provider's issue - this frequency is invalid and it's announced using the DVB information tables. Just disable this mux.

177.5Mhz - could you grab cca 30 seconds from this mux ? Use play list in the mux grid and paste it to 'wget -O a.ts <MUXURL>' .

Jaroslav Kysela wrote:

The 1600Mhz is really provider's issue - this frequency is invalid and it's announced using the DVB information tables. Just disable this mux.

OK, so it's the provider that it's injecting this mux. Thanks for checking it.

177.5Mhz - could you grab cca 30 seconds from this mux ? Use play list in the mux grid and paste it to 'wget -O a.ts <MUXURL>' .

I'm attaching the file a.ts, captured using your instructions.

Paolo Roascio wrote:

@ virtual dj: as shown in your screenshots you come from Italy. The 1600 MHz mux isn't a tvheadend issue, it's a wrong data transmission from another mux (telecity for me) which send this for mux discovery service.
In your network settings simply disable that option and delete the 1600 MHz mux (mux discovery is pointless in a dvb-t setup - all 60 frequencies can easily be set).

Thanks, I didn't know that.

May i ask why don't you use presets in network setup? They work flawlessly for me.

For me the Italy: it-All preset doesn't work correctly, maybe your tuner is more AUTO-friendly than mine.
I get only 1 mux not failing of the whole list, while adding the muxes manually by specifying their data of course works correctly.

These screenshots are self-explanatory and created using Italy: it-All:

Are you sure you did try to scan the muxes using the presets recently?
Using the same tuner and kernel 2.6.33.2 the scans with the presets worked also for me, but now they don't... and this is the reason why I opened this ticket, thinking it was a TVHeadend issue.

Sorry, the upload failed with "Request Entity Too Large" (the file is about 120 MB so it should not fail). I'm attaching the a.ts file as a Dropbox link:
https://dl.dropboxusercontent.com/u/9526782/a.ts

Anyway at the top of the ticket you also have the previous muxdumps.

virtual dj wrote:

Sorry, the upload failed with "Request Entity Too Large" (the file is about 120 MB so it should not fail). I'm attaching the a.ts file as a Dropbox link:
https://dl.dropboxusercontent.com/u/9526782/a.ts

Anyway at the top of the ticket you also have the previous muxdumps.

The upload error is because cloudflare only allow 100MB upload through their proxies.

Are you sure you did try to scan the muxes using the presets recently?
Using the same tuner and kernel 2.6.33.2 the scans with the presets worked also for me, but now they don't... and this is the reason why I opened this ticket, thinking it was a TVHeadend issue.

I regularly build tvheadend from git with the last dvb data downloaded in the build process and yes, i always recreate the whole configuration from scratch (this for my tests). I never advised problems with presets.
I use a heavily customized OpeneLEC (git) with 4.1.12 kernel. My tuners are two Avermedia Avertv Volar Hd Pro A835 sticks.

For the record, in the scan process, there are services with invalid data (no lcn number, no service name, continuity errors), but i verified that this isn't a tvheadend problem too: signals for these services are really poor in my zone (Alessandria with mux in Valcava - Brescia or Bric - Tourin) and also my TVs are affected, the only one that works correctly is my SHARP LC-DH77E. These tests are performed with a field RF meter Unaohm AP-301HD and for the affected services the BER is very high.

My actual setup is 450 services and 290 mapped channels (encripted are deliberately excluded)

Paolo Roascio wrote:

I use a heavily customized OpeneLEC (git) with 4.1.12 kernel. My tuners are two Avermedia Avertv Volar Hd Pro A835 sticks.

Unfortunately the QNAP NASes do not allow the user to upgrade the kernel, so I have to stick to the kernel bundled with the QNAP firmware.
So maybe the kernel support in 4.1.12 for DVB-T is better than mine; the only thing I regret is that with the older 2.6.33.2 all was working well.

My actual setup is 450 services and 290 mapped channels (encripted are deliberately excluded)

It's impressive to hear that, considering that my tuner detects only 12 services with the bundled presets. Bear I mind I have good reception with the manual settings, it's just the AUTO feature that does not work well (with the current kernel).

I tried this with latest TVH and I see all service names.
Please, upgrade. Closing as invalid.

I've compiled the latest TVHeadend v4.1-1047~g851aebb (64-bit) and retried with mux 177500000 (added manually).
It finds 8 services but neither one has names. I may be dumb for sure, but it doesn't work on my system (with this mux). How did you feed the ts file to see if it finds the names?

Maybe it's something different on the QNAP, for example related to gconv?
As it's not available on the operating system "out of the box" I'm providing the environment variable:

export GCONV_PATH=/tvheadend/path/gconv

Just a small update: after upgrading to 4.1-1246~gdc4e037, manually scanning the 177.5 MHz mux finds the whole service names.

So it was not a gconv problem!

Thanks.