It should be an option to build against the system fmt, or if we have to use a specific version, it should not be installed to /usr/lib and /usr/lib64 #42
Comments
|
This may be something weird with arch's build system...not sure yet. xbmc has a nice FindFmt.cmake : |
|
...I seem to be ok with it now with some adjustments, however is it necessary to have Neumodvb bring it's own fmt when it's already installed in the system libs? |
|
Nevermind...my workarounds failed. Guess I need to figure out how to get system fmt working. |
|
This appears to get it built without conflicting with the local system at least - just going built in instead of dynamic: |
Where should this be placed? There is a reason for using non standard packages: specifically when the installed versions are not new enough (eg. ubuntu is often very outdated). Also, there is no need to install neumodvb. Just run from where it was compiled. This is how most people |
|
Here's a patch: https://aur.archlinux.org/cgit/aur.git/plain/static-build-fmt.patch?h=neumodvb-git I can pull request if you want though. In the case of Arch, I have the opposite issue at times where packages are too new...haha. Having it packaged is just nice. |
|
Patch is fine (for such a simple thing). Will be in next version. |
|
Current master is crashing for me whenever I try to scan or tune, it can see the spectrum though...I'm going to build the 1.7 tag and see if it does any better. |
|
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/14.2.1/../../../../include/c++/14.2.1/optional:475: _Tp &std::_Optional_base_impl<devdb::fe_t, std::_Optional_basedevdb::fe_t>::_M_get() [_Tp = devdb::fe_t, _Dp = std::_Optional_basedevdb::fe_t]: Assertion 'this->_M_is_engaged()' failed. |
|
Is my gcc stdlib too new? @deeptho |
|
Just because I got it working right in headend now, doesn't mean I don't want to get neumo working for all the stranger stuff that can be discovered on these satellites. |
|
You should compile using clang, not gcc. And if something does not work, you need to provide useful information to figure out the problem. neumo.log, debug.log, any asserttions printed on the console + a description on how the problem can be made to occur. I doubt that any library is too new. At most that should cause compilation problems. |
Could you please write in the Readme how to do that? I guess others have the same problem. Lots of us are users, not programmers. |
|
No need: it is in the CMakeLists.txt file and the instructions already explain the prerequisites. If you make a similar list for ArchLinux, I am willing to add it to install.md |
|
Maybe you should just provide some information on what went wrong. |
|
I'm using clang/clang++ though...it's just that clang doesn't provide stdlib which is provided by gcc, or at least lives in with the gcc libs. I'll double check - something stupid in the build system may be trying to use gcc instead. If I still hit the wall, I'll run with gdb and see if I can't trace this down to whatever the issue is. |
|
I repeat: Maybe you should just provide some information on what went wrong. If you find something with gdb, then let me know. |
|
@deeptho I go to LNBs, then DX -> Spectrum. I can get the spectrum for H and V, and once the button is white again, I try to blindscan, and then get this crash. It is happening in devdb - I can build with debug on if necessary: Which, when drilled down in the stack is happening here - so my stdlib (14.2.1) may be a newer ABI than yours, which is just an Archlinux life issue...or there's a real issue somewhere? |
|
@deeptho Here's a more and full backtrace from a debug build. I suspect that either one or more std::optional objects isn't being checked properly to use or be dereferenced, or their predecessor may be null or dereferenced and not be getting checked, in one of the assertions? |
|
So that should be easy to find: set a break point on assertion. Go up in the debugger and check in each call frame which variable is null. Or set a break point on one of the calling functions and step through them. |
|
@deeptho so feel free to chide me if you'd like but I'm suspecting now that the issue is some cflag issue from my distro's defaults...building it manually without letting those pass through and it appears to be working now - so I'll try adjusting my build config for the packaged version and see if that fixes it. So far no found muxes, on a known good satellite, but it has 85 peaks left to check. The only other issue I have is that because my GPU is an intel arc card, which does support vulkan and opengl fully, for whatever reason the baked in use of mpv complains in an error dialog that it failed to create an opengl context.... I'll let you know what I come up with otherwise...first chance I've had to try it in a more clean manner. |
|
I had my switch config in the wrong diseqc slot...ha. |
|
So with that correct, while I can see peaks, for whatever reason, I run into this on every peak checked: neumodvb/src/neumodb/devdb/fe_find.cc Line 439 in bf0f307 |
|
In addition, if I manually plug in a valid TP and tune, it does tune and lock under the tune mux box, but it does appear that the mpv integration is not working and I thus cannot play video...not sure if that has to do with something else or the fact mpv, despite my having specified not to use opengl in the config file, throws the "failed to open gl context" error...not sure if that's from wxwidgets or mpv actually...open to suggestions. |
That is a debug message, not an error, |
It cannot work without opengl and opengl should work on all platforms. Does the command line mpv player work? If not, then fix that first. Without using configuration changes. |
|
I'm using an Intel Arc A380 in my home theater PC, primarily for its proper 4K and HDR support. All the critical components like OpenGL, Vulkan, VAAPI, and Mesa are functioning correctly, including MPV on its own. I suspect the issue lies with wxWidgets. I've tried setting various properties when creating the OpenGL instance (such as RGB and such), but this hasn't resolved the problem. Despite the fact I can't play something back after manually plugging in the correct details, I think the more concerning issue I'm facing is with the blind scan, which finds zero muxes. Initially, the spectrum shows one peak with a datastream and rate along with the less obvious ones, but it never finds any of the muxes despite the fact the spectrum is clear and signal is strong. Using your CLI blindscan tool, I can typically find some TPs and muxes, so I’m not sure where the discrepancy is coming from. |
|
I think you are just randomly guessing. |
I have run into an issue where Neumodvb is building it's own fmt, which I already have installed by the system. I'm currently working around it by installing to /opt/neumodvb, however it would be nice if CMake first checked for a system fmt and used that instead?
Totally understand if there's some specific fmt version required, though, too.
The text was updated successfully, but these errors were encountered: