Tvheadend

yep, i have same bug when add new mux not start to scan and stay "PEND" i need force to play mux to start scan.

Attach output from '--trace mpegts' : https://tvheadend.org/projects/tvheadend/wiki/Traces

TRACE lines are missing. Please, follow all instructions in the link in comment 2.

Again, those muxes fail to scan anyway. But exactly same thing happens on perfectly fine muxes also. It just gets stuck at PEND status and does not try to scan at all. I didnt want to mess up my existing muxes by deleting them and then setting the up again. But if you need me to do that, I can do it also

Add more traces,pls: '--trace mpegts,linuxdvb,service'.

And subscription: '--trace mpegts,linuxdvb,service,subscription' .

Please, create new trace logs with latest v4.3-147-g5f27a4b .

Jaroslav Kysela wrote:

Please, create new trace logs with latest v4.3-147-g5f27a4b .

root@ubuntu:/tmp# tvheadend -v
tvheadend: version 4.3-147~g5f27a4b
root@ubuntu:/tmp#

It is exactly the same:
1- Started force scan at 2017-05-25 13:47:41.813
2- Got stuck at 2017-05-25 13:47:52.318 and printed same message every 2 minutes
3- I set offending muxes to ignore at 2017-05-25 13:50:47.376 (it scanned 634Mhz then which was waiting because of stuck muxes).
4- Restart at 2017-05-25 13:51:54.826
5- Enabled muxes and set them to pend at 2017-05-25 13:52:40.999
Then it scanned them...

By the way, apparently I dont have to restart tvheadend, it scans the problem muxes when I set them IGNORE then back to ENABLE and PEND manually.

I Scan in network 30 muxes and add 42 more muxes repeated with same configuration exept delivery system dvb-s change for dvb-s2. If i do a force scan with new muxes + changed muxes in the middle of the scan get stuck.

Jaroslav Kysela delete my issue because is very similar to this issue.

Evren Yurtesen

i have same problem like you

When I try to scan the muxes from scan status putting idle to active manual, it gets stuck because it tries to scan the muxes added with different configuration and maybe tvh or dvbs card not recognizing the configuration and get stuck in idle.

@cilin dro: which issue? number?

Fixed in v4.3-149-g8802233 .

And in v4.2.2-23-ga28861f .

Jaroslav Kysela wrote:

And in v4.2.2-23-ga28861f .

Are you sure? Because I installed v4.2.2-29~g80e1fdf and still having the same issue?

I was almost sure, but I've not tried the code. Provide the logs again.

Jaroslav Kysela wrote:

I was almost sure, but I've not tried the code. Provide the logs again.

root@ubuntu:~# tvheadend -v
tvheadend: version 4.2.2-29~g80e1fdf
root@ubuntu:~#

OK I deleted the offending muxes and set 'New muxes + changed muxes' in 'Network discovery'

1- Clicked on 'Force scan' at 2017-05-26 00:14:36.237 after scanning first 3 muxes, it gets stuck at 514Mhz and puts repeating messages at 2017-05-26 00:14:49.266
2- At 2017-05-26 00:21:15.506 I put them as IGNORE
3- At 2017-05-26 00:22:14.364 I enable them back and set them as PEND

It scans them...

What is the problem? It seems like it can't start scan when it says 'adding mux Multiplex' instead of the MHz value?

2017-05-26 00:14:36.237 [  DEBUG]:mpegts: adding mux 538MHz in Turku to scan queue weight 6 flags 4000
2017-05-26 00:14:36.237 [  DEBUG]:mpegts: adding mux 634MHz in Turku to scan queue weight 6 flags 4000
2017-05-26 00:14:36.237 [  DEBUG]:mpegts: adding mux 682MHz in Turku to scan queue weight 6 flags 4000
2017-05-26 00:14:38.724 [  DEBUG]:mpegts: adding mux Multiplex [onid:20F6 tsid:1001] in Turku to scan queue weight 5 flags 1000
2017-05-26 00:14:38.724 [  DEBUG]:mpegts: adding mux Multiplex [onid:20F6 tsid:3001] in Turku to scan queue weight 5 flags 1000
2017-05-26 00:14:38.724 [  DEBUG]:mpegts: adding mux Multiplex [onid:20F6 tsid:5001] in Turku to scan queue weight 5 flags 1000
2017-05-26 00:14:42.724 [  DEBUG]:mpegts: removing mux 538MHz in Turku from scan queue
2017-05-26 00:14:45.363 [  DEBUG]:mpegts: removing mux 634MHz in Turku from scan queue
2017-05-26 00:14:49.266 [  DEBUG]:mpegts: removing mux 682MHz in Turku from scan queue
2017-05-26 00:21:15.506 [  DEBUG]:mpegts: removing mux 514MHz in Turku from scan queue
2017-05-26 00:21:15.506 [  DEBUG]:mpegts: removing mux 674MHz in Turku from scan queue
2017-05-26 00:21:15.506 [  DEBUG]:mpegts: removing mux 562MHz in Turku from scan queue
2017-05-26 00:22:14.364 [  DEBUG]:mpegts: adding mux 514MHz in Turku to scan queue weight 6 flags 4000
2017-05-26 00:22:14.364 [  DEBUG]:mpegts: adding mux 674MHz in Turku to scan queue weight 6 flags 4000
2017-05-26 00:22:14.364 [  DEBUG]:mpegts: adding mux 562MHz in Turku to scan queue weight 6 flags 4000
2017-05-26 00:22:19.885 [  DEBUG]:mpegts: removing mux 674MHz in Turku from scan queue
2017-05-26 00:22:19.885 [  DEBUG]:mpegts: removing mux 514MHz in Turku from scan queue
2017-05-26 00:22:25.357 [  DEBUG]:mpegts: removing mux 562MHz in Turku from scan queue

This is your fault. Enable "init scan" for at least one tuner. The discovered muxes are added with the init flag not with the force user flag.

Jaroslav Kysela wrote:

This is your fault. Enable "init scan" for at least one tuner. The discovered muxes are added with the init flag not with the force user flag.

Hi Jaroslav,

Thank you for all the help and you are right, it scans when I enable initial scan in dvb settings. But I think this feature is somewhat confusing and difficult to understand what it does. I might be wrong, but I will try to explain my reasoning and well you get some free user input, no need to agree... Tvheadend is great and I think you are doing a great job solving these bug reports. I have enjoyed sending debugging info and helping tvheadend become better.

In DVB settings help it says "Allow the initial scan tuning on this device (scan when Tvheadend starts). See 'Skip Initial Scan' in the network settings for further details." and in network settings it says "Skip scanning known muxes when Tvheadend starts. If "initial scan" is allowed and new muxes are found then they will still be scanned. See Help for more details."

In reality now I understood that in DVB settings 'Initial scan' means:
1- It will scan known muxes in attached networks if 'skip initial scan' is not selected in network settings
2- It will allow scan of new muxes automatically if they are discovered at any point. If this option is not selected, new muxes will be stuck at PEND state.

In network settings 'Skip initial scan' means:
1- Do not scan known muxes at startup.
2- This does NOT effect initial scan of new muxes. That is controlled by DVB initial scan setting. (confusing or what?)

In my opinion these options should not have the same name. In network options it should be renamed to 'Skip startup scan' because it is what it simply does.

I can't really understand why DVB settings need initial scan option. Because you would either want to allow DVB input for scans or do not allow at all. Maybe that particular DVB hardware has a scanning problem. OK I would want to disable scans completely on it. But I can't do it... because even if initial scan is disabled for a DVB input, I can set the mux 'active' manually and that DVB input may be used for scanning. So what is the purpose of not allowing/disallowing a particular dvb input only for initial/startup scan? In DVB settings the option should be something like 'Allow scan'. Startup scans should be only controlled from network settings.

I don't know if my reasoning is incorrect but I think:
1- I would want either to use dvb input for scans or NOT use.
2- I would want either to scan a network at startup or NOT scan.
So one clear option for dvb input settings and one clear option for network settings.

Furthermore, if DVB initial scan is not allowed, but in network settings 'skip initial scan' is not selected, then tvheadend puts all muxes to PEND at startup but can't scan them. (I can see how this could be confusing for users). There should be perhaps a message saying 'no available adapters for scan' or something in that line. It is difficult to tell why muxes are sometimes in PEND state and sometimes they change to ACTIVE automatically.

Thank you!

I test last code and problem with "PEND" is fixed here, but will be good when add new mux automatically change to "ACTIVE" ,not to "PEND" how is now and manually to set to "ACTIVE", because when i add new mux i want to scan. This is slow when i add 5 muxes and after that one by one to go to set manually "ACTIVE".

Petar Ivanov wrote:

I test last code and problem with "PEND" is fixed here, but will be good when add new mux automatically change to "ACTIVE" ,not to "PEND" how is now and manually to set to "ACTIVE", because when i add new mux i want to scan. This is slow when i add 5 muxes and after that one by one to go to set manually "ACTIVE".

You need to go to DVB settings and enable 'Initial scan' option. That was what I was missing also. I tried to explain it in my previous reply, seemingly unrelated option is causing that.

I added these texts based on suggestions: https://tvheadend.org/projects/tvheadend/repository/revisions/17996c35a5e2d92af3f65c204ee7e66a5501ede5/diff/

I can't really understand why DVB settings need initial scan option. Because you would either want to allow DVB input for scans or do not allow at all. Maybe that particular DVB hardware has a scanning problem. OK I would want to disable scans completely on it. But I can't do it... because even if initial scan is disabled for a DVB input, I can set the mux 'active' manually and that DVB input may be used for scanning. So what is the purpose of not allowing/disallowing a particular dvb input only for initial/startup scan? In DVB settings the option should be something like 'Allow scan'. Startup scans should be only controlled from network settings.

These "limiters" were added mostly for setups where your have 8 or more tuners and the scanning might use a lot of CPU, so it would be good to reduce the tuners which are doing the scan task. Anyway, users should keep the defaults in normal configs.

Jaroslav Kysela wrote:

These "limiters" were added mostly for setups where your have 8 or more tuners and the scanning might use a lot of CPU, so it would be good to reduce the tuners which are doing the scan task. Anyway, users should keep the defaults in normal configs.

Yes, but I had to modify that because it kept finding muxes and getting stuck due to the bug. Also, this is not the best solution to CPU load problem. I can go to muxes and set 8+ muxes ACTIVE and all the cards would be used regardless of the setting. The best solution would be a limit on maximum simultaneous scan processes. You could have a general setting 'Maximum allowed simultaneous network/mux scans = X'

What you may also want is a setting to enable/disable possibility of scanning on a specific card. Like an on/off switch. It would be a more clear, easy to understand feature. If this feature is even needed (I dont know?). This would be useful if scanning is broken on a specific card/driver.

At the very least, please update the help text for 'DVB Initial scan' to include 'Automatic scans from PEND state will not be performed if none of the adapters assigned to a network has initial scan option enabled.' This way users can know that it also causes this being stuck at PEND state problem.

Anyway, thank you for your time.

Evren Yurtesen wrote:

Jaroslav Kysela wrote:

These "limiters" were added mostly for setups where your have 8 or more tuners and the scanning might use a lot of CPU, so it would be good to reduce the tuners which are doing the scan task. Anyway, users should keep the defaults in normal configs.

Yes, but I had to modify that because it kept finding muxes and getting stuck due to the bug.

The default settings is to allow all type of scanning on all tuners. So you modified the settings to one which resulted with 'no available tuners' for the operation. I don't plan to add any other modifications for this issue. This settings is marked as advanced, so users should know what they're doing.

Jaroslav Kysela wrote:

Evren Yurtesen wrote:

Jaroslav Kysela wrote:

These "limiters" were added mostly for setups where your have 8 or more tuners and the scanning might use a lot of CPU, so it would be good to reduce the tuners which are doing the scan task. Anyway, users should keep the defaults in normal configs.

Yes, but I had to modify that because it kept finding muxes and getting stuck due to the bug.

The default settings is to allow all type of scanning on all tuners. So you modified the settings to one which resulted with 'no available tuners' for the operation. I don't plan to add any other modifications for this issue. This settings is marked as advanced, so users should know what they're doing.

You could at least make the help entry more clear by adding 'Automatic scans from PEND state will not be performed if none of the dvb adapters assigned to a network has initial scan option enabled.' This was not clear to me by reading the help.