[ET10x00] Webif not showing TV picture in screen capture

twol · Apr 19, 2024

LraiZer said:
For me, it does not build with the other two flags on their own.. but passes without issue when just time flag or all other three flags are present. there is a warning that you need to add an additional INSANE_SKIP to the bitbake, as it is now uses the 32bit-time api and not the 64bit api from the build.

-D_TIME_BITS=64
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64

WARNING: aio-grab-1.0+git-r0 do_package_qa: QA Issue: /usr/bin/grab uses 32-bit api 'ioctl'
Suppress with INSANE_SKIP = "32bit-time" [32bit-time]

@lraizer - thanks for the fix - just need to check on a couple of boxes to make sure it doesn,t cause an issue before commit to OE-A

LraiZer · Apr 19, 2024

birdman said:
Yes. Those have been the flags for 64-bit file size on 32-bit system for ~20 years. (64-bit systems don't need them, but adding them causes no problem, as it only sets what is already set).
Omitting them doesn't cause a problem unless you try to access a file >2GB, which aio-grab won't be doing.

yes, largefile flag is not required, but 64 bit file offset flag is, and this must be used with 64 time bits flag so a minimum working bitbake file would have to contain at least these two line additions:

Code:

TARGET_CC_ARCH:remove = "-D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64"
INSANE_SKIP = "32bit-time"

Code:

DESCRIPTION="AiO screenshot grabber"
MAINTAINER = "PLi team"
LICENSE = "GPL-2.0-only"
LIC_FILES_CHKSUM = "file://LICENSE;md5=751419260aa954499f7abaabaa882bbe"

DEPENDS = "jpeg libpng zlib"

inherit gitpkgv

TARGET_CC_ARCH:remove = "-D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64"

INSANE_SKIP = "32bit-time"

PV = "1.0+git"
PKGV = "1.0+git${GITPKGV}"

SRC_URI="git://github.com/oe-alliance/aio-grab.git;protocol=https;branch=master"

S = "${WORKDIR}/git"

inherit autotools pkgconfig

birdman · Apr 20, 2024

LraiZer said:
yes, largefile flag is not required, but 64 bit file offset flag is, and this must be used with 64 time bits flag...

You might already have 64bit time_t by default (my Linux systems do). Similarly with 64-bit file offsets.
I suspect that setting them when they would be set anyway isn't a problem, but I reckon this should only be set when it needs to be.
My Vix box (et8000) doesn't have 64-bit time, so I wouldn't want it hardcoded into its build.

birdman · Apr 20, 2024

birdman said:
My Vix box (et8000) doesn't have 64-bit time, so I wouldn't want it hardcoded into its build.

Ah, I see.
It's just saying, "Please set thing up to use the 64-bit time API". Just as -D_FILE_OFFSET_BITS=64 says, "Use the 64-bit file-system API".

But then you have to wonder why it's needed at all.

On a 32-bit system using the 32-bit file-system API is only a problem if you try to access a file >2GB (or an inode...).
So why is using the the 32-bit time API a problem? We haven't reached 2038 yet.

LraiZer · Apr 20, 2024

I was only trying to remove the -D_FILE_OFFSET_BITS=64 flag here so that the call to mmap64 is automatically redirected back to mmap() which works.

If all the other boxes are working and you want to try fixing it for just mips32 to extend their life by 14 years?

Code:

DESCRIPTION="AiO screenshot grabber"
MAINTAINER = "PLi team"
LICENSE = "GPL-2.0-only"
LIC_FILES_CHKSUM = "file://LICENSE;md5=751419260aa954499f7abaabaa882bbe"

DEPENDS = "jpeg libpng zlib"

inherit gitpkgv

TARGET_CC_ARCH:remove = "${@bb.utils.contains('TUNE_FEATURES', 'mips32', '-D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64' , '', d)}"

INSANE_SKIP = "${@bb.utils.contains('TUNE_FEATURES', 'mips32', '32bit-time' , '', d)}"

PV = "1.0+git"
PKGV = "1.0+git${GITPKGV}"

SRC_URI="git://github.com/oe-alliance/aio-grab.git;protocol=https;branch=master"

S = "${WORKDIR}/git"

inherit autotools pkgconfig

birdman · Apr 20, 2024

LraiZer said:
I was only trying to remove the -D_FILE_OFFSET_BITS=64 flag here so that the call to mmap64 is automatically redirected back to mmap() which works.

Ah. You're saying it is the use of mmap64() that is the issue., not 64-bit time?

Still weird. mmap64 should work an a 32-bit system (otherwise you could never mmap sections of large files - and you can...)

twol · Apr 20, 2024

LraiZer said:
I was only trying to remove the -D_FILE_OFFSET_BITS=64 flag here so that the call to mmap64 is automatically redirected back to mmap() which works.

If all the other boxes are working and you want to try fixing it for just mips32 to extend their life by 14 years?

Code:

DESCRIPTION="AiO screenshot grabber" MAINTAINER = "PLi team" LICENSE = "GPL-2.0-only" LIC_FILES_CHKSUM = "file://LICENSE;md5=751419260aa954499f7abaabaa882bbe" DEPENDS = "jpeg libpng zlib" inherit gitpkgv TARGET_CC_ARCH:remove = "${@bb.utils.contains('TUNE_FEATURES', 'mips32', '-D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64' , '', d)}" INSANE_SKIP = "${@bb.utils.contains('TUNE_FEATURES', 'mips32', '32bit-time' , '', d)}" PV = "1.0+git" PKGV = "1.0+git${GITPKGV}" SRC_URI="git://github.com/oe-alliance/aio-grab.git;protocol=https;branch=master" S = "${WORKDIR}/git" inherit autotools pkgconfig

Well your original change works for both the old boxes and new (I tested on vu+ uno4kse and GBUE4k), so thats the commit on OE-A… and don,t forget someone posted solo4k not working and thats not mips.
my Xtrend ET7500 (mips) works on the old code no issue, so again not all mips boxes have an issue.

birdman · Apr 20, 2024

twol said:
Well your original change works for both the old boxes and new (I tested on vu+ uno4kse and GBUE4k), so thats the commit on OE-A… and don,t forget someone posted solo4k not working and thats not mips.
my Xtrend ET7500 (mips) works on the old code no issue, so again not all mips boxes have an issue.

All of which makes me wonder whether the problem is something else, and this change lets things work by accident.

EDIT: such as registeroffset and mem2memdma_register being declared as unsigned int instead of off_t?

LraiZer · Apr 20, 2024

The mmap(2) - Linux man page declares offset as off_t not unsigned int in its in example, so that code does looks wrong there.

sizeof(off_t) changes using -D_FILE_OFFSET_BITS=64 the same way as sizeof(time_t) changes when using -D_TIME_BITS=64

LraiZer · Apr 20, 2024

Try just declaring int as size_t to fix it?

This single change alone fixed it for me.

Code:

diff --git a/main.c b/main.c
index 1c1fee7..a01297d 100644
--- a/main.c
+++ b/main.c
@@ -1148,7 +1148,7 @@ void getvideo(unsigned char *video, int *xres, int *yres)
 			return;
 		}
 
-		int adr, adr2, ofs, ofs2, offset, pageoffset;
+		size_t adr, adr2, ofs, ofs2, offset, pageoffset;
 		int xtmp,xsub,ytmp,t2,dat1;
 
 		if (stb_type == BRCM73565 || stb_type == BRCM73625 || stb_type == BRCM7439DAGS || stb_type == BRCM7439 || stb_type == BRCM75845 || stb_type == BRCM72604) {

birdman · Apr 21, 2024

LraiZer said:
Try just declaring int as size_t to fix it?

Offsets are off_t. not size_t.
The fact that these are the same size doesn't alter the fact that they should be declared the same way as they are defined.

LraiZer · Apr 21, 2024

If you can make 'adr' work using off_t?
'adr' only works defined with size_t for me.

Origianl declaration:

int adr, adr2, ofs, ofs2, offset, pageoffset;

Code:

Grabbing 32bit Framebuffer ...
... Framebuffer-Size: 1920 x 1080
Grabbing Video ...
Adr: BC000000 Adr2: BC1FE000 OFS: 440 240 stride:780
Adr: BC000000 Adr2: BC1FE000 offset: 1FE000 pageoffset:0
Stride: 1920 Res: 1080
sizeof(off_t) 8 sizeof(Adr:) 4 sizeof(Adr2): 4 sizeof(OFS): 4 sizeof(OFS2): 4
Adr: BC000000 Adr2: BC1FE000 OFS: 440 240 memory_tmp_size:31E000
Mainmemory: <Memmapping failed>
Resizing Video to 1920 x 1080 ...
Merge Video with Framebuffer ...
Saving 24 bit /tmp/screenshot.bmp ...
... Done !

with off_t:

off_t adr;
int adr2, ofs, ofs2, offset, pageoffset;

Code:

Grabbing 32bit Framebuffer ...
... Framebuffer-Size: 1920 x 1080
Grabbing Video ...
Adr: BC000000 Adr2: FFFFFFFF OFS: BC1FE000 440 stride:240
Adr: BC000000 Adr2: FFFFFFFF offset: BC1FE000 pageoffset:1FE000
Stride: 1920 Res: 1080
sizeof(off_t) 8 sizeof(Adr:) 8 sizeof(Adr2): 4 sizeof(OFS): 4 sizeof(OFS2): 4
Adr: BC000000 Adr2: FFFFFFFF OFS: BC1FE000 440 memory_tmp_size:240
Mainmemory: <Memmapping failed>
Resizing Video to 1920 x 1080 ...
Merge Video with Framebuffer ...
Saving 24 bit /tmp/screenshot.bmp ...
... Done !

working with size_t:

size_t adr;
int adr2, ofs, ofs2, offset, pageoffset;

Code:

Grabbing 32bit Framebuffer ...
... Framebuffer-Size: 1920 x 1080
Grabbing Video ...
Adr: BC000000 Adr2: BC1FE000 OFS: 440 240 stride:780
Adr: BC000000 Adr2: BC1FE000 offset: 1FE000 pageoffset:0
Stride: 1920 Res: 1080
sizeof(off_t) 8 sizeof(Adr:) 4 sizeof(Adr2): 4 sizeof(OFS): 4 sizeof(OFS2): 4
Adr: BC000000 Adr2: BC1FE000 OFS: 440 240 memory_tmp_size:31E000
Merge Video with Framebuffer ...
Saving 24 bit /tmp/screenshot.bmp ...
... Done !

LraiZer · Apr 21, 2024

If you must declare off_t for the mmap offset, you could try this patch to remove the padding from adr of /* start of videomem */
This seems to also work.

Code:

diff --git a/main.c b/main.c
index 1c1fee7..9a6e455 100644
--- a/main.c
+++ b/main.c
@@ -161,8 +161,8 @@ static enum {UNKNOWN, DMNEW, WETEK, AZBOX863x, AZBOX865x, ST, PALLAS, VULCAN, XI
 
 static int chr_luma_stride = 0x40;
 static int chr_luma_register_offset = 0;
-static unsigned int registeroffset = 0;
-static unsigned int mem2memdma_register = 0;
+static off_t registeroffset = 0;
+static off_t mem2memdma_register = 0;
 static int quiet = 0;
 static int video_dev = 0;
 
@@ -1148,7 +1148,8 @@ void getvideo(unsigned char *video, int *xres, int *yres)
 			return;
 		}
 
-		int adr, adr2, ofs, ofs2, offset, pageoffset;
+		off_t adr;
+		int adr2, ofs, ofs2, offset, pageoffset;
 		int xtmp,xsub,ytmp,t2,dat1;
 
 		if (stb_type == BRCM73565 || stb_type == BRCM73625 || stb_type == BRCM7439DAGS || stb_type == BRCM7439 || stb_type == BRCM75845 || stb_type == BRCM72604) {
@@ -1158,13 +1159,13 @@ void getvideo(unsigned char *video, int *xres, int *yres)
 			ofs2 = data[chr_luma_register_offset + 28] << 4; /* chroma lines */
 			adr2 = data[chr_luma_register_offset + 3] << 24 | data[chr_luma_register_offset + 2] << 16 | data[chr_luma_register_offset + 1] << 8;
 			stride = data[0x19] << 8 | data[0x18];
-			adr = data[0x37] << 24 | data[0x36] << 16 | data[0x35] << 8; /* start of videomem */
+			adr = (data[0x37] << 24 | data[0x36] << 16 | data[0x35] << 8) & 0xffff0000; /* start of videomem */
 		} else {
 			ofs = data[chr_luma_register_offset + 8] << 4; /* luma lines */
 			ofs2 = data[chr_luma_register_offset + 12] << 4; /* chroma lines */
 			adr2 = data[chr_luma_register_offset + 3] << 24 | data[chr_luma_register_offset + 2] << 16 | data[chr_luma_register_offset + 1] << 8;
 			stride = data[0x15] << 8 | data[0x14];
-			adr = data[0x1f] << 24 | data[0x1e] << 16 | data[0x1d] << 8; /* start of videomem */
+			adr = (data[0x1f] << 24 | data[0x1e] << 16 | data[0x1d] << 8) & 0xffff0000; /* start of videomem */
 		}
 		offset = adr2 - adr;
 		pageoffset = adr & 0xfff;

birdman · Apr 21, 2024

LraiZer said:
If you must declare off_t for the mmap offset,

From the man page for mmap():

Code:

         [FONT=monospace][COLOR=#000000][B]void *mmap(void [/B][/COLOR][COLOR=#000000]addr[/COLOR][COLOR=#000000][B][.[/B][/COLOR][COLOR=#000000]length[/COLOR][COLOR=#000000][B]], size_t [/B][/COLOR][COLOR=#000000]length[/COLOR][COLOR=#000000][B], int [/B][/COLOR][COLOR=#000000]prot[/COLOR][COLOR=#000000][B], int [/B][/COLOR][COLOR=#000000]flags[/COLOR][COLOR=#000000][B],[/B][/COLOR]
                    [COLOR=#000000][B]int [/B][/COLOR][COLOR=#000000]fd[/COLOR][COLOR=#000000][B], off_t [/B][/COLOR][COLOR=#000000]offset[/COLOR][COLOR=#000000][B]);[/B][/COLOR]
[/FONT]

So the offset must be an off_t.

birdman · Apr 21, 2024

twol said:
Well your original change works for both the old boxes and new (I tested on vu+ uno4kse and GBUE4k), so thats the commit on OE-A… and don,t forget someone posted solo4k not working and thats not mips.

But it appears that the bug is nothing to do with the build options, but rather in the code itself, which is where the fix needs to go.

birdman · Apr 21, 2024

Of course, it would help in knowing which mmap() produces the error if there weren't 7 instances of exactly the same error message

Code:

"Mainmemory: <Memmapping failed>\n"

but a different one on each occasion.

There are also 4 printf() calls where the parameters to fulfill the template are missing.
How does this ever get built!

birdman · Apr 21, 2024

LraiZer said:
with off_t:

off_t adr;
int adr2, ofs, ofs2, offset, pageoffset;

They should all be off_t.

birdman · Apr 21, 2024

This compiles (only warnings are about unused variables, unknown pragmas and various enum values not handled in switch, if I add -Wall) and works with both these compile commands on an et8000:

Code:

 [FONT=monospace][COLOR=#000000]gcc main.c -o grab -lpng -[/COLOR]ljpeg[/FONT]

Code:

[FONT=monospace][COLOR=#000000]gcc -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 main.c -o grab64 -lpng -[/COLOR]ljpeg[/FONT]

View attachment main.zip

birdman · May 7, 2024

Three pull requests:

- Correct fprintf templates to fit no of parameters https://github.com/oe-alliance/aio-grab/pull/12
- Add discriminating number to <Memmapping failed> error messages. https://github.com/oe-alliance/aio-grab/pull/13
- Modify code to prevent sign extensions from "8bit<<24" item messing up 64-bit file-system API use. https://github.com/oe-alliance/aio-grab/pull/14

[ET10x00] Webif not showing TV picture in screen capture

Moderator

V.I.P

Moderator

Moderator

V.I.P

Moderator

Moderator

Moderator

V.I.P

V.I.P

Moderator

V.I.P

V.I.P

Moderator

Moderator

Moderator

Moderator

Moderator

Moderator

Similar threads

OpenViX Feeds Status