71 replies to this topic

[orator89]

If I look at the configure.ac from the satip client, then your missing boxes ala zgemma, mutant, maxytec and abcom actually appear there.

 

Also with VMSG_TYPE2.

 

But we're talking about usb tuner and not satip. I only mentioned satip because it also uses vtuner.

 

 

I see one strange thing in this "SatIP" code you linked from OpenATV:

 

if test "$BOXTYPE" == "vusolo4k" -o "$BOXTYPE" == "vuuno4k" -o "$BOXTYPE" == "vuuno4kse" -o "$BOXTYPE" == "vuultimo4k" -o "$BOXTYPE" == "vuduo4k" -o "$BOXTYPE" == "vuduo4kse" -o "$BOXTYPE" == "vuzero4k" -o "$BOXTYPE" == "hd51" -o "$BOXTYPE" == "vs1500" -o "$BOXTYPE" == "sf4008" -o "$BOXTYPE" == "gb7252" -o "$BOXTYPE" == "gb72604" -o "$BOXTYPE" == "dags7252" -o "$BOXTYPE" == "xc7439" -o "$BOXTYPE" == "h7" -o "$BOXTYPE" == "8100s" -o "$BOXTYPE" == "osmio4k" -o "$BOXTYPE" == "osmio4kplus" -o "$BOXTYPE" == "osmini4k" -o "$BOXTYPE" == "cc1" -o "$BOXTYPE" == "sf8008" -o "$BOXTYPE" == "sf8008m" -o "$BOXTYPE" == "sf8008opt" -o "$BOXTYPE" == "sx988" -o "$BOXTYPE" == "ustym4kpro" -o "$BOXTYPE" == "ustym4kottpremium" -o "$BOXTYPE" == "gbmv200" -o "$BOXTYPE" == "beyonwizv2" -o "$machine" == "hzero" -o "$machine" == "h8" -o "$BOXTYPE" == "h9" -o "$BOXTYPE" == "h9se" -o "$BOXTYPE" == "h9combo" -o "$BOXTYPE" == "h9combose" -o "$BOXTYPE" == "h10" -o "$BOXTYPE" == "h11" -o "$BOXTYPE" == "i55plus" -o "$BOXTYPE" == "i55se" -o "$BOXTYPE" == "hd60" -o "$BOXTYPE" == "hd61" -o "$BOXTYPE" == "hd66se" -o "$BOXTYPE" == "pulse4k" -o "$BOXTYPE" == "pulse4kmini" -o "$BOXTYPE" == "multibox" -o "$BOXTYPE" == "multiboxse" -o "$BOXTYPE" == "viper4k" -o "$BOXTYPE" == "u5" -o "$BOXTYPE" == "u5pvr" -o "$BOXTYPE" == "u51" -o "$BOXTYPE" == "u52" -o "$BOXTYPE" == "u53" -o "$BOXTYPE" == "u532" -o "$BOXTYPE" == "u533" -o "$BOXTYPE" == "u54" -o "$BOXTYPE" == "u55" -o "$BOXTYPE" == "u56" -o "$BOXTYPE" == "u57" -o "$BOXTYPE" == "u571" -o "$BOXTYPE" == "u41" -o "$BOXTYPE" == "u42" -o "$BOXTYPE" == "u43" -o "$BOXTYPE" == "u45" -o "$BOXTYPE" == "dagsmv200" -o "$BOXTYPE" == "og2ott4k" -o "$BOXTYPE" == "sfx6008"; then
AC_DEFINE(VMSG_TYPE2, 1,[define vtuner_message type 2 see vtuner.h])
fi


if test "$BOXTYPE" == "vuduo" -o "$BOXTYPE" == "vusolo" -o "$BOXTYPE" == "vuduo2" -o "$BOXTYPE" == "vusolo2" -o "$BOXTYPE" == "vuuno" -o "$BOXTYPE" == "vuultimo" -o "$BOXTYPE" == "vusolose" -o "$BOXTYPE" == "vuzero" -o "$BOXTYPE" == "vusolo4k" -o "$BOXTYPE" == "vuuno4k" -o "$BOXTYPE" == "vuultimo4k"; then
AC_DEFINE(VMSG_TYPE1, 1,[define vtuner_message type 1 see vtuner.h])
fi

The "vusolo4k", "vuuno4k" and "vuultimo4k" (all ARM decoders) appear two times, above with "VMSG_TYPE2" defined, and below with "VMSG_TYPE1" defined.

Maybe because "vusolo4k", "vuuno4k" and "vuultimo4k" have different "ARM" cpu dual core? Instead the others are "quad core" hisilicon cpus? I'm only supposing... I don't know...

 

Edited by orator89, 23 July 2022 - 09:17.

[WanWizard]

The VU+, Gigablue, Xsarius, Qviart are Broadcom ARM, the others are HiSilicon ARM.

 

From what I can see in the build tree it doesn't matter, asm-generic for both doesn't set the correct type.

 

My assumption is that ATV just hasn't listed all boxes, and the other images copied ATV.

[orator89]

The VU+, Gigablue, Xsarius, Qviart are Broadcom ARM, the others are HiSilicon ARM.

 

From what I can see in the build tree it doesn't matter, asm-generic for both doesn't set the correct type.

 

My assumption is that ATV just hasn't listed all boxes, and the other images copied ATV.

 

Ok, but I don't understand why "Broadcom ARM" decoders are in both variables (VMSG_TYPE 2 and VMSG_TYPE1) for SatIP vtuner.h..

It will be evaluated only the second one (VMSG_TYPE1), I think? Or I'm wrong?... SO why? mistake? Or it's necessary to list in both variables? The file that will point the "configure.ac" of SatIP is that:

 

https://github.com/o...031736/vtuner.h

 

Edited by orator89, 23 July 2022 - 15:04.

[WanWizard]

I don't know, I can't see any difference in kernel building between Hisilicon and Broadcom. And without the hardware, I can only speculate.

[orator89]

I don't know, I can't see any difference in kernel building between Hisilicon and Broadcom. And without the hardware, I can only speculate.

 

Ok, understood... So for the moment can we make a pull request to add at least "boxtype" for "VMSG_TYPE2" in dvb usb part? The SatIP maybe will be solved later, I will test also that.. But at least can we add same code of OpenATV for "configure.ac" and "dvb.cpp" of "Enigma2"? Or maybe can we modify the code telling "all arm decoders" for "VMSG_TYPE2"? At least the vtunerc usb dvb part... And later we can see also the SatIP part...

[4l3x2k]

 

I don't know, I can't see any difference in kernel building between Hisilicon and Broadcom. And without the hardware, I can only speculate.

 

Ok, understood... So for the moment can we make a pull request to add at least "boxtype" for "VMSG_TYPE2" in dvb usb part? The SatIP maybe will be solved later, I will test also that.. But at least can we add same code of OpenATV for "configure.ac" and "dvb.cpp" of "Enigma2"? Or maybe can we modify the code telling "all arm decoders" for "VMSG_TYPE2"? At least the vtunerc usb dvb part... And later we can see also the SatIP part...

 

Yes that would be reasonable.

 

Later I check the situation with my usb dvb-t device that uses rtl2832, sf8008, openatv 6.4 and openpli 8.2.

 

I also found the autodetect solution provided by @Dima73 for satip client. Maybe this solution could also be used in dvb part of enigma2. This would make the VMSG_TYPE2 variable in configure.ac obsolete.

Edited by 4l3x2k, 23 July 2022 - 16:11.

[orator89]

Yes that would be reasonable.

 

 

Later I check the situation with my usb dvb-t device that uses rtl2832, sf8008, openatv 6.4 and openpli 8.2.

 

I also found the autodetect solution provided by @Dima73 for satip client. Maybe this solution could also be used in dvb part of enigma2. This would make the VMSG_TYPE2 variable in configure.ac obsolete.

 

Wow ahah this is perfect! With this modification, maybe in this way, adding those lines in the right position: 

#if _IOC_NONE == 0
#define VTUNER_GET_MESSAGE  11
#define VTUNER_SET_RESPONSE 12
#define VTUNER_SET_NAME     13
#define VTUNER_SET_TYPE     14
#define VTUNER_SET_HAS_OUTPUTS 15
#define VTUNER_SET_FE_INFO  16
#define VTUNER_SET_NUM_MODES 17
#define VTUNER_SET_MODES 18
#else

we can modify only the "dvb.cpp" file, and we don't need to edit the "configure.ac"

Edited by orator89, 23 July 2022 - 16:23.

[WanWizard]

That would indeed change it for all ARM SoC's.
 
So it should become

#if _IOC_NONE > 0
#define VTUNER_GET_MESSAGE      1
#define VTUNER_SET_RESPONSE     2
#define VTUNER_SET_NAME         3
#define VTUNER_SET_TYPE         4
#define VTUNER_SET_HAS_OUTPUTS  5
#define VTUNER_SET_FE_INFO      6
#define VTUNER_SET_NUM_MODES    7
#define VTUNER_SET_MODES        8
#else
#define VTUNER_GET_MESSAGE     11
#define VTUNER_SET_RESPONSE    12
#define VTUNER_SET_NAME        13
#define VTUNER_SET_TYPE        14
#define VTUNER_SET_HAS_OUTPUTS 15
#define VTUNER_SET_FE_INFO     16
#define VTUNER_SET_NUM_MODES   17
#define VTUNER_SET_MODES       18
#endif
#define VTUNER_SET_DELSYS      32
#define VTUNER_SET_ADAPTER     33

?

Edited by WanWizard, 23 July 2022 - 17:00.

[orator89]

That would indeed change it for all ARM SoC's.

 

Yes. It's the right way?

[WanWizard]

I don't know, this is way above my pay grade . But is sounds logical, I can commit it, so it can be tested tomorrow after the build is finished.

[orator89]

I don't know, this is way above my pay grade . But is sounds logical, I can commit it, so it can be tested tomorrow after the build is finished.

 

ahaha I made a commit with first modification some minutes ago, but your modification seems better with ">" operator

Edited by orator89, 23 July 2022 - 17:07.

[WanWizard]

autism trait, I'd like the numbers to be in order

 

If you have patched a local image, I'll wait with comitting until you report it fixes it for you.

[orator89]

autism trait, I'd like the numbers to be in order

 

If you have patched a local image, I'll wait with comitting until you report it fixes it for you.

No I didn't patched any image. I just added modification in forked repository to test in your builds.. You can close commit, or I can close it.. And you can add your editing with ">" operator.

Edited by orator89, 23 July 2022 - 17:25.

[WanWizard]

Ok, Clear. Done, will be in tommorrows image.

[4l3x2k]

Ok, Clear. Done, will be in tommorrows image.

Great!

 

Maybe you missed some header file. @Dima73 also includes linux/ioctl.h. This is not the same as sys/ioctl.h.

 

But build will tell us whether it is necessary or not.

 

@orator89

Do you may tell us what you want do achieve with the usb device? Are you in a region where dvb-t is still used?

And please tell me what you did to get this message with unknown IOCTL.

 

I want to reproduce it.

 

My RTL2832 device is a

 

Dexatek DK DVB-T Dongle (Logilink VG0002A)

 

with

 

Fitipower FC0013 tuner.

[ims]

2832 is good working, but not for DVB-T2 ... unusable in this time in most countries, imho

[orator89]

 

@orator89

Do you may tell us what you want do achieve with the usb device? Are you in a region where dvb-t is still used?

And please tell me what you did to get this message with unknown IOCTL.

 

I want to reproduce it.

 

My RTL2832 device is a

 

Dexatek DK DVB-T Dongle (Logilink VG0002A)

 

with

 

Fitipower FC0013 tuner.

 

Ok, in my country the DVB-T is still in use, until the end of 2022. I have, as already told, two devices. RTL2832U (only DVB-T) and RTL2832P (DVB-T/T2/C).
With both happens same error when you search to scan

 

2832 is good working, but not for DVB-T2 ... unusable in this time in most countries, imho

 Inexact. In OpenATV the DVB-T2 part works (= RTL2832P, also known as ASTROMETA, correctly recognized, but I cannot search channels because in Italy there isn't DVB-T2 until 2023), and I think that I found the solution alson in OpenPLI with the a "prestart" switch that make the device recognized as "DVB-T2", but for that you need to install the driver "mn88473" from OpenATV feeds, because with the simple "RTL2832" driver of OpenPLi it shows only two frontends, instead with drivers of OpenATV it shows 3 frontends (Panasonic MN88473, demod DVB-T2, is recognized and added in dmesg) and you can switch beetween them.

Edited by orator89, 23 July 2022 - 19:26.

[orator89]

 

 

@orator89

Do you may tell us what you want do achieve with the usb device? Are you in a region where dvb-t is still used?

And please tell me what you did to get this message with unknown IOCTL.

 

I want to reproduce it.

 

My RTL2832 device is a

 

Dexatek DK DVB-T Dongle (Logilink VG0002A)

 

with

 

Fitipower FC0013 tuner.

 

 

If you want to reproduce.. In order:

1) Install RTL2832 drivers

 

2) Restart box with DVB RTL2832 inserted and when system initialized, on telnet digit "dmesg" and see if in the entire output it shows various errors "unknown IOCTL 0x2 " and others... Those errors there aren't on OpenATV.

 

3) If there are those errors, when you will try to scan channels (but only if there is signal SNR and AGC on the transponder you select), your system will block, and if you digit "dmesg" again on telnet, you will get loop error:

 

 vtunerc0: unknown IOCTL 0x1

Edited by orator89, 23 July 2022 - 19:56.

[4l3x2k]

 

 

 

@orator89

Do you may tell us what you want do achieve with the usb device? Are you in a region where dvb-t is still used?

And please tell me what you did to get this message with unknown IOCTL.

 

I want to reproduce it.

 

My RTL2832 device is a

 

Dexatek DK DVB-T Dongle (Logilink VG0002A)

 

with

 

Fitipower FC0013 tuner.

 

 

If you want to reproduce.. In order:

1) Install RTL2832 drivers

 

2) Restart box with DVB RTL2832 inserted and when system initialized, on telnet digit "dmesg" and see if in the entire output it shows various errors "unknown IOCTL 0x2 " and others... Those errors there aren't on OpenATV.

 

3) If there are those errors, when you will try to scan channels (but only if there is signal SNR and AGC on the transponder you select), your system will block, and if you digit "dmesg" again on telnet, you will get loop error:

 

 vtunerc0: unknown IOCTL 0x1

 

Thank you.

 

The tuner appear on both images after installing dvb-usb-rtl2832 from drivers section and doing a full reboot of the box. A search can be made but it does not find any channels. dvb-t stopped broadcast in my region so this is expected.

 

Thus step 3) is out of my test.

 

 

I really hope the change made by WanWizard is going to work for you orator89.

 

Please see that the change by WanWizard was made to develop branch so you will need to test with develop image by openpli and not openpli 8.2.

Edited by 4l3x2k, 23 July 2022 - 20:26.

[orator89]

The tuner appear on both images after installing dvb-usb-rtl2832 from drivers section and doing a full reboot of the box. A search can be made but it does not find any channels. dvb-t stopped broadcast in my region so this is expected.

 

Thus step 3) is out of my test.

 

I expected that...But when inserted and system started, in dmesg Openpli you see errors?
In OpenATV it should show correctly:

vtunerc0: setting DVB-T tuner type
vtunerc0: usb frontend initialized as type=4

Instead on Openpli you should see:

vtunerc0: unknown IOCTL 0x3
vtunerc0: unknown IOCTL 0x4
vtunerc0: unknown IOCTL 0x5
vtunerc0: unknown IOCTL 0x6
vtunerc0: usb frontend initialized as type=0

Please, see this. 

 

 

Please see that the change by WanWizard was made to develop branch so you will need to test with develop image by openpli and not openpli 8.2.

 Yes, I know, thanks