level indicator range

[deeptho]

SYS_AUTO means that the user wants blindscan. This is the only way to enter that information into a mux. So I have not used to changes, because it would reduce functionality.

Level indicator: I do not think the fix is the correct one as it forces this range (which is excessive to most users). A better solution is to leave the bars at maximum, but change the text value

[psyborg55]

Can't understand why some information needs to be entered into mux. I'd expect tune_options.use_blind_tune is already enough to enable blindscan. I have it working on m88ds3103 cards and can use SYS_AUTO in both blind (entered wrong symrate, it tuned to correct one) and normal (tunes any of the DVBS,DVBS2QPSK,DVS28PSK as long as symrate is correct) mode. But with double blind condition check as currently it is, trying to use SYS_AUTO in normal mode always forces blind mode

Signal level range montage specify -92 to -10dbm for their tuners, probably other vendors are similar. SNR with 1.1m dish on strongest 5w transponder can reach 22db, and if some user with 1.8m dish tries it he'll get close to 30

[deeptho]

Can't understand why some information needs to be entered into mux. That is a gui thing: If you want to scan a mux, you add it there. If you want blindscan you set the system to 'SYS_AUTO'. Any subsequent muxes are found from SI information, but it is better not to use blindscan for those. Or at least you should have the option.

I think what you expect (which is also valid) is that in that case, SYS_AUTO woukd perform a blind-tune (specify frequency, and perhaps even symbol rate but nothing else) instead of a blindscan (which has more freedom to change frequency)

have it working on m88ds3103 cards and can use SYS_AUTO in both blind (entered wrong symrate, it tuned to correct one) and > normal (tunes any of the DVBS,DVBS2QPSK,DVS28PSK as long as symrate is correct) mode.

Yes, but what does it mean then? It means "use blindscan but with known frequency". I would call this blind-tune, which is a separate feature from blindscan (blindtune is a special case).

But with double blind condition check as currently it is, trying to use SYS_AUTO in normal mode always forces blind mode

I think what you are really asking for is some more fine-grained subset of blindscan methods, because SYS_AUTO as you want it is probably a blind-tune, whereas the implementation turns it into a blindscan. But remember, there is also the GUI and database issue: it should be possible to set this per mux, especially as the issue is only relevant for manually entered muxes.

A blindtune feature is certainly useful, as blind-tune may be supported even if blindscan is not (e.g., before blindscan was supported in the driver).

So to summarize: my "design" is: SYS_AUTO is a flag for "I want blind SCAN on this mux" (used from the muxes screen) but indeed it could be useful in some cases to turn that into "I want blind TUNE on this mux". I also seem to remember that in some cases you want to override data from the driver or from SI. Again that coulkd be useful, but it is a lot of complexity added. There are of course good reasons why this would be needed. E.g., greke channels report that they are encrypted but they really are not. Sometimes wrong frequencies and polarisations are reported. Data from the drivers contains errors etc....

Signal level range montage specify -92 to -10dbm for their tuners, probably other vendors are similar. I think signal levels are meaningless in general except when compared relatively. The definition I use is: the physical voltage entering the RF connector. Usweful values are in the range -80 to -40.

SNR with 1.1m dish on strongest 5w transponder can reach 22db, and if some user with 1.8m dish tries it he'll get close to 30

That is true, but even then the graphical indication is only relevant for weaker signals. It is of course always useful to see the correct value numerically. It could also become a per user config. option.

[psyborg55]

Can't understand why some information needs to be entered into mux. That is a gui thing: If you want to scan a mux, you add it there. If you want blindscan you set the system to 'SYS_AUTO'. Any subsequent muxes are found from SI information, but it is better not to use blindscan for those. Or at least you should have the option.

I think what you expect (which is also valid) is that in that case, SYS_AUTO woukd perform a blind-tune (specify frequency, and perhaps even symbol rate but nothing else) instead of a blindscan (which has more freedom to change frequency)

have it working on m88ds3103 cards and can use SYS_AUTO in both blind (entered wrong symrate, it tuned to correct one) and > normal (tunes any of the DVBS,DVBS2QPSK,DVS28PSK as long as symrate is correct) mode.

Yes, but what does it mean then? It means "use blindscan but with known frequency". I would call this blind-tune, which is a separate feature from blindscan (blindtune is a special case).

No no. I see what differenceis there between blindscan and blindtune. Blindtune will do a single frequency while blindscan goes through entire spectrum. SYS_AUTO in my case is about something else when neither blindtune or blindscan are used. It does the most simple thing just as windows drivers in altdvb do. Set some frequency and symrate (both known) but, let's say you got this info from a lyngsat on your phone, you didn't remember if it's DVBS or DVBS2, to not go open the page on the phone again, just set SYS_AUTO, the driver tries both and tunes to the correct one. No blind methods involved in this case

But with double blind condition check as currently it is, trying to use SYS_AUTO in normal mode always forces blind mode

I think what you are really asking for is some more fine-grained subset of blindscan methods, because SYS_AUTO as you want it is probably a blind-tune, whereas the implementation turns it into a blindscan. But remember, there is also the GUI and database issue: it should be possible to set this per mux, especially as the issue is only relevant for manually entered muxes.

A blindtune feature is certainly useful, as blind-tune may be supported even if blindscan is not (e.g., before blindscan was supported in the driver).

So to summarize: my "design" is: SYS_AUTO is a flag for "I want blind SCAN on this mux" (used from the muxes screen) but indeed it could be useful in some cases to turn that into "I want blind TUNE on this mux". Both of these seem the same to me, if by blind scan you refer to "blindscan all" button in spectrum dialog. Both blindscan and blindtune lock the transponder and then obtain NIT and other pids. Is just blindscan does automatically peaks in spectrum, while blindtune expects manually clicking on each peak and hitting tune button. Why the two methods make a difference for you? Perhaps the blind scan shouldn't do any tuning/data aqusition from transponder but only detect correct symbol rate? If so, in my case it still does it all.. Anyway ,the flag being set by selecting blind button is enough here to do both without involving sys auto as a blind mode parameter

[deeptho]

Your description of SYS_AUTO in windows sounds similar (but not equal) to what I called blind_tune: "specify frequency, and perhaps even symbol rate but nothing else".

The point is that all variations are possible, but the only one that would matter is to be able to choose whether or not the prevent changes to frequency and symbol rate. It could be useful, but it would involve quite a bit of effort to handle all cards correctly, for little gain: you might as well blindscan if you forgot what was on lyngsat.

[psyborg55]

Yes, you right here, might just blindscan it, or try manually one system then another. It can happen blindscan is broken temporarily, and we have s2x support too. That's already 3 types to manually try.

Then it could be we're using another app that has no blindscan feature, e.g tvheadend, and trying both types manually in that one is already a nightmare, especially on small touchscreen devices.

So, the solution that seemed the best was to just follow vendor driver implementation.

[deeptho]

For the tvheadend case I once implemented an "always_blindscan" kernel module option. The trouble with tvheadend is that often it fails to recognize that muxes are the same despite small differences. So it is a bit of a mess. Blindscan would probably make that worse. I still use tvheadend every day despite all the problems.