Bug #3301
closed
DVB-T add mux 'AUTO' not working and missing channel titles
Added by virtual dj over 9 years ago. Updated over 9 years ago.
0%
Description
I'm trying to make a recent TVHeadend version (4.1-360~g0916e52) work on a x86_64 QNAP NAS from scratch, i.e. without importing a previous channels configuration.
On another x86 NAS in fact I'm running TVHeadend 3.9.2709~g6b472cd but channels were actually discovered using older versions of TVHeadend (I don't remember exactly the version number, but years ago).
So, the tuner is an Hauppauge WinTV Nova-T (Dibcom 7000PC) but this issue seems not tuner-related but DVB instead.
Basically I'm creating a network named Test of type DVB-T without adding any preset, as they do not work, so just an empty network assigned to the tuner.
Then I go to DVB Input > Muxes and click Add; I select the network Test and create a new one with these parameters (only the Hz):
After a couple of seconds I got the attached Log_177500_Auto.txt.
And a FAIL status:
So it seems that the AUTO settings do not work... I've tried then to remove the mux and then adding a new one but this time copying the settings for the same mux from the other NAS (where TVHeadend is working).
Here they are:
When confirming I get the attached log Log_177500_Manual.txt.
And a success status with the number of services > 0:
... but without any service name:
I'm attaching the muxdump (file sample_177500.ts) so you can investigate.
This is not the only problematic mux, for example another one with auto settings:
With attached log Log_698000_Auto.txt.
Removed, added again with manual settings:
As you see, a "spurious" mux is created (automatically) but at least the services are discovered.
And on this mux there are also the service names (at least for one of the two 698 MHz muxes):
I get the attached log file Log_698000_Manual.txt.
I'm attaching the muxdump too, as sample_698000.ts for the mux with network ID 272 and sample_698000_spurious.ts for the other one with ID 65535. Please note that both of these two are not playable with VLC (while sample_177500.ts is).
Sorry for the long post, but I think it would be better to have the whole debug info.
Files
| Log_177500_Auto.txt (5.2 KB) Log_177500_Auto.txt | virtual dj, 2015-11-14 21:34 | ||
| Log_177500_Manual.txt (20.7 KB) Log_177500_Manual.txt | virtual dj, 2015-11-14 21:34 | ||
| Log_698000_Auto.txt (5.83 KB) Log_698000_Auto.txt | virtual dj, 2015-11-14 21:34 | ||
| Log_698000_Manual.txt (84.8 KB) Log_698000_Manual.txt | virtual dj, 2015-11-14 21:34 | ||
| sample_698000.ts (76.5 MB) sample_698000.ts | virtual dj, 2015-11-14 22:30 | ||
| sample_177500.ts (79.4 MB) sample_177500.ts | virtual dj, 2015-11-14 22:30 | ||
| sample_698000_spurious.ts (76.5 MB) sample_698000_spurious.ts | virtual dj, 2015-11-14 22:56 | ||
| Log_177500_New.txt (29.4 KB) Log_177500_New.txt | Log file after adding a mux with v4.1-990~g2afa831 | virtual dj, 2015-11-16 20:36 | |
| sample_new_177500.ts (52.5 MB) sample_new_177500.ts | Muxdump with v4.1-990~g2afa831 | virtual dj, 2015-11-16 20:47 |
Updated by B C over 9 years ago
this is the bug tracker, please use the forum for support. further more this is a quite old build, you should update..,
Updated by virtual dj over 9 years ago
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).
Updated by Mark Clarkstone over 9 years ago
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.
Updated by Jaroslav Kysela over 9 years ago
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 ?
Updated by virtual dj over 9 years ago
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?
Updated by Mark Clarkstone over 9 years ago
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.
Updated by Jaroslav Kysela over 9 years ago
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.
Updated by virtual dj over 9 years ago
- File sample_new_177500.ts sample_new_177500.ts added
- File Log_177500_New.txt Log_177500_New.txt added
Jaroslav Kysela wrote:
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.
OK, now with version 4.1-990~g2afa831 (and after clearing the config folder) the phantom service is not there anymore when adding the mux manually:
But after 5 minutes it re-appears:
You can see on the attached logfile Log_177500_New.txt that at 20:18:12.018 there was a service, while 20:26:12.000 another one is created, but I didn't click anything.
Actually I captured the new muxdump with curl (attached file sample_new_177500.ts), it may be that action that triggered the new "frequency".
Unfortunately, neither the service names are there (at least for that frequency):
Can you see if the names are there in the muxdump?
By looking with an hex viewer I can see the some channel names inside, but I don't know if they're in the correct location. What's the proper way to debug that?
Updated by Paolo Roascio over 9 years ago
@ 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.
Updated by Jaroslav Kysela over 9 years ago
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>' .
Updated by virtual dj over 9 years ago
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.
Updated by virtual dj over 9 years ago
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.
Updated by Mark Clarkstone over 9 years ago
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.tsAnyway 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.
Updated by Paolo Roascio over 9 years ago
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)
Updated by virtual dj over 9 years ago
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). :(
Updated by Jaroslav Kysela over 9 years ago
- Status changed from New to Invalid
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.tsAnyway at the top of the ticket you also have the previous muxdumps.
I tried this with latest TVH and I see all service names.
Please, upgrade. Closing as invalid.
Updated by virtual dj over 9 years ago
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/gconvand on that folder I have the .so files. I tried to run a small C script that calls iconv_open and when using that folder it works.
Updated by virtual dj over 9 years ago
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.