(Auto)Scan badly misses time-out
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.
You may also need to change the following:
@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.
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.)
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.
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?
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?
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.)
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.
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.
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?
- Best Answerset by DeltaMikeCharlie
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!
- Edited
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.
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.
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 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.
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.
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:
