neumoDVB

Thanks!

The /tmp/neumo.log file grew to 52MB after watching TV for 10 minutes. Is there any way to reduce it?
logging is controlled through
config/neumo.xml
It helps me to fix problems.....
 
logging is controlled through
config/neumo.xml
It helps me to fix problems.....

It's necessary, it's understandable.
But for the next version, please add the option to disable it in a menu, and if there's an error, enable it so you can see the cause of the error.
I'm requesting this because I've had neumodvb close more than once because I don't have any space left in /tmp due to the log.
And since I'm requesting, for the next version, and if you have time to do it, enabling the format change would be nice. I have several channels that don't send the correct aspect ratio, mpv has it and does it with "shift a".
Thanks!
 
It's necessary, it's understandable.
But for the next version, please add the option to disable it in a menu, and if there's an error, enable it so you can see the cause of the error.
I'm requesting this because I've had neumodvb close more than once because I don't have any space left in /tmp due to the log.
And since I'm requesting, for the next version, and if you have time to do it, enabling the format change would be nice. I have several channels that don't send the correct aspect ratio, mpv has it and does it with "shift a".
Thanks!
You must have a computer with really little memory. Menu item: no, but it is possible to disable it in a config and in any case, the extra logging was more a result of forgetting to disable it.
 
I have just released a new version of neumoDVB

Changes in version neumodvb-2.1​

Major new features​

  • Fast and slow playback, including osd message.
  • Reverse play, including osd message.
  • Smart jumping during playback: the amount of jumping backward now increases with each key press andis then reduced again as soon a the jump direction is changed using the left and right arrow keys.
  • Allow reusing recently abandoned live buffer. This allows keeping timeshift data from a previous tune and rewinding that service.The main reason for implementing this is, is to prevent loss of all time shift data when accidentally tuning to anotherservice: the old data remains available for a few miutes and will become useable as soon as the original service is retuned.

Gui​

  • Allow jumping forward and backward in playback, even when servicelist is displayed.
  • Stereo loudness normalization.
  • Increased subtitle size.
  • Display streams in 4/3 format as 16/9. Also detect weird HEVC aspect ratios and force them to 16/9.
  • Service information window needlessly small in positioner dialog.
  • Activate selected audio language at service start.
  • Allow removing ch_order in service_list.
  • Experimental fix to remove/reduce hick-ups at start, but some of these hickups may reappear due tothe new reverse-play code.
  • Reduced font size on live screen.
  • Experimental change to try to remove artifacts seen by some users.
  • Live screen: show blank channel order numbers when user has not set such numbers.
  • Live screen: show message when stream fails to decrypt.

Bug fixes​

  • Regression: menu from spectrum dialog removed due to commit 388034f16d552373be94ea9.
  • Some data incorrectly copied when adding ts-in-ts muxes.
  • Gridepg cache can fill up with new services discovered by scanning, resulting in an assertion.
  • mmap at wrong offset, causing playback to malfunction.
  • Remove debug code causing problems for some users.
  • Commands sometimes disabled when gui is hidden in live mode.
  • Unwanted showing of coloured border when gui is hidden.
  • Some jump forward/backward bugs.
  • Record not working when gui is hidden.
  • SDT not processed when no nit is present
  • Trying to save template mux (not allowed) when retuning too fast in positioner dialog.
  • Bug: entering user defined muxes in muxlist causes template muxes to be inserted in database; change tune_src to USER in this case.
  • Regression: neumodvb no longer working with DVBAPI, i.e., when proper drivers are not installed.
  • scan_status_t::PENDING not set when tuned mux is not yet in database
  • Update_stream_ids_from pat sometimes called erroneously.
  • Invalid assertion when not using neumodvb drivers.
  • Saved subtitle preference not applied at channel playback; Bug: saved preference incorrectly shown in subtitle dialog.
  • Stackstring::rotate not working properly.
  • Confusion on 28.2E between bloomberg and freesat eit
  • Incorrect fixing of this->dbmux from sdt
  • Don't log known skipped descriptors.
  • Horizontal scroll not working in live epg
  • Sometimes wrong config_id picked.
  • Incorrect assertion during scan of 0.8W.
  • fe_monitor sometimes does not exit due to race. Renamed fe_monitor_t::stop and ::start to pause and unpause.
  • playback_mpm reads past num_bytes_safe_to_read, which could cause crash when mpm part is truncated.
  • Oncorrect call to wait_for_update causes this call not to wait, resulting in a needless busy loop.
  • Incorrect assertion when two non-lockable old muxes overlap.
  • Incorrect assertion when tuning two overlapping muxes and both fail.
  • Old error messages are prepended to new ones.
  • Allow frequency update for muxes without si-data (e.g. gse)
  • Regression: message to oscam truncated when pid=0x1fff.
  • When filtering for frequency in service list, the frequency limits are narrowed by subsequent sorts, resulting in errors in the displayed services.
  • Correctly propagate scan when scanning ts-in-ts muxes.

Other​

  • Swap the East and West buttons on the positioner dialog for installations on the southern hemisphere.Proper operation of Usals has not yet been tested in this case.
  • Do not save muxes when lock times out.
  • Force biss caid when decrypted data is received but there is no valid capmt data.

Internals​

  • Simplified code for playback_mpm, introdcing mpm_cursor_t to seek by time and byte position.
  • Reduce log verbosity.
  • Improved setting/remembering of which mpv playback window willl receive GUI commands.
  • Remove dependency on sip.
  • Support for Ubuntu 24.4.
  • Improved assertion.
  • Change how textures are managed.
  • Update main.yml.
  • Refactor pause command.
  • scam: add enigma namespace descriptor.
  • Remove accidentally left over debug printf.
  • Remove unneeded header.
 
Swap the East and West buttons on the positioner dialog for installations on the southern hemisphere.

I don't use NeumoDVB, but my eye fell upon this sentence, as I wondered about this issue (this incongruency) some time ago, when I worked on my (USALS) motor angles spreadsheet.


A motor doesn't know if it is on the northern or southern hemisphere. So the USALS command "DriveMotorEast" should in fact have the name DriveMotorLeft, as that is the way a motor is programmed to react to that command, regardless of the hemisphere where the motor is situated.
Same case with EastLimit instead of LeftLimit, etc, etc.

So you could swap all the button names with East and West, to repair this; or you could rename them to Left and Right. And use the appropriate calculations, either way.
If renamed to Left and Right, I think it is more clear that the historical incongruency for the southern hemisphere is 'repaired'. Otherwise you have to check, in every application, when you are south of the equator, if GoEast means GoLeft (incorrect) or GoRight (correct).
So using the terms Left and Right would be my solution, for solving the incongruency. Though I realize that is sort of a revolution... :-ohmy


Also most positioners have GoEast/GoWest buttons, I noticed. Better button names would have been GoLeft/GoRight.
[ Of course you can swap the motor wires to solve this. But then, you have to use the left button (with "GoEast"), to actually go eastwards: to the right. That doesn't deserve a prize in the beauty contest... ]


No idea why the Eutelsat document for diseqc 1.2 (Positioner Application Note) didn't address (or solve) this issue.
It is "not inclusive" to have commands or buttons that just match the northern hemisphere, I think.


Sorry for this rather off-topic sidestep.

Greetz,
A33
 
I don't use NeumoDVB, but my eye fell upon this sentence, as I wondered about this issue (this incongruency) some time ago, when I worked on my (USALS) motor angles spreadsheet.


A motor doesn't know if it is on the northern or southern hemisphere. So the USALS command "DriveMotorEast" should in fact have the name DriveMotorLeft, as that is the way a motor is programmed to react to that command, regardless of the hemisphere where the motor is situated.
Same case with EastLimit instead of LeftLimit, etc, etc.

So you could swap all the button names with East and West, to repair this; or you could rename them to Left and Right. And use the appropriate calculations, either way.
If renamed to Left and Right, I think it is more clear that the historical incongruency for the southern hemisphere is 'repaired'. Otherwise you have to check, in every application, when you are south of the equator, if GoEast means GoLeft (incorrect) or GoRight (correct).
So using the terms Left and Right would be my solution, for solving the incongruency. Though I realize that is sort of a revolution... :-ohmy


Also most positioners have GoEast/GoWest buttons, I noticed. Better button names would have been GoLeft/GoRight.
[ Of course you can swap the motor wires to solve this. But then, you have to use the left button (with "GoEast"), to actually go eastwards: to the right. That doesn't deserve a prize in the beauty contest... ]


No idea why the Eutelsat document for diseqc 1.2 (Positioner Application Note) didn't address (or solve) this issue.
It is "not inclusive" to have commands or buttons that just match the northern hemisphere, I think.


Sorry for this rather off-topic sidestep.

Greetz,
A33
Is this what the Donald means by the radical-left? :->

Left/right is not good either as it depends on conventions like: viewed from in front or from behind the dish, or rotor axis pointing down or up.
On Egyptian satellites they are even cofused about where the satellite is....
 
Left/right is not good either as it depends on conventions like: viewed from in front or from behind the dish, or rotor axis pointing down or up.

Well, the convention that Left is used for left, counterclockwise direction, and that you would look from above the motor (regardless of axis pointing up or down) to see the satellite direction (more left or right), are already rather common conventions, I would say.

But, the time for the revolution hasn't come yet, it seems. ;-)

The fact remains that even the eutelsat diseqc documents are not southern-hemisphere-proof. To have just one command "DriveMotorEast" for a motor that is following the Diseqc protocol (and carrying the diseqc logo), without sending/using an identifyer if you are north or south of the equator, is wrong.
So south of the equator, you have to use the command "DriveMotorEast" to go West. That is a better convention for you? ;-)

Greetz,
A33



N.B. To add: Convention for skew angle is: positive value is clockwise, when seen in the direction of the satellite. Regardles if the LNB is pointing directly at the satellite (without dish), or a (one) dish is used as a mirror, or even if also a secondary mirror is used, as with a Fibo or T90 dish.
So: some conventions are better and/or more selfexplaining than others. "From behind the LNB" is not clear, as long as it is unclear how many mirrors are used between the LNB and the satellite. So the convention to define skew angle in the direction of the satellite is rather good, I'd say. :cool:
 
Well, the convention that Left is used for left, counterclockwise direction, and that you would look from above the motor (regardless of axis pointing up or down) to see the satellite direction (more left or right), are already rather common conventions, I would say.

But, the time for the revolution hasn't come yet, it seems. ;-)
It will happen when the Australians learn to walk the right way up.

The fact remains that even the eutelsat diseqc documents are not southern-hemisphere-proof. To have just one command "DriveMotorEast" for a motor that is following the Diseqc protocol (and carrying the diseqc logo), without sending/using an identifyer if you are north or south of the equator, is wrong.
So south of the equator, you have to use the command "DriveMotorEast" to go West. That is a better convention for you? ;-)
Indeed, and there are many other poor choices in there, but all of these things are internal to software.

I think neumodvb tries to use the right thing: you enter the coordinates of your location. If you then press "go east" it will drive the motor
to go east. What could be less confusing? There can be bugs of course.

Greetz,
A33



N.B. To add: Convention for skew angle is: positive value is clockwise, when seen in the direction of the satellite. Regardles if the LNB is pointing directly at the satellite (without dish), or a (one) dish is used as a mirror, or even if also a secondary mirror is used, as with a Fibo or T90 di
True, but each time someone reports skew I have to look up the convention and each time someone gives advice they must explain the convention.

So: some conventions are better and/or more selfexplaining than others. "From behind the LNB" is not clear, as long as it is unclear how many mirrors are used between the LNB and the satellite. So the convention to define skew angle in the direction of the satellite is rather good, I'd say. :cool:
It becomes even more interesting with a T90 wavefrontier dish as the lnbs are pointing 180 degrees different to other dishes.
 
... but all of these things are internal to software.

I think neumodvb tries to use the right thing: you enter the coordinates of your location. If you then press "go east" it will drive the motor
to go east. What could be less confusing?

This way, you have solved it in the user interface of neumoDVB. That is good, indeed.

In the programmer interface, you still have to deal with the fact that giving the command "DriveMotorEast" sometimes results in the motor driving to the west.
Even my (revolution)solution would have an incongruency, because my term "DriveMotorLeft" is a derivative of the original Eutelsat term "DriveMotorEast", and you have to realize the relation between the two.

So always at some level, the incongruency remains.
And everyone has his own way, of dealing with it.

I (as a radical :p ) will keep using the terms GoLeft and GoRight (or similar) regularly in the forums, though, as I think they are clearer and better than the Eutelsat terms.

Greetz,
A33
 
I (as a radical :p ) will keep using the terms GoLeft and GoRight (or similar) regularly in the forums, though, as I think they are clearer and better than the Eutelsat terms.
Moving the dish east or west leaves no doubt.
Move left or right yes, since it depends on our relative position.
Saludos!
 
I (as a radical :p ) will keep using the terms GoLeft and GoRight (or similar) regularly in the forums, though, as I think they are clearer and better than the Eutelsat terms.

Greetz,
A33
This is all small potatos: Soon we will have daylight savings time
 
Moving the dish east or west leaves no doubt.
Move left or right yes, since it depends on our relative position.
Saludos!
And why can it not be moved north and south?
 
And why can it not be moved north and south?
Are we talking about moving the antenna east or west along the Clark curve?
Imagine having two motorized dish, one in front of you and one behind you. Right or left, or clockwise or counterclockwise, leads to confusion.
 
Are we talking about moving the antenna east or west along the Clark curve?
Imagine having two motorized dish, one in front of you and one behind you. Right or left, or clockwise or counterclockwise, leads to confusion.
No, we are talking about a joke. :->
 
Hi

I found a TP that closes neumodvb.

Attached log

This TP does not cause any problems with Kaffeine.

Thanks!
 

Attachments

Hi

I found a TP that closes neumodvb.

Attached log

This TP does not cause any problems with Kaffeine.

Thanks!
Try removig the line
assert(ts_id != 65535);
in active_si_stream.cc at line 66.
After recompiling it will probably work
 
can you please help?
TBS 6903 How can I change it? There are 2 tuners

diff --git a/drivers/media/usb/dvb-usb/tbs5927.c b/drivers/media/usb/dvb-usb/tbs5927.c
old mode 100644
new mode 100755
index 0df754b44..254257d19
--- a/drivers/media/usb/dvb-usb/tbs5927.c
+++ b/drivers/media/usb/dvb-usb/tbs5927.c
@@ -414,6 +414,7 @@ static struct dvb_usb_device_properties tbs5927_properties = {
.adapter = {{
.num_frontends = 1,
.fe = {{
+ .caps = DVB_USB_ADAP_RECEIVES_RAW_PAYLOAD,
.frontend_attach = tbs5927_frontend_attach,
.streaming_ctrl = NULL,
.tuner_attach = tbs5927_tuner_attach,
 
Ok, I did rm -rf neumodvb folder and after that I build latest from github (b5714fd by the time of writing), hoping to resolve some issues when neumodvb freeze on channels that cannot decrypt. Random freeze is still there on scrambled channels so I must terminate neumodvb and start all over, but I can live with that, but this confuses me:
cat /sys/module/dvb_core/info/version
type = "neumo";
version = "1.7";

Shouldn't it be 2.1 version as far as I remember it is the latest?
Btw, it is Debian Trixie with 6.12.38 kernel.
 
Ok, I did rm -rf neumodvb folder and after that I build latest from github (b5714fd by the time of writing), hoping to resolve some issues when neumodvb freeze on channels that cannot decrypt. Random freeze is still there on scrambled channels so I must terminate neumodvb and start all over, but I can live with that, but this confuses me:
Well, your guess is as good as mine. You have log fles, I don't.

cat /sys/module/dvb_core/info/version
type = "neumo";
version = "1.7";

Shouldn't it be 2.1 version as far as I remember it is the latest?
Btw, it is Debian Trixie with 6.12.38 kernel.
This is the version of he API
 
Back
Top