Closed trollcop closed 2 years ago
Indeed a bit hard to read with all the whitespace changes, But I will trust you on that one !! And this is a PR that can open quite a few things so I really like it !
Could you also please provide a win binary ?
Thank you again
I've added one under releases in my fork. I'm not sure if its possible to auto-build using github actions/workflow/whatever the new thing is.
https://github.com/trollcop/MuMuDVB/releases
Indeed a bit hard to read with all the whitespace changes
As far as I know I didn't break anything related to DVB-API (I don't have a good way to test, but I think I didn't). The only trouble point is the MU_F_T macro and friends, as soon as I figure out how to make them work under visual studio, I will fix that :)
Hello, I wonder if this PR might be linked with issue #292 Do you have clues if this might be the case ?
Thank you
Hello, I wonder if this PR might be linked with issue #292 Do you have clues if this might be the case ?
Thank you
i will take a look today and see. i didn't notice 100% on my dvbapi testing but i only have a very old device wish isn't even fully working (tt-3200).
Most likely issue is in the poll area somewhere.
I can confirm the problem exists. Looking through it.
On Tue, May 3, 2022 at 5:04 AM Brice Dubost @.***> wrote:
Hello, I wonder if this PR might be linked with issue #292 https://github.com/braice/MuMuDVB/issues/292 Do you have clues if this might be the case ?
Thank you
— Reply to this email directly, view it on GitHub https://github.com/braice/MuMuDVB/pull/290#issuecomment-1115308028, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABDM5WEECWB26BWYJVYTS2LVIAYMFANCNFSM5UCLWCUQ . You are receiving this because you authored the thread.Message ID: @.***>
Hello, I wonder if this PR might be linked with issue #292 Do you have clues if this might be the case ?
Thank you
The problem isn't in this PR but in UDP/multicast input. Investigating whats going on. This one is fine - I checked out and built 859ad57 and CPU isn't at 100%
@trollcop CPPCheck
Checking src/win32.c ...
src/win32.c:54:5: error: va_list 'ap_copy' used before va_start() was called. [va_list_usedBeforeStarted]
va_copy(ap_copy, ap);
^
src/win32.c:57:39: error: va_list 'ap_copy' used before va_start() was called. [va_list_usedBeforeStarted]
formattedLength = _vscprintf(fmt, ap_copy);
^
src/win32.c:58:5: error: va_list 'ap_copy' used before va_start() was called. [va_list_usedBeforeStarted]
va_end(ap_copy);
^
Is this normal?
Yeah because vasprintf() is called from asprintf() in the same file which does va_start
On Tue, May 10, 2022 at 5:23 AM Saentist @.***> wrote:
CPPCheck
Checking src/win32.c ... src/win32.c:54:5: error: va_list 'ap_copy' used before va_start() was called. [va_list_usedBeforeStarted] va_copy(ap_copy, ap); ^ src/win32.c:57:39: error: va_list 'ap_copy' used before va_start() was called. [va_list_usedBeforeStarted] formattedLength = _vscprintf(fmt, ap_copy); ^ src/win32.c:58:5: error: va_list 'ap_copy' used before va_start() was called. [va_list_usedBeforeStarted] va_end(ap_copy); ^
Is this normal?
— Reply to this email directly, view it on GitHub https://github.com/braice/MuMuDVB/pull/290#issuecomment-1121540858, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABDM5WFNEWS3Q4Z6MUNIWMTVJFX4FANCNFSM5UCLWCUQ . You are receiving this because you authored the thread.Message ID: @.***>
This is kind of a huge PR because I took the project hoping to test some multicast/unicast streaming but as most of my devices are under Windows, I wanted to make it work there first.
At first, I tried using mingw to build stuff, and that made some progress, but as I was looking over the code, I noticed not much of it was actually platform-dependent other than DVB layer, so a native win32 build looked promising.
A lot of these changes are whitespace changes because my editor will REMOVE trailing whitespace on lines by default, and this project was riddled with them. Honestly I think anything larger than a quick hack should have some kind of consistent indent/spacing style automatically applied to prevent this kind of thing from happening.
Changes are, as the title says
1) Making build on win32 2) removing a bunch of compiler warnings (ambigious casts, usage of obsolete inet apis, operator order parenthesis, unused variables, etc etc) 3) Allow building without dvb-api at all - in that case, the only input method is file, at least on Linux, on win32 there's also an interprocess named pipe input method (see doc/readme.win32 for explanation)
All of the above, while still maintaining a buildable environment under Linux (tested to the best of my knowledge)
This would probably need a fair bit of review to chug through the whitespace changes, but as far as I know most other modifications are legit and do not change /break existing functionality.
Comments welcome.