(Auto)Scan badly misses time-out

Digard · 2024-06-23T09:23:35+00:00

I have been fighting with an otherwise almost impeccable tvheadend for the last weeks, together with the very helpful support of Sundtek. I couldn't get a us...

Jonas Lang

I’ve noticed over the last couple of days there has been a rush of users, possibly new users all simultaneously posting their issues. Reminds me of our public transport system. Nothing for ages then everything arrives together. Good to see some of the more seasoned users back contributing to the forum too. I digress.

You now have a Network defined. Forget about using predefined mux tables. They are woefully out of date and basically useless.

Ensure your defined network is empty and free of all muxes. From there you can add a known working mux and enable a full network scan. That should provide you with a full list of your local muxes fully scanned and ready for services to be mapped.

I’ve posted this procedure a number of times on the forum so rather than repeat myself again, search the forum for further details.

Digard

Jonas Lang
Tried your suggestion, I think, correctly. That is, starting from scratch, adding TVadapter, enabling it, add DVB-C network, enabling it, add a mux as given on the current website of the provider, 370000000, symbol rate 6900000, QAM256, saved it. Since then it is resting there, saying PEND. Tried to change it to IDLE and ACTIVE, Saved and Applied, to no avail. It stays on PEND. I have Force Scan-ed the network. So far nothing.
Am I missing anything?

DeltaMikeCharlie

You may also need to change the following:

DeltaMikeCharlie

@Digard - Can you please go into Configuration -> DVB Inputs -> Muxes -> Select 370Mhz -> Edit, and take a screen print of the settings for that mux?

It would be interesting to compare your TVH values to the scan-w values for the same mux.

Digard

DeltaMikeCharlie
I think this is the one? I had submitted it already a few days ago to the Sundtek forum. There I was told that the 64QAM was wrong. It was assumed that I had set it; but I never had (being a beginner, didn't even know it existed, having just started with wizard). Then I changed to 256QAM, Force Scan, and the stuck state, observed with mediaclient, was posted in my first post as above.

(I'll look into the other post(s) tomorrow, since it is nightfall here, sorry.)

Jonas Lang

The majority of the issues as described above relate to using the dreaded predefined mux tables during the Configuration Wizard process. Maybe it’s time we either ditch the predefined muxes option in the Configuration Wizard or maintain our own predefined mux tables. Personally I’d opt for ditching the predefined mux tables and point the new user towards a full network scan using a known mux.

Maybe the developers might want to have a closer look at the Configuration Wizard with a view to overcoming this recurring issue. Maybe invite the user to enter a known working mux and enable a full network scan during the Configuration Wizard process.

Digard

Jonas Lang
As you know, I'm a beginner. A few weeks ago I didn't know what a mux was (and still today, I don't, really).
But w_scan doesn't know either, and makes no mistake; and the 'stupid' hardware cable tuner also doesn't know anything about my provider. At least, so I think.

What hinders tvheadend to do likewise; respectively import a proper parameter list? That should be serious fun, if I could share that list with friends and neighbours after some allocation change, to just import that list? I guess everyone here, sitting on the same network, gets the same services?

So, why would a user have to google for a working mux?

DeltaMikeCharlie

Digard As you know, I'm a beginner. A few weeks ago I didn't know what a mux was (and still today, I don't, really).

'mux' is short for 'multiplexer'. Multiplexing is a technique for combining multiple data streams into one data stream that can be transmitted and then later be de-multiplexed into the original multiple data streams once it has been received. In the context of digital TV, it is the way that broadcasters send multiple TV channels over the same frequency.

TVH, or any digital TV system, needs to know the details about the mux so that it can decode the data that is being broadcast. This includes the frequency, but also some data encoding and error correction parameters.

Digard But w_scan doesn't know either, and makes no mistake;

Because 'w_scan' is able to determine the list of channels on your 370Mhz mux, we just need to tell TVH the correct settings to use.

Here is an extract from your scan-w file.

-_-_-_-_ Getting frontend capabilities-_-_-_-_ 
Using DVB API 5.10
frontend 'Sundtek DVB-C (III)' supports
INVERSION_AUTO
QAM_AUTO not supported, trying QAM_64 QAM_256.
FEC_AUTO
FREQ (42.00MHz ... 1002.00MHz)
SRATE (0.520MSym/s ... 7.233MSym/s)
-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_

searching QAM256...

tune to: QAM_256  f = 370000 kHz S6900C0  (61441:9999:10002) (time: 12:53.717) 
        already known: (QAM_256  f = 346000 kHz S6900C0  (61441:9999:10008)), but not found by pids

        service = TV 5 Monde (fre) (Digital Free)

You mention that you have already changed your settings to QAM_256.

I have also noticed that your FEC is set to 'NONE', whereas your w_scan has the value set to "AUTO". Have you tried changing this parameter?

Digard

DeltaMikeCharlie
A simple 'NO'.
That's why I pointed out the change of QAM, the only one I ever effected.

The fresh (second) install and using the wizard, selecting the closest provider (actually mine), TV 5 Monde was 'found' on the 170 MHz mux. And during recording, it recorded something on 170 MHz; though there are only encrypted signals.
(The whole set of info can be seen in the post in the Sundtek forum; see above, in case.)

DeltaMikeCharlie

I have found that I can read the output of the w_scan command as a TVH scan file.

I ran the command w_scan -f t -c AU -x > au-wscan and copied the output file into my scan file directory and restarted TVH.

(Please note that the w_scan parameters -f t and c AU are specific to me [DVB-T/Australia], the -x parameter created the output in the required format.)

When I created a new network and selected au-wscan as my Pre-defined Muxes, my muxes were created automatically. When I assigned my new network to my adapter, I was able to successfully scan my services.

Digard

DeltaMikeCharlie
Thanks a bunch. I'm pretty busy these days, will come back probably during the weekend, and try this myself here, with -f cand c DE.

And hope to furnish the log by then, too.

Digard

DeltaMikeCharlie
Yep. Almost. Did this, and copied it into /usr/share/tvheadend/data/dvb-scan/dvb-c.
(had to sudo systemctl restart tvheadend.service, otherwise it wouldn't want to show)
Again, did nothing, because the mux showed as 0MHz, no symbol rate. (Edit view). Really don't understand this!! Where does it read this??)
In any case, after manually entering a correct 370 MHz and 6900000 it immediately started, and brought up 28 muxes very quickly, and all on 'OK'; which I never had before.

So it seems my problem is 'fixed', as they might say. But it isn't fixed, actually. I wouldn't believe that I'm the only one with this hassle. Compared to anything else, tvheadend looks sub-par w.r.t. auto-scanning.

In any case, I include the w_scan for eventual use. Don't forget to change Frequency and Symbol rate, additionally!

de-wscan-voda-nrw.txt

2kB

Jonas Lang

Digard try stopping TVH after adding the mux details and then restart it. It should start the scan process. If not to switch it to Active and Save it.

DeltaMikeCharlie

Digard So it seems my problem is 'fixed', as they might say.

Good news.

Digard In any case, I include the w_scan for eventual use. Don't forget to change Frequency and Symbol rate, additionally!

Please mark the posting as the 'best solution' so that other users have a better chance of seeing it.

Digard

DeltaMikeCharlie
Thanks to you! - I had been asking here and there on how to make use of a successful w_scan to import into tvheadend. Finally you found it!
I don't think I could mark my own as 'best answer'. I guess someone else has to do so.

DeltaMikeCharlie

Digard I don't think I could mark my own as 'best answer'. I guess someone else has to do so.

I have marked your post as the 'best answer' because it summarised the solution neatly.

Digard

Jonas Lang
Thanks. You might have seen by now that the problem has been 'solved'; at least individually. I didn't know about the restart.
In any case, kudos to you, and your insistence that the pre-defined tables may produce more misery than they might help. I've been in this for the last 5 weeks or so, and finally, today everything turned out properly by feeding tvheadend the correct list of muxes, within minutes, thanks to DeltaMikeCharlie.

A complete description of your method, and maybe this method, should be pinned at the top, I think.

Digard

DeltaMikeCharlie
Thanks!
It really serves the purpose. I had had time and paper ( ;-) ), and compared the list of provided services offered by the provider with the list of services found by tvheadend through this method. It finally fits 1:1: provider says 121 TV channels, 105 radio channels - tvheadend shows 121 TV channels and 105 radio channels.

Digard

Only in case someone ever stumbles on this thread, despite of being 'solved', I have taken new confidence into the matter and explored further possible reasons for the scan failure: tvheadend seems unable to discard muxes inserted through pre-defined lists. In my case, it had a wrongly configured 370 MHz mux, because it had been passed a 370 MHz mux from the predefined list with wrong parameters (see above), and a 370 MHz mux supplied 'freshly' from the cable network. It simply stumbled across its own feet by contradictory parameters.

I manually compared the list of muxes of w_scan with the muxes found on my pre-defined list (51 altogether), deleted those not found by w_scan 828 left), and - eureka! - suddenly the scan went through smoothly and quickly.
So far nobody was able to convince me that this would NOT be a bug!
Maybe not quite correctly formulated in the title, though a time-out might still be useful, but one step seemingly missing: using the predefined list (okay), contacting some muxes from the provider (correct), deleting those that are not available, respectively have contradictory parameters (missing).

To me the method proposed by Jonas further up seems most adequate, in principle, if ever anyone would care to resolve this bug: find an 'access' to the provider network, get a minimal number of working muxes (one?), and then discard anything else.

Or, make w_scan a library, ask the user for network type and country, and produce a list of active muxes, and start scanning then.

davep

I'm not sure that it would have fixed your problem, but there is an outstanding PR from 3 years ago which provided a time-out on subscription failure:

tvheadend/tvheadend1399

Jonas Lang

Workarounds are not permanent solutions though. If a problem has been identified it would need to be addressed in further commits. That would be a matter for the developers/maintainers of TVH.

I find that commits are not being thoroughly tested these days. No fault of the developers/maintainers though. They can only work on the hardware they have in front of them. The user base needs to get more actively involved in this aspect of the cycle. A user who finds a workaround needs to report that they’ve discovered an issue in the first place otherwise these issues will surface again and again.

The one lesson learnt here as with many of the recent issues posted on the forum is for the user to supply a full list of hardware, OS, tuner brand where applicable and logs where possible before other users wade in to try and debug the issue. Remember you need to help us to help you. TVH is installed on the most diverse platforms you can imagine these days.

Flole

Jonas Lang No fault of the developers/maintainers though. They can only work on the hardware they have in front of them.

There is still an ongoing effort to get test hardware for all features of Tvheadend. So that is a known problem, but of course volunteers who test PRs are also highly appreciated.

« Previous Page