neumoDVB

[Llew]

Llew,
I just scanned 28.2E with 6909x (not 6903x because that is currently not in my computer). No problems. All works fine.
Could be the patch I made yesterday which is a case of memory corruption. For me that lead to crashes (but not always!) withoyt any
error message, but I found the cause (related to the new list of services that is now shown).

I will release it within the next hour. A simple test is to see if the new code fixes your problem (probably not).

OK deeptho. Thanks. I'll pull any change you make and check tomorrow. Will report back if anything different.

I'm testing on my main PC with Ubuntu 20.2 kernel 5.15.0-48.

I have it also on a Raspberry Pi 4, Ubuntu 22.04 kernel 5.15.0-1022, which I shall check later too to see if it has a similar problem.

 

[Llew]

The error message is a new one for me. A bit strange, because 28.2E is one I test regularly. The crash might be related to the bug I fixed yesterday or perhaps not (error message is different). I will upload that code todat.

It might help to get a copy of your databases, mainly the files in ~/neumo/db/chdb.mdb to see if there is something in there that can reproduce the problem.

If you can manage, you could also try and run neumodvb under gdb and then capture a backtrace. It is explained somewhere in the documentation.
Or you can provide me temporary access on your compyter with a teamviewer session or something similar.

Blindscanning is still causing a crash deeptho, with the same terminal output as before.

If it's any help, maybe you can find something in my mdb files?

I think using gdb is somewhat over my head. If all else fails, teamviewer might be worth a shot.

An uneducated guess - dependency difference between Fedora (yours) and Ubuntu (ours) causing the problem?

 

[deeptho]

Llew,
I found the problem. It happens only in specific cases: when the database is empty and then also scan 28.2E.

It should be fixed now.

 

[Llew]

Llew,
I found the problem. It happens only in specific cases: when the database is empty and then also scan 28.2E.

It should be fixed now.

Fine now deeptho. Thanks.

Did a full and part blindscan of 28.2E. Both completed without issues

The part scan shown here.

 

[deeptho]

Todat I found and tested a t2mi stream which is part of a multis-stream 12668H on 5.0W.
It has 20mediasat and focustv, both without audio (and so displayed as static images
as neumoDVB syncrhonises on the audi) and a "test HEVC Main10" channel
which has choppy audio, which is due to the code in neumoDVB that tries to extract timestamps
and which does not work well on this stream. neumoDVB does seem to save the stream properly

 

[deeptho]

Today was a good day for me to test if the trees in the garden block satellite reception, as it is "solar outage period".
So I took some pictures of the trees, checking the location of the sun. The tree partially blocking 39.0E was already
cut down and all was well, although in a few years time some other trees will start blocking it as they grow.

52E was partially blocked by a smaller tree.

At the same time, I also used neumoDVB to see what happens during solar outage. And indeed, the SNR dropped by the predicted amount (3.9dB ) at the predicted time (08:33 UTC)

 

[deeptho]

neumodvb-1.2 has been released.

Most important changes​

• Internal processing of SI data has been simplified, removing many exceptions while still correcting for incorrect data in muxes with bad SI data.
• Several bugs were fixed causing blindscan or mux scan to never end.
• During scanning, discovered services are now shown in positioner and spectrum dialog.
• Support for wxpython4.2.

SI processing and blind scanning improvements​

• Various bug fixes causing blindscan to never end (but some more remain).
• Correct handling of multistreams during scan.
• Bug: in by_mux_fuzzy_helper returns wrong mux, causing updates to be applied to the wrong mux.
• t2mi muxes sometimes incorrectly updated after scan.
• set t2mi_pid to zero before blind scanning, so that not only the t2mi mux is canned but also its parent mux.
• Add T2MI media type while scanning PMT.
• Ensure sdt data shown during spectrum scan corresponds to nit info.
• Bug: deadlock while saving services.
• Do not trust tuning information from muxes except from nit_actual and from driver.
• Bug: sometimes services missing in service list in positioner and spectrum dialog.
• Pick proper ts_id when NIT and SDT are absent.
• Avoid creating services with incorrect mux_key which can then not be tuned.
• Make frequency estimate robust against incorrect tone status returned from driver.
• Avoid creating muxes which differ only in extra_id on same frequency.
• Simplification of mux scanning code: Always give preference to sdt version if ts_id and network_id, even if mux reports other (incorrect) data. If there is no SDT, prefer setting these values from NIT, and if there is no (valid) NIT, use the value of ts_id in PAT. Also ensure that all of this works irrespective of the other in which NIT and SDT are received and handle timeouts when they not exist.

Handling of various muxes which broadcast incorrect SI data​

• Incorrect detection of t2mi on 30.0W 11382H, which does not have t2mi data.
• 39.0E 10930V stream 1 reports 30E as satellite position in the NIT actual table. This causes NIT_ACTUAL to be ignored, resulting in no useful nit data. On the other hand, there is no SDT table. Now, pat data is used in this case.
• 14.0W. Incorrect modulation parameters belarus24hd.

Bugs related to changing LNB settings​

• Incorrect estimation of current satellite positions on offset LNBs.
• usals_pos not correctly set when entering sat_pos in network.
• Incorrect computation of cur_sat_pos.
• Offset angle for offset LNBS incorrectly estimated or not recomputed.
• Bug: lnb_cur_sat_pos messed up when closing lnb network dialog.
• Ensure that usals_pos and sat_pos are both initialized in network_list if either one is set. This also solves a bug when clicking "sort" on uninitialized usals_pos or sat_pos column.
• Ensure that spectrum acquisition always uses the most recent usals_pos if this has been changed from positioner_dialog.
• Update positioner and spectrum dialog title after changing sat; include card in title.
• Network and connection combo not updated after selecting lnb in positioner or spectrum dialog.
• Reference mux not saved when set.
• Usals type cannot be changed from positioner and change is not immediately visible in lnblist.
• Usals pos not correctly set in positioner dialog.

Support for wxpython4.2​

• Detect wxpython version and remove workarounds needed un older versions of wxpython when wxpython4.2 is detected.
• Bug: incorrect font size in grids vin wxpython4.2.
• Bug: excessive row spacing in live screen in wxpython4.2. *Bug: Excessive size of bar gauges in wxpython4.2.
• Bug: incorrect size of comboxes in wxpython4.2.
• Bug; Togglebuttons have different size than regular buttons in newer OSes.

Other GUI related changes​

• Show list of services in postioner and spectrum dialogs.
• Improved selection of mux on tune mux panel if no reference mux is set: specifically select a tunable default frequency and polarisation.
• Bug: subtitles on arte confused by mpv with teletext. The solution is to not save teletext information in the stream as neumoDVB does not implement teletext anyway.
• Signal history: improved date formatting; Show signalhistory_plot in local time.
• Improved formatting of status_list.
• The speak function now also speaks "not locked" when appropriate.
• Improved sort default sort order for time columns.
• In DVBS mux list, indicate more clearly where network and ts ids were found, by introducing key_src.
• spectrum_plot: allow a range of no more than 30dB range in initial spectrum plot.
• Indicate initially sorted column in GUI using triangle. The old code sorted properly but did not indicate graphically which column was sorted.
• When filtering a column, avoid some needless clicks and mouse movements: in the popup window immediately. focus the new filter cell, without user having to click the cell. Also allow the filter dialog to close by just pressing ENTER.
• Bug: filter not updated after its value has been edited.
• Move lock indicator to more logical position, i.e., in front of transport stream specific lock indicators.
• Pick proper default polarisation for draw_mux (circular versus linear).
• Bug ShowOkCancel not imported resulting in python exception.
• Display unknown matype as blank.
• Bug: incorrect string value for Ka LNB subtype.
• Bug: In the status list screen, not only live muxes are shown but also previously tuned ones.

Various bugs causing crashes or incorrect data​

• For LNBs with One band, set freq_mid to freq_high in all cases.
• Bug: si_state returns erroneous value of timedout.
• Bug: si_state check erroneously returns duplicated instead of completed for single section, potentially resulting in lost SI data.
• Bug: when a table times out, it still must be processed because some code in active_si_stream relies on knowing ts_id.
• Bug: scan_status_t::RETRY status should also be cleared at startup.
• Avoid assertion when lock is lost after init_si has been called.
• Bug: incorrect looping over frequencies.
• Bug: crash due to accessing record of different type when looping over cursor range due to key_prefix not being set.
• Bug: database mux sometimes deleted when not overwritten.
• Bug: memory corruption due to not unregistering subscriber properly.
• Bug: Do not rely on voltage and tone retrieved from driver, because. for slave connections, these values are not even set in the driver.
• Prevent events being queued on window after it is destroyed.
• Bug: incorrect matching of rf_path causing wrong tuner to be used.
• Bug: PENDING status set on multistream while not scanning.
• Bug: incorrect usage of find_by_key like functions in conjunction with find_geq because default fields lead to incorrect lower bound.
• Introduce sat_pos_tolerance. Muxes on satellites less than 1 degree apart are now treated correctly when SI data is received.
• Workaround for false positive at start when using sanitized, causing a crash at startup
• Add Sanitize compilation option, disabling it by default

 

[satesco]

I updated neumodvb to v.1.2. 6903x card tests
I encountered two problems/errors: 1; after I chose a new lnb and set the satellite to the Usals positioner,neumodvb crashed every time. 2. On reboot, the card deactivates, so I have to restart the computer, as shown in the picture. Only in this way can I use 6903x.
I hope the attached files help.

 

[deeptho]

Satesco,
One of the problems shown in your screenshot is unrelated to what you mention. I have fixed it already

Number 1 and must be related to something specific about your setup. I sent you a PM.

 

[deeptho]

So the remaining problems were an unusual lnb configuration (fix still to be uploaded) and not having the latest
drivers installed.

 

[satesco]

I found a bug at 5.0W, which manifests at 12725 H,30000,3/4. This mux is at 4.0W, in the lower band, on 11175 H,30000,3/4, Ukrainian provider.
I know the signal on Amos 3 is very strong in my area, which could explain its presence at 5.0W. But why it appears in the upper band at 5.0W?
I can only explain this by the presence of a bug in neumoDVB,1.2. But I must add that the same bug is present in the previous version,1.1.
I should also add that I found this bug with Crazyscan under Windows on the 6903x card.
No bug or error with the 6902se card at 5.0W.

 

[deeptho]

Satesco,
what is the bug? The signal has been received. It is not possible to know where it comes from as the mux does not include that information.
So there is no way to know,

 

[satesco]

How do you define that a transponder from 11175 H from 4.0W appears on the upper band on 12725 H at 5.0W, especially when it comes from another position? Then how do you diagnose such a situation?
I'm interested in explaining why such a mux would appear on the spectrum where it shouldn't be. Why does the same problem occur with Crazyscan under Windows with the same 6903x card?
I'm not necessarily referring to the word "bug" but to an explanation. I don't mind that this happens, especially since neumoDVB works.
I thought that people like you and CrazyCat who develop drivers are interested when such phenomena occur.
Or is it a false alarm?

 

[satesco]

I did a test again at 5.0W in the upper band. The same situation remains, with 12725 H,30000,3/4 on the spectrum.

 

[deeptho]

How do you define that a transponder from 11175 H from 4.0W appears on the upper band on 12725 H at 5.0W, especially when it comes from another position? Then how do you diagnose such a situation?
I'm interested in explaining why such a mux would appear on the spectrum where it shouldn't be. Why does the same problem occur with Crazyscan under Windows with the same 6903x card?
I'm not necessarily referring to the word "bug" but to an explanation. I don't mind that this happens, especially since neumoDVB works.
I thought that people like you and CrazyCat who develop drivers are interested when such phenomena occur.
Or is it a false alarm?.

This must be related to your dish. I also pickup signals from 4W on 5W, but my dish is smaller. You should see the signal grow stronger
if you move the dish closer to 4.0W.
neumoDVB finds the satellite position from the NIT_ACTUAL table, but can only do that if there is such a table.

 

[satesco]

I probably didn't express myself correctly. The problem is not that the signal on 12725 H at 5.0W is coming from 4.0W. It's normal that it should be so considering that it is stronger at 4.0W than at 5.0W, which at the distance of only one degree between the two satellites, was and is a problem affecting reception at one of the positions.
So it's not the signal that is the problem (sorry to repeat me), but why a frequency at the bottom of the band is found at the upper band?
In short,11175 H =12725 H? That the signal is from another position is not important for my question, but how do the 6903s/6909x cards find a mux that should not be there? No others dvb card detected the 12725 H mux at 5.0W.
The most convincing way to explain what I mean is to illustrate graphically how the same mux-11175 H appears on the spectrum at 5.0W, which then appears on the upper-band spectrum with the same parameters.
I did the signal test at 5.0W with Crazyscan under Windows with the 6909x,6983,usb5927 cards. Same result as on Linux.
At the risk of loading even the thread with pictures, I will post the tests done on both systems at 5.0W.
After your intervention, I'll refrain from saying "bug" what happens with 12725 H at 5.0W, either at the driver or at the demodulator. But, as you can see, only cards with the chip stid135 show such, how to say, anomalies?
I will also post the tests with 6909x and other cards(6983,5927, and 6902se on Ubuntu) at 5.0W on Windows. Who knows, maybe it can help me find out if the problem comes from the receiving system or the demodulator.

 

[Llew]

Can't really help with this one satesco. Sometimes Amos 3 comes in better later in the day, but it won't give me the same results as you, as 5W normally swamps it.

I'm on 4W, with 11140H barely registering. There's a showing of 12730H at the top end., wherever that's coming from.

 

[satesco]

Thanks, @Llew, for wanting to check the signal on those two nearby satellites. But your area is outside Amos3's footprint, and if you also use a smaller antenna, your result may not be conclusive.
The first Amos 1 and 2, when they became operational in the 2000s, had such a strong signal that it disturbed reception of some frequencies at 5.0W, and vice versa, from Eutelsat 5 West (before Atlantic Bird 5). With offset antennas, this signal couldn't be fully discriminated. Those with smaller antennas had reception problems anyway because of the strong signal at the two positions. Even with big antennas, as I have, I had to move my antenna from the focus from 4.0W a little further east.
Here is the explanation although I have a big (symmetrical) antenna for the Amos 3 spot Europa, and so I would have a chance to separate the signal at these close positions, with the 1.50m antenna, I get a pretty good signal at the 5.0W position.
But that's not my problem with the signal, but how the 6903x/6909x cards are "capable" (quotation marks required) of receiving the same signal on two different frequencies.
That's the question I'm asking @Deeptho, and if @CrazyCat reads this topic, all the better because this phenomenon manifests itself with the stid135 chip on both operating systems. And I think only these two brilliant developers can find an explanation, but more importantly, fix this problem.
I discovered the same thing a few years ago at 90.0E, when I first used Crazyscan, then adapted for 6903x/6909x cards. In the meantime, after countless Crazyscan updates, I never noticed one of the frequencies repeating. But, as already known, the stid135 chip is still, even for developers, a permanent challenge. Each satellite has its peculiarities through its transponders, so it's no wonder they must update their applications according to the bugs they discover.
Probably other users could check the situation I described if they meet the same reception conditions, as signal and the same card used. And I would be happy for such verification to confirm or refute the allegations and evidence I have brought forward.
Regards

 

[deeptho]

@satesco So that is what you mean. I could not have guessed.
Anyway: 12725.290 - 11175.22 = 1550.07 which almost exactly equals the local oscillator frequency of the stid135 chip

When tuning to the high band, what happens is that the very string 11175 comes into the card
at a frequency of 11175.22- 10600 = 575.22 Mhz (use tbs5927 or tbs603 to verify)

Internally the card tunes around the center frequency of 1550 with a bandwidth of about 1200 Mhz.
So between 950Mhz and 2150 Mhz. However, the bandpass filter is not perfect, and any incoming frequency
f below 950Mhz that is not sufficiently attenuated will also appear at f+1550 Mhz.


For f=575.22 Mhz, the aliased value equals 2125.25 Mhz

On the other hand, if a real signal appears at 12725.290H then the frequency received by the chip
equals 12725.29 - 10600 = 2125.29 Mhz, which is almost exactly the same


Also, if the LNB suppress signals outside its designed band, like 575.22 Mhz, then this problem would also not
exist. So you could also blame the lnb.

Try the following experiment: reduce the signal coming into the card using an attenuator, At some point the 12725.29
will disappear into the noise. You can of course also put a wet cloth on the lnb, which will also reduce the signal.

Other cards do not have this problem as they tune to a much narrowerd band (e.g., 60Mhz bandwidth instead of 1.2Ghz)

 

[deeptho]

Satesco,

I have an easy fix for your problem: we can exchange dishes. You get a smaller one and me a bigger. We can both be very
happy with such a solution.