neumoDVB

[Llew]

But I'm glad we're united in trying to use neumoDVB. I hope we're not the only ones using it.

If we're not , the silence here is deafening

 

[deeptho]

With today's update (#de61b60 ), I managed to scan all the cable muxes, but before that, I deleted all of them and, simultaneously, the Services. So it worked. Thanks, @deeptho
For the terrestrial reception configuration, I admit I was annoyed, and it took me a long time to find the solution to lock the signal and scan the terrestrial services for the 6590 C/T card. Compared to my first experience with terrestrial reception with neumoDVB, last August, with this version, I had to choose 1 for priority, for the card and the standard (terrestrial) to work and show my subscription.
I don't remember than having to give priority 1 to the adapter for terrestrial.

@Llew,
Our settings differ because, in our country, they switched directly to the Dvb-T2 standard while you still keep Dvb-T.
But I'm glad we're united in trying to use neumoDVB. I hope we're not the only ones using it.

Satesco: you had or have multiple adapters which can each receive DVBC and DVBT. There is no way for neumoDVB to figure out on its own which of the cards has a cable connected, and which it is (DVBC or DVBT) except by configuring it. You have to do this by (de)activating in the config the proper choices.

And regarding the duplicate muxes: they should not have happened of course, but the underlying cause is the complexity of what is transmitted on satellite , cable .... In too many cases wrong information is transmitted, or essential information is omitted, so it is is not easy to avoid dupicate muxes (as users of tvheadend well know). As a result, the code is complicated, and a small change can lead to big consequences especially for the parts that are not well tested.

That is where you come in: you find the bugs for me :->

 

[Llew]

@deeptho

Is it possible to number channels en bloc instead of individually (time consuming)?

For instance, in my case, give all DVB-T2 channels one number, all 16E channels a different number etc.?

(perhaps we can, and I've not found a way yet).

 

[satesco]

Deeptho:
I agree with you entirely about the problems you are experiencing with your application. And all the more deserving is your success as you want neumoDVB to perfectly cover all transmission standards, each with different and complex parameters, all of which are a first in the world of dvb cards under Linux.
In this respect, if I may say something friendly, somehow this project of yours, although successful, does not satisfy you completely, not only because of bugs, but also, I hope I am not wrong because you want to make it perfect with defective hardware (I mean the demodulator and other hardware components).
A developer goes through mental/intellectual torment when solving a software problem related to the physical part of the cards. It's a continuous alert for him, with no periods of respite and quiet.
For my part, hats off to what you do and what you propose to do next, achievable or not.
More for accuracy, on the list of cards that appear there, only tbs6590 is also for Cable/Terrestrial standard.

 

[deeptho]

@deeptho

Is it possible to number channels en bloc instead of individually (time consuming)?

For instance, in my case, give all DVB-T2 channels one number, all 16E channels a different number etc.?

(perhaps we can, and I've not found a way yet).

No that is currently not possible.

 

[deeptho]

Deeptho:
I agree with you entirely about the problems you are experiencing with your application. And all the more deserving is your success as you want neumoDVB to perfectly cover all transmission standards, each with different and complex parameters, all of which are a first in the world of dvb cards under Linux.
In this respect, if I may say something friendly, somehow this project of yours, although successful, does not satisfy you completely, not only because of bugs, but also, I hope I am not wrong because you want to make it perfect with defective hardware (I mean the demodulator and other hardware components).
A developer goes through mental/intellectual torment when solving a software problem related to the physical part of the cards. It's a continuous alert for him, with no periods of respite and quiet.
For my part, hats off to what you do and what you propose to do next, achievable or not.
More for accuracy, on the list of cards that appear there, only tbs6590 is also for Cable/Terrestrial standard.

You make it sound like I need a drink :->

 

[satesco]

Back to 26.0E with a neumoDVB version 1.2 test after switching to the lnb setting before the dvb cards (v.1.1). I tried scanning Amateur Radio on 10491 H,1500,4/5 at 26.0E with the lnb set to 10.5 GHz, as the documentation states. This lnb setting does not work on muxes between 10490-10499 H. The only way to lock these muxes is with lnb 9.75 GHz at LOF Low, setting the scan limits between 10470-11200 H or narrowing the search band even more.
My first test was with the 5927 tuner, also recommended for these low sub-band muxes. I also had no problems locking Mux with a symbol rate of 333.
I also tested the 6983 card with the same lnb configuration for Amateur Radio reception. This time I also had no problems locking some frequencies.
With the 6903x card, I managed to do a normal scan of these muxes, getting a normal spectrum.
The problem was only when I scanned it manually, it gave me a parameter error, i.e., instead of the 10491 H frequency, it scanned 12040 H, although the other 10490 H parameters were preserved (sr & FEC).
I would like to know if another valid setting exists for the lnb so that I can scan and lock these Amateur Radio muxes.
Or even better, how is it correct to set LOF Low, freq min, freq max, etc.?

 

[satesco]

A video sample of Amateur Radio activity (from Germany) taken directly with neumoDVB from 26.0E on mux 10497 H,333,2/3.
I used the 6983 card to lock and record.

 

[Llew]

Where are video/audio recordings stored in neumodvb? A .ts file presumably. Most tuner apps give you a choice, e.g /home/videos or whatever.

(Not my preferred choice, just testing).

 

[satesco]

The recorded files are in the recordings folder in neumo folder.
I recorded the posted file with SimpleSimpleRecorder.
I've never tried using this function before, but now that you've reminded me when I tried to make a recording, neumoDVB crashed.
I followed the instructions in the neumoDVB documentation.

 

[Llew]

The recorded files are in the recordings folder in neumo folder.
I recorded the posted file with SimpleSimpleRecorder.
I've never tried using this function before, but now that you've reminded me when I tried to make a recording, neumoDVB crashed.
I followed the instructions in the neumoDVB documentation.

I've obviously recorded the TV programme as it shows as finished, but Control/Play doesn't do anything.

 

[satesco]

As I told you, I haven't used this function, so I don't know what to recommend.
But I ask you, have you searched the "neumo" folder in Home (separate from neumoDVB ), the "recordings" folder? That's where you should find the recordings you made.

 

[Llew]

As I told you, I haven't used this function, so I don't know what to recommend.
But I ask you, have you searched the "neumo" folder in Home (separate from neumoDVB ), the "recordings" folder? That's where you should find the recordings you made.

Yes, that's the first place I went to, but the file in neumo/live has just a blank screen. neumo/recordings has just a .mdb folder.

@deeptho

As per my query, I can't play a recording - does this tell you what's amiss? :-

 

[deeptho]

Back to 26.0E with a neumoDVB version 1.2 test after switching to the lnb setting before the dvb cards (v.1.1). I tried scanning Amateur Radio on 10491 H,1500,4/5 at 26.0E with the lnb set to 10.5 GHz, as the documentation states. This lnb setting does not work on muxes between 10490-10499 H. The only way to lock these muxes is with lnb 9.75 GHz at LOF Low, setting the scan limits between 10470-11200 H or narrowing the search band even more.

"Setting the LNB to 10.5Gz" is not mentioned in the documentation, which mentions setting freq_min to that value.
That will only work if the card supports it. 6903x does not.

The LOF value should be set to the correct one for the LNB, which is indeed probably 9.75GHz if it is a Universal LNB.
The value -1 is also fine. It then picks that default.

So in summary: all of this works correctly for you (except for the impossible parts)

My first test was with the 5927 tuner, also recommended for these low sub-band muxes. I also had no problems locking Mux with a symbol rate of 333.
I also tested the 6983 card with the same lnb configuration for Amateur Radio reception. This time I also had no problems locking some frequencies.
With the 6903x card, I managed to do a normal scan of these muxes, getting a normal spectrum.
The problem was only when I scanned it manually, it gave me a parameter error, i.e., instead of the 10491 H frequency, it scanned 12040 H, although the other 10490 H parameters were preserved (sr & FEC).

Difficult to comment without any further information.

I would like to know if another valid setting exists for the lnb so that I can scan and lock these Amateur Radio muxes.
Or even better, how is it correct to set LOF Low, freq min, freq max, etc.?

Well, it is exactly as the documentation states, with possibly one exception: the lowest and highest frequency that can
be tuned to are not only determined by the lnb but also by the card. So not all values will work. The only limit that is internally
checked is the one for the card. The other limits (for the lnb) you have to set yourself. The LOF value needs to be the correct one
as written on the LNB.

 

[deeptho]

Where are video/audio recordings stored in neumodvb? A .ts file presumably. Most tuner apps give you a choice, e.g /home/videos or whatever.

(Not my preferred choice, just testing).

It is explained in the documentation, in the section troubleshooting.

 

[Llew]

It is explained in the documentation, in the section troubleshooting.

As I understand it, according to neumo.log the file should be in neumo/live as A03 (line 25070)

Line 25606 has it as being removed, then streaming again in 25614.

Maybe all is revealed in the log, which I attach. Beyond my knowledge I have to admit.

 

[deeptho]

As I understand it, according to neumo.log the file should be in neumo/live as A03 (line 25070)

Line 25606 has it as being removed, then streaming again in 25614.

Maybe all is revealed in the log, which I attach. Beyond my knowledge I have to admit.

This is a bug (one line of code). It is fixed now.

 

[deeptho]

I have just releases neumoDVB version 1.2.1. This has all kinds of bug fixes compared to 1.2
Here is the list of the most important changes:

• Report error when recording in background fails.
• Bug: recordings did not start.
• Bug: Avoid assertion when recordings list is empty.
• Assertion when showing service info in recordings screen.
• Fixed row auto sizing and deleting in lnb list and other lists.
• Fixed assertion while scanning DVB-C muxes.
• Bug: dvbsc and dvbt tune code sometimes find wrong mux due to bug in find_by_mux_fuzzy.
• Bug: incorrect selection of frontend during dvbsc and dvbt tune.
• Bug: assertion when adding more muxes to scan in progress.
• Frontend list: improved display of DVBC/DVBT subscriptions.
• Use the same tolerance everywhere when deciding if a satellite is sufficiently close to the current one for possible reception; Allow error up to and including 1 degree.
• Bug: NIT_ACTUAL incorrectly treated as invalid in GUI in some cases.
• Slightly simplify positioner control: SLAVE control is replaced by NONE, signifying that no dish moving commands will be sent. Actual "slave" status is now determined from on_positioner' field and positioner' field is no longer automatically adjusted.
• Bug: custom lnb settings low_low/high freq_low/mid/high were ignored.
• Improved installation instructions: Merge pull request #29 from Saentist/patch-1.
• Bug: missing abs() when comparing sat_pos, leading to incorrect lnb network selection.
• Improved installation instructions Ubuntu 22.04.
• Avoid assertions when receiving SDT_OTHER table.
• When usals computation goes wrong, e.g., because user did not set proper usals_location or selects satellite below the horizon, set lnb.cur_sat_pos to lnb.usals_pos and avoid assertion.
• When user turns off on_positioner, for an LNB, ensure that lnb.usals_pos and lnb.sat_pos are set to values from the network list, such that the cur_sat_pos column is correct.
• Replace rotor_control_t::FIXED_DISH with rotor_control_t::ROTOR_MASTER_MANUAL, which will be used to indicate that user wants external-to-neumo rotor control. The only difference is that no dish moving commands will be sent.
• Bug: error deleting rows in lists.
• Bug: channel list (not service list) no longer working

 

[EnoSat]

"Setting the LNB to 10.5Gz" is not mentioned in the documentation, which mentions setting freq_min to that value.
That will only work if the card supports it. 6903x does not.

The card processes frequencies approximately in the range of 0.3 to 2.5 GHz (officially 0.95-2.150 GHz), so it does not matter at all what the LOF of the LNB is as long as the output frequency from the LNB is in this range. The LOF value is important for displaying the "imaginary (broadcast)" frequency in the program.

I tried scanning Amateur Radio on 10491 H,1500,4/5 at 26.0E with the lnb set to 10.5 GHz, as the documentation states. This lnb setting does not work on muxes between 10490-10499 H. The only way to lock these muxes is with lnb 9.75 GHz at LOF Low, setting the scan limits between 10470-11200 H or narrowing the search band even more.

If IF-LOF=BB (10492-10500=-8) or LOF-IF=BB (10500-10492=8) is used, then for both cases the resulting BB is nonsense. 10.5GHz will be the beginning of the range rather than the LOF.
LOF can be easily verified in L-band IF-BB=LOF (10492-742=9750)

 

[deeptho]

The card processes frequencies approximately in the range of 0.3 to 2.5 GHz (officially 0.95-2.150 GHz), so it does not matter at all what the LOF of the LNB is as long as the output frequency from the LNB is in this range. The LOF value is important for displaying the "imaginary (broadcast)" frequency in the program.

It does matter that the correct information is given to neumodvb. It also matters if the LNB can actually output the lowest frequency
told to neumoDVB. There are physical limits

If IF-LOF=BB (10492-10500=-8) or LOF-IF=BB (10500-10492=8) is used, then for both cases the resulting BB is nonsense. 10.5GHz will be the beginning of the range rather than the LOF.
LOF can be easily verified in L-band IF-BB=LOF (10492-742=9750)

Yes, that is the correct LOF. That is what I wrote...